主要架构模式

云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。

1、服务化架构模式

服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口

契约（例如 IDL）定义彼此业务关系，以标准协议（http、gRPC 等）确保彼此的互联互通，结合 DDD

（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服务化

架构的典型模式是微服务和小服务（Mini Service）模式，其中小服务可以看做是一组关系非常密切的

服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太

细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。

通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，

从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而

提升了整体的迭代效率。但是也需要注意到，服务拆分导致要维护的模块数增多，如果缺乏服务的自动

化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。

2、Mesh 化架构模式

Mesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与

业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对

业务透明。分离后在业务进程中只保留很“薄”的 Client 部分，Client 通常很少变化，只负责与 Mesh

进程通讯，原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。整个架构如下图所示。

态数据（如 session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但

仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断

根据上下文重新获取等，则可以考虑通过采用 Event Log + 快照（或 Check Point）的方式，实现重启

后快速增量恢复服务，减少不可用对业务的影响时长。

5、分布式事务模式

微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需

要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景

选择合适的分布式事务模式。

传统采用 XA 模式，虽然具备很强的一致性，但是性能差；

基于消息的最终一致性（BASE）通常有很高的性能，但是通用性有限，且消息端只能成功而不能触发消息

生产端的事务回滚；

TCC 模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强，

设计开发维护等成本很高；

SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段，而是每个正向事务都对应一个补偿事务，也是

开发维护成本高；

开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些

使用场景限制。

《云原生架构白皮书2022新版》——云原生架构的定义——主要架构模式（下） https://developer.aliyun.com/article/1232967