接前一篇文章：软考 系统架构设计师系列知识点之云原生架构设计理论与实践（6）
所属章节：
第14章. 云原生架构设计理论与实践
第2节 云原生架构内涵
14.2 云原生架构内涵
关于云原生的定义有众多版本，对于云原生架构的理解也不尽相同。本节将根据广泛的云原生技术、产品和上云实践，给出一般性的理解。
14.2.3 主要架构模式
云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。
1. 服务化架构模式
服务化架构是云时代构建云原生应用的标准架构模式。要求以应用模块为颗粒度划分一个软件，以接口契约（例如IDL）定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联互通，结合DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务模式。其中小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。
通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。
2. Mesh化架构模式
Mesh化架构是把中间件框架（如RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很“薄”的Client成分，Client通常很少变化，只负责与Mesh进行通信，而原来需要在SDK中处理的流量控制、安全等逻辑则由Mesh进程完成。整体架构如图14-1所示：
完成Mesh化架构后，大量分布式架构模式（熔断、限流、降级、重试、反压、隔仓……）都由Mesh进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性（比如零信任架构能力），按流量进行动态环境隔离、基于流量左冒烟/回归测试等。
更多架构模式请看下回。
