主要架构模式
云原生架构有非常多的架构模式,这里选取一些对应用收益更大的主要架构模式进行讨论。
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