微服务中的通信&saga

0.前言

  相关内容主要是阅读《微服务架构设计》的一些所得及吐槽，内容作为笔记、周记的属性更重，若有幸被人看到，欢迎吐槽、指正。

---

1.微服务中的通信

	一对一	一对多
同步模式	请求/响应	无
异步模式	异步请求/响应 单向通知	发布/订阅 发布/异步响应

---

apid的语义化版本控制规范（Semvers）要求版本号由三个部分组成： MAJOR.MINOR.PATCH

• MAJOR:进行不兼容的更改时
• MINOR:进行向后兼容的增强时
• PATCH:进行向后兼容的错误修复时

---

确保消息可靠发送的一些方案：

• 使用数据库表作为消息队列

  创建一张表作为临时的消息队列，基于本地事务将待发送的消息写入临时表中，保证事务的原子性，之后将临时表中的信息发送到消息方：
方案1：轮询消息表，简单但只适用于小规模场景
方案2：事务日志拖尾，监听数据库的日志，如mysql的binLog

---

  同步的通信方式会降低可用性，一个api聚合多个接口，整体可用性为所聚合的接口的可用性的乘积，如 (99.5%)^3^ = 98.5%

提高系统可用性就应该最小化系统的同步操作量 ：

• 使用异步交互方式
• 复制数据，即做数据副本，实现数据闭环

---

2.分布式事务-saga模式

  微服务的拆分导致原来在单体应用中简单的事务需要跨越不同的服务了，变成了分布式事务，实现分布式事务经常提到的有两阶段提交、TCC(try-confirm-cancel) ， saga模式也是分布式事务的一种解法。
  事务拆分为事务的发起事件和补偿事件，例如一个下单事务(正向事件)失败时，要发出一个补偿事务(负向事件)用来实现回滚操作；当然实际业务中，一个事务有多个正向事件和多个负向事件，这种事件驱动的架构有两种模式：

• 协同模式：把saga的决策和执行顺序逻辑分布在saga的每一个参与方中，他们通过交换事件的方式进行沟通
• 编排模式：把saga的决策和执行顺序逻辑集中在一个saga的编排器中，编排器发出命令给各个saga的参与方，指示这些参与方完成具体的操作

  协同模式更灵活也更简单，但是当场景复杂之后，整体的协作难以理解，新接手的同学要理解完整的业务流细节会很困难，bug的修复、迭代也会有风险。
  编排模式有一个专门的编排器管理业务逻辑，各领域关注自己的事件，职责集中，在组织上甚至可以是专门的同学负责；

---

  服务之间采用事件驱动会引入一些公共问题，其中事件的重复、丢失、乱序对事务都会造成严重的影响，所以需要一些策略：

• 语义锁：业务中增加标识字段，例如订单状态state（approval_pending approved rejected)，数据的更新依赖于状态的流转规则
• 悲观视图：重新排序saga的步骤，最大限度降低业务风险
• 重读值：更新时执行cas操作