微服务与架构设计原则

Service、Dao

Page

Controller

视图无关！

关注服务本身

JSON

API

Service

dao/repo

商品详情页

优惠计算

秒杀

批量上架

服务隔离

搜索

详情

Cart

下单

支付

搜索

详情

下单

服务隔离

异常容错

流控

弹性计算

toC

toB

运营

采购

相同领域、独有场景

商家前台的下单链路

商家后台

运营后台

快速验证业务模式

一月放一天假

集团的希望，五星目标

App终端

手淘导流

线下POS

Web业务系统

履约终端APP

拣货终端

扫码枪

核心业务

履约生命周期

订单生命周期

搜索推荐

广告展示

单体应用

拥有功能

服务混战，改造成为必然趋势

低频瞬时流量场景

高频匀速流量

定时任务

主链路+用户场景

运营场景

隔离业务场景

剥离高频接口

IC订单

淘系商品

UMP

支付系统

淘系支撑服务

商品搜索微服务

运营微服务

非主链路微服务

单商品下单

店内但商品下单

跨店下单

处理突发流量

Guava单机版限流工具

降级

熔断

路由

前端处理

后端处理

分发消息

会计账目

报表系统

退款流程

三段论拆解问题

翻译为凑合用

主链路

一致性

也可以范围以中间状态

高并发必备！

When & How

缓存一致性

数据一致性

一次调用

多次调用

单次与补偿

业务结果相同

最终一致性-补偿重试

异常访问

INSERT

UPDATE

DELETE

SELECT

对扩展开放

对修改关闭

网课程例子

Spring有很多的扩展点可以研究一下

按照上面的设计

单一职责的优化设计

通过迪米特法则我们可以尽可能降低类之间的耦合。

通过学校小姐姐，选择最风骚的老师

直接关联的是朋友，间接使用或者目标的是陌生人

子类可以添加自己独有的方法（废话，不然定义子类干什么）

子类重载父类方法时，方法的入参要比父类的入参更为宽松（接收更抽象的类），但返回值要比父类更严格（返回更具体的类）

子类必须实现父类抽象方法，但不能覆盖父类中非抽象的正常业务逻辑

public abstract class Teacher {
    public void saySomthing(){
        System.out.println("我们的口号是" + “同学们好” );
    }
}
// 正常老师
public class NormalTeacher extends Teacher {
    public void saySomthing(){
        System.out.println("我们的口号是" + “同学们好” );
    }
}
// 不正常老师
public class FengSaoTeacher extends Teacher {
    @Override
    public void saySomthing(){
        System.out.println("Hello同学们大家好" );
    }
}

以上结构在实现功能上没有问题，但是违反了里式替换原则里的一点 - 子类必须实现父类抽象方法，但不能覆盖父类中非抽象的正常业务逻辑。

public abstract class Teacher {
    public void saySomthing(){
        System.out.println("我们的口号是" + say() );
    }
}
public class NormalTeacher extends Teacher {
    @Override
    public abstract String say() {
        return "同学们好";
    }
}
public class FengSaoTeacher extends Teacher {
    @Override
    public String say() {
        return "同学们大家好";
    }
}
上面的例子当中四户看出来前面的影子，开闭原则，对扩展开放，对修改关闭，对父类行为的扩展，不仅仅可以通过声明一个新的类来做，也可以在方法级别声明这样一个扩展点。所以在架构领域，很多原则和准则都是相通的。

集成--->树状结构--->封闭性（父类变化影响子类，打破开闭原则）

树状结构

组合声明接口

迭代器

Builder

Decorator

Strategy

所谓依赖，从程序的角度看，就是比如A要调用B的方法，那么A就依赖于B，反正A要用到B，则A依赖于B。

所谓倒置，你必须理解如果不倒置，会怎么着，因为A必须要有B，才可以调用B，如果不倒置，意思就是A主动获取B的实例：B b = new B()，这就是最简单的获取B实例的方法（当然还有各种设计模式可以帮助你去获得B的实例，比如工厂、Locator等等），然后你就可以调用b对象了。

依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现（面向接口编程）。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

通过面向接口编程使程序中模块的依赖程度降低，达到低耦合的功能，重用性加强。

依赖倒置原则

两个核心甩锅思想

经典案例

软件设计层面

一个类对一类的依赖应该建立在最小的接口之上。

建立单一接口，不要建立庞大臃肿的接口。

尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。

接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑；

为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法；

提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

计算优惠信息

生成订单快照

自动/手动付款

获取商品信息

获取地址信息

账户信息检查

生成支付链接

计算优惠信息

库存锁定

生成订单快照

创建订单

释放/减少库存

商品服务

订单服务

库存服务

营销服务

全模板

领券服务

核销服务

高频场景

低频场景

IO密集

计算密集

配置中心

请访问其他页面

等等

Redis的local静默

核心主链路出现问题如何处理

Limit模块

Redis+Lua

Guava，单机限流轻量级别的

Sentinel，分布式的限流比较重

Nginx deny解决

托管平台防DDos的云平台来确定

动态限流

域名切换入口，Client端流量调度（推送）

HaProxy  LVS负载均衡

Nginx+服务网管

减少信息重复度

学车例子

框架层面

总之实现一句话描述

避免过度设计

分布式事务

上面就是脱裤子放屁

曾经只是职责分离

读写分离

数据异构和数据聚合

横向业务

纵向业务

无感知

约定大于配置

定制化，默认值

代码量少

框架层面

技术选型