微服务设计模式

微服务设计模式

什么是微服务？

相互独立但包含多个内部模块的子进程，服务之间采用网络调用（RPC）相互通信。

1| 独享数据库模式

特点：一个数据库对应一个微服务

优点：

• 更好的数据隔离、可扩展性和自治性。
• 每个微服务都可以独立地演化其数据模型，而不会影响其他服务。
• 每个微服务可以使用最适合的数据库。

• 团队开发之间耦合度降低

缺点：

• 写的问题：跨服务数据一致性问题（例如：订单+库存分布在两个服务中，单个服务中，利用数据库的事务就能解决@Transaction，分布在多个服务中，无法通过两个独立的数据库事务解决一致性问题-MQ半消息、2pc、3pc、seata、tcc），解决分布式事务头疼。
• 读的问题：跨服务的sql查询（在一个服务中，可以使用连接查询；跨服务就需要经过多次查询，再合并处理了，慢了，复杂了）

2| 事件溯源（Event Sourcing）模式

记录完整的过程(事件序列)，就可以算出任意时间点的状态。（比如购物车开始有10件商品，又加入了5件，如果用数据库就是修改数据，但是事件源模式，就是记录开始10件，又加了5件…）

举例：

创建一个专门的服务来负责所有物化视图的更新。这个服务订阅所有相关的事件，并根据这些事件更新物化视图，以便获取最新的状态。

1. 订单创建，发布消息
2. 库存监听到，减少库存，发布库存减少的消息
3. 支付处理，发布支持成功失败的消息
4. 订单监听，修改状态为已支付
5. （一般使用乐观锁去更新物化视图数据）

优势

• 有完整的事件序列（记录），有一些监管可以使用，还有比如用户在哪个功能停留了多久，什么时候退出系统，可以完整的监控到

挑战

由于需要事件版本控制、事件模式演化和处理长流程，因此复杂性增加。（当你引入新的字段（如订单备注）时，旧版本的事件没有这些字段。需要确保旧版本的事件在处理时不会因为缺少这些字段而导致错误，加了事件）

总结：我们一般使用MQ来实现。使用MQ 解耦、异步。

MQ数据一致性：

1. 发送prepare消息到消息中间件
2. 发送成功后，执行本地事务
3. 如果事务执行成功，则commit，消息中间件将消息下发至消费端
4. 如果事务执行失败，则回滚，消息中间件将这条prepare消息删除
5. 消费端接收到消息进行消费，如果消费失败，则不断重试

3| 命令查询职责分离（CQRS）模式

主要用于提高应用程序的可伸缩性和响应性。它的核心思想是将处理命令（cud）与查询（q）的责任分。

• 命令侧（Command Side）：负责处理所有改变应用状态的操作
• 查询侧（Query Side）：负责处理所有从应用中检索数据的操

举例：

购物车举例。

传统购物车一张表，添加商品修改商品，查询都需要这张表来操作。

现在： 读与写命令分离，写的时候就操作写，然后发送事件，读的逻辑接收事件，并做更新，方便后面的读操作。

• 查询侧

  • 数据存储：查询侧也有一个数据存储，也可以是一个缓存系统（如 Redis）。这个存储主要用于优化读取操作，比如快速获取购物车中的商品列表。
  • 事件监听：查询侧监听命令侧发布的事件，并根据这些事件更新自己的数据存储。例如，当查询侧监听到 item_added 事件时，它会更新自己的数据存储，以反映最新的购物车状态

总结

通过使用 CQRS 模式，我们可以独立地优化写操作和读操作，从而提高系统的性能和响应能力。

一个长事务，之前支付成功，然后后端的配送订单也成功等等，全部成功之后这个长事务才能完整的结束。引入MQ后，每个小的事务成功之后，就成功了，保证最终一致性即可。

4| SAGA 模式

一种长事务管理模式。通过一系列有序的本地事务和相应的补偿事务来保证最终一致性。每个事务本地事务完成后立即提交，如果发生错误，则按照顺序执行相应的补偿事务以回滚到之前的状态。

一般有两种模式“:

• 编排模式：集中式的协调者管理和控制saga的执行，负责触发每个本地事务并处理失败后的补偿
• 协同模式：每个服务决定何时开始下一个本地事务，通过事件驱动的方式进行协调。

阿里开源Seata长事务解决方式，底层理论就是SAGA模式

5| 断路器（Circuit Breaker）模式

微服务通过同步调用其它服务，由于瞬时故障（网络等），可以尝试重新，如果服务不可用，还在不断访问，线程被阻塞，就会出现雪崩。

断路器模式，就是监控故障数量，决定继续请求还是直接默认返回。有三种状态，开启，关闭，半开。

阿里Sentinel 实现了断路器模式的核心思想，并且在其基础上增加了更多的功能

6| API 网关

反向代理： 根据请求（例如 URL 路径或请求参数）路由到相应的微服务。

横切关注点：

• 认证和授权，身份识别与访问控制
• 限速和节流
• 负载均衡
• log 日志、链路追踪、关联，集中式日志管理（服务之间的 transaction ID、错误日志等）
• Header、query 字符串 以及 claims 转义
• IP 白名单

优势

• • 客户端应用程序只需要与API 网关连接，相当于微服务对客户端来说是单个系统。
• • 减少了客户端和微服务之间的请求响应次数。
• • 提供了一个横切关注点，例如身份验证、授权和日志记录。
• • 充当安全网关，执行身份验证和授权策略。

挑战

• API网关本身容易形成单点故障，需额外的处理。
• 如果 API 网关执行大量处理，它可能会成为瓶颈

总结：

如果流量过大，gateway很容易造成性能瓶颈，但是gateway又作为入口，有很多期望的逻辑去做，这时候要评估逻辑是不是下方到各个服务去做，尽量让gateway轻快。

7|BFF模式

简单理解：本来这个页面要展示的数据需要3个接口来完成，现在后端封装成一个接口（接口聚合）了，减少了前后端直接的交互（某些场景下会使用，单不是所有）

8|边车模式

在每个微服务旁边部署一个代理服务（边车），来处理服务间的通信和其他附加功能

下单举例：

1. 客户端发起请求：客户端（如Web应用）向订单服务的下单接口发送请求。
2. 边车接收请求：边车代理接收请求，进行鉴权等。
3. 记录日志：边车代理记录请求的日志信息。
4. 转发请求：边车将请求转发给订单服务。
5. 处理请求：订单服务处理请求并返回响应。
6. 边车记录响应日志：边车记录响应的日志信息。
7. 返回响应：边车将响应返回给客户端

还是解耦，维护性和灵活性都更高