Saga
如果微服务使用独享数据库，那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议，因为它要么不可伸缩（关系数据库），要么不被支持（多数非关系数据库）。
但您还是可以在微服务架构中使用 Saga 模式实现分布式事务。Saga 是 1987 年开发的一种古老模式，是关系数据库中关于大事务的一个替代概念。但这种模式的一种现代变种对分布式事务也非常有效。Saga 模式是一个本地事务序列，其每个事务在一个单独的微服务内更新数据存储并发布一个事件或消息。Saga 中的首个事务是由外部请求（事件或动作）初始化的，一旦本地事务完成（数据已保存在数据存储且消息或事件已发布），那么发布消息或事件则会触发 Saga 中的下一个本地事务。
如果本地事务失败，Saga 将执行一系列补偿事务来回滚前面本地事务的更改。
Saga 事务协调管理主要有两种形式：
- 事件编排 Choreography：分散协调，每个微服务生产并监听其他微服务的事件或消息然后决定是否执行某个动作
- 命令编排 Orchestration：集中协调，由一个协调器告诉参与的微服务哪个本地事务需要执行
优点
- 为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务
- 为使用了不支持 2PC 的非关系数据库的微服务架构提供一致性事务
缺点
- 需要处理瞬时故障，并且提供等幂性
- 难以调试，而且复杂性随着微服务数量增加而增加
何时使用 Saga
- 在使用了事件源的高可伸缩、松耦合的微服务中
- 在使用了分布式非关系数据库的系统中
何时不宜使用 Saga
- 使用关系数据库的低可伸缩性事务型系统
- 在服务间存在循环依赖的系统中
面向前端的后端 （BFF）
在现代商业应用开发，特别是微服务架构中，前后端应用是分离和独立的服务，它们通过 API 或 GraphQL 连接。如果应用程序还有移动 App 客户端，那么 Web 端和移动客户端使用相同的后端微服务就会出现问题。因为移动客户端和 Web 客户端有不同的屏幕尺寸、显示屏、性能、能耗和网络带宽，它们的 API 需求不同。
面向前端的后端模式适用于需要为特殊 UI 定制单独后端的场景。它还提供了其他优势，比如作为下游微服务的封装，从而减少 UI 和下游微服务之间的频繁通信。此外，在高安全要求的场景中，BFF 为部署在 DMZ 网络中的下游微服务提供了更高的安全性。
优点
- 分离 BFF 之间的关注点，使得我们可以为具体的 UI 优化他们
- 提供更高的安全性
- 减少 UI 和下游微服务之间频繁的通信
缺点
- BFF 之间代码重复
- 大量的 BFF 用于其他用户界面（例如，智能电视，Web，移动端，PC 桌面版）
- 需要仔细的设计和实现，BFF 不应该包含任何业务逻辑，而应只包含特定客户端逻辑和行为
何时使用 BFF
- 如果应用程序有多个含不同 API 需求的 UI
- 出于安全需要，UI 和下游微服务之间需要额外的层
- 如果在 UI 开发中使用微前端
何时不宜使用 BFF
- 如果应用程序虽有多个 UI，但使用的 API 相同
- 如果核心微服务不是部署在 DMZ 网络中
可用技术示例
任何后端框架（Node.js，Spring，Django，Laravel，Flask，Play，…）都能支持。
