分布式微服务架构设计原理_读书笔记_3

1.3.5微服务的容错模式

整体的业务流程被拆分成小的微服务，并组合在一起对外提供服务，微服务之间使用轻量级网络协议通信，通常是基于REST的风格的远程调用。网络通信不稳定，不可靠，一个服务依赖的服务可能出错，超时或者宕机，如果没有及时发现和隔离问题，或者设计中没有考虑如何应对这样的问题，短时间内服务的线程池中的线程被用满，资源耗尽，导致雪崩效应。

舱壁隔离模式

船舱进水希望这个舱和其他舱是隔离的。

1）微服务容器分组

笔者所在支付平台应用微服务，将微服务每个节点的服务池分为三组

准生产环境，灰度环境，生产环境

准生产环境供内侧使用;

灰度环境跑一些普通商户流量;

生产环境跑大部分生产流量和VIP商户的流量。

这样在较大重构过程中，我们就可以充分利用弧度环境的隔离性进行预验证，普通商户的流量验证重构没有问题后，再上生产环境。

另一个案例：

社交平台将名人的自媒体流量全部路由到服务的核心池子中，普通用户的流量路由到另一个服务池子中，有效隔离普通用户和重要用户的负载。

负载均衡（分流）

• 分组一：容器，容器，容器...

• 分组二：容器，容器，容器...

• 分组三：容器，容器，容器...

2）线程池隔离

一般将同一类功能划分在一个微服务中，避免微服务过细导致成本增加

这就导致多个功能混合部署在一个微服务实例中，这些微服务不同功能通常使用同一个线程池，导致一个功能流量增加时耗尽线程池的线程，阻塞其他功能的服务。

不同功能不使用同一个线程池，功能一一个线程池，功能二一个线程池，功能三一个线程池...

2.熔断模式

类似电路保险开关，自动跳闸。

当服务输入负载迅速增加时，如果没有有效措施对负载进行熔断，会使服务迅速被压垮，在微服务架构中实现熔断模式。

3.限流模式

控制访问的并发量

1）计数器

原子变量计算单位时间内访问此时，如果超出某个阈值，则拒绝后续请求，等到下一个单位时间再重新计数。

计数器实现方法中通常定义一个循环数组，定义五个元素的环形数组，计数周期为1秒，可以记录4S内的访问量，其中有一个元素为当前时间点的标志，通常来说每秒程序都会将前面3秒的访问量打印到日志，提供分析

前一秒一直没有请求量，下一秒计数器始终不能清零，下一秒请求到达后要先清零，并更新清零时间再使用。

2）令牌筒

流行的实现限流的计数方案，通过一个线程单位时间内产生固定数量的令牌，然后把令牌放入队列，每次请求调用需要从筒中拿取一个令牌，拿到令牌才有资格执行请求调用，否则只能等待拿到令牌再执行，或者直接丢弃。

3）信号量

限流类似漏斗，无论倒入多少油，下面的漏斗流量有限，实际上在应用层使用的信号量也可以实现限流

4）失效转移模式

微服务发生了熔断和限流，处理被拒绝的请求就要用到失效转移模式

• 采用快速失败策略，直接返回使用方错误，让使用方知道发生了问题并自行解决后续处理

• 是否有备份服务，如果有备份服务，则循序切换到备份服务。

• 失败的服务有可能是某台机器有问题，而不是所有机器有问题，如OOM问题[内存不足]，这时适合使用故障转移策略，采用重试方法来解决，但是要求服务提供者的服务实现了幂等性。[的接口幂等性实际上就是接口柯林斯重复调用，在调用方多次调用的情况下，接口最终得到的结果是一致的。有些接口可以天然的实现幂等性，比如查询接口，对于查询来说，你查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。]

  如何保证幂等

  • 全局唯一ID，根据业务的操作和内容生成全局ID，执行前根据这个全局唯一ID是否存在，判断这个操作是否已经执行。如果不存在则把全局ID存储到存储系统[数据库，redis的等]，如果存在则表示该方法已经执行。每个微服务都完成这些功能会存在功能重复，还要考虑很多问题，引入全局ID超时机制。全局ID是通用方案，支持插入更新和删除业务，但是比较麻烦

  • 去重表：适用业务中有唯一标的插入场景

  • 多版本控制：适合在更新的场景中

  • 状态机制：。适合在有状态流转的情况下比如订单的创建和支付设计状态字段INT并通过值大小做幂等订单创建0，付款成功100，付款失败99

  
  更新 '订单'  设定状态=＃{}状态，其中 ID =＃{ID} 和状态<＃{}状态

1.3.6微服务的粒度

拆分服务要按照业务功能进行拆分，直到每个服务功能和职责单一，甚至不可再分，每个服务都能单独部署，扩容和缩容方便，有效提高利用率。拆的越细，服务的耦合度越小，内聚性越好，越适合发布和上线。然而拆的太细会导致互相依赖关系复杂，

康威定律（Conway的定律）

团队的组织方式必然会对它产生的代码有影响。时间推移，架构也会影响到团队的协作的好坏。团队瓦解代码交互很糟，团队协作架构就会集成很好。

对微服务拆分适可而止，可以让使用方自由编排底层的子服务来获得相应的组合服务即可，同事考虑团队的建设及人员的数量和分配。