第二章架构设计之技术实践篇(下)

本章要点

• 分布式事务设计与实践
• 服务降级设计
• 服务限流/熔断设计
• 服务灰度发布设计

1.分布式事务设计与实践

分布式事务：不同的服务或者多个DB保持数据的一致性和操作的原子性

1.1 分布式事务理论

1）CAP理论

CAP：C(Consistency)，数据一致性；A(Availability),可用性；P(PartitionTolerance),表示分区容错性，即当部分服务器宕机或网络异常时其他服务器可以提供正常服务。
分布式系统只能满足三项中的两项而不可能满足全部三项；其中P是不可丢弃的，是必须的，所以C和A之间，二选一。

• CP： ，要求服务器之间保持强一致，而P（分区）数据同步是需要时间的，期间一旦发生网络异常或者消息丢失等情况，就需要一直等在数据同步完成，数据一致后，才能给予用户提供正常服务，严重影响牺牲用户的体验。CP系统，最典型的就是分布式数据库，如Redis、HBase等。

• AP： 要求高可用,一旦分区发生，节点之间可能无法通信；为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

2) BASE理论

BASE理论：BA指的是基本业务可用性，支持分区失败，S表示柔性状态，也就是允许短时间内不同步，E表示最终一致性，数据最终是一致的。

1.2 刚性分布式事务（CP模型）

特点： 满足事务的ACID特性 ；XA模型（实现方式2PC）
思路：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

2PC

过程：
（1）投票阶段（voting phase）：协调者(Coordinator或TM)发起投票，参与者(Partcipant或RM)准备好资源之后，将准备好的信息结果通知给协调者(Coordinator或TM)；
（2）提交阶段（commit phase）：收到参与者(Partcipant或RM)的已准备好资源的通知后，协调者再向参与者参与者(Partcipant或RM)发出通知，则所有的参与者参与者(Partcipant或RM)进行提交操作，如果遇到失败则回滚

缺点：

• 1）阻塞问题：在其执行过程中间，节点都处于阻塞状态；
• 2）性能问题，数据库资源锁定时间过长，各个操作数据库的节点此时都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源
• 3）全局锁(隔离级别串行化)，并发低
• 4）单点故障问题，协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态或中间状态
• 5）不适合长事务场景

image.png

1.3 柔性分布式事务（AP模型）

通过是对XA协议的妥协，通过降低对强一致性对要求，从而降低对数据库资源对锁定时间，提升可用性，达到最终一致性
柔性事务的理论基础：CAP理论，BASE理论，
实现：TCC事务模型(偏业务)，SAGA模型

1.3.1 TCC模型

TCC 的三阶段：

• Try 阶段，对业务系统做检测及资源预留;
• Confirm 阶段，对业务系统做确认提交，Try 阶段执行成功并开始执行 Confirm 阶段时，默认 Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm 一定成功；
• Cancel 阶段，在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
  对业务侵入性较大

1.3.2 SAGA模型

每个Saga由一系列sub-transaction Ti 组成，每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果

Saga的两种恢复策略：

backward recovery：向后恢复，补偿所有已完成的事务，如果任一子事务失败，例如i是发生错误的子事务，此时应该撤销i之前所有所有成功的子事务，使得整个Saga的执行结果达到数据一致性。
forward recovery：向前恢复，重试失败的子事务。

刚性分布式事务与柔性分布式事务比较：

image.png

1.4 分布式事务设计方案

（1）异步场景以半消息分布式事务方案：

• 业务方提供本地操作成功回查接口
• Half Message(半消息) ：Producer 已经把消息成功发送到了 Broker 端，但此消息被标记为暂不能投递状态，处于该种状态下的消息称为半消息，Consumer暂时不能消费的消息，需要 Producer对消息的二次确认后，Consumer才能去消费它。
• 消息回查：由于网络闪段，生产者应用重启等原因，导致 Producer 端一直没有对 Half Message(半消息) 进行二次确认。这时Brock服务器会定时扫描长期处于半消息的消息，会
  主动询问 Producer端该消息的最终状态(Commit或者Rollback),即叫做消息回查。

image.png

流程设计：

• 1）事务发起方首先发送半事务消息到MQ
• 2）在发送半事务消息成功后，执行本地事务
• 3）根据本地事务执行结果的成功与否，执行commit或rollback消息
• 4）如果消息是rollback，MQ应将该半消息删除不进行下发；如果是commit则MQ将会将消息发送给订阅方
• 5）如果执行本地事务过程中，执行端挂掉或者超时，MQ Server端将会不停的询问发送方来获取事务状态
• 6）订阅方的消费成功机制有MQ保证

缺点：

• 业务方需要提供查询接口，对业务侵入比较大
• 由于发送消息非幂等，所以消费端需要处理幂等
• MQ Server需要遍历处理半事务消息

（2）异步场景以本地事务消息表方案：

• 本地操作和发送消息通过本地事务强保证一致性
  -- 消息表
  -- 业务表
  -- 日志记录表
• 业务侵入性小

image.png

缺点：

• 由于发送端消息不幂等，消费端需要处理幂等性
• 消息发送需要使用At least once
  （3）同步步场景以本地消息事务表方案：
  SAGA原理基于补偿机制
• 记录请求参数，记录事务状态等
• 每个更新服务都需要提供相应的补偿接口
• 补偿接口必须是幂等
• JOB定时扫描事务表，处理事务异常记录

image.png

2.服务降级设计

当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

目的：保证核心服务可用，非核心服务弱可用或甚至不可用
手段： 1）拒绝部分请求； 2）关闭部分服务

image.png

服务层面进行分级别，按照服务的重要性进行降级。

3.服务限流/熔断设计

在分布式的环境或者微服务中，不可避免的会出现一些错误，一个服务的失败或许会导致整个项目的失败。熔断就是通过添加容错逻辑来保护或者控制你的分布式服务之间的交互，通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供后备选项来实现这一目标，所有这些都可以提高系统的整体弹性。
限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源

熔断框架：Hystrix，Sentinel，Resilience4j等

4.服务灰度发布设计