系统架构设计高级技能 · 云原生架构设计理论与实践

系列文章目录

系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

一、 云原生架构内涵

1.1 定义

云原生架构 是基于云原生技术的一组架构原则和设计模式的集合，旨在讲云应用中的非业务代码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

1.2 特点

基于云原生架构的应用特点包括：

（1） 代码结构发生巨大变化：不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的网络技术，简化让业务开发变得更敏捷、更快捷。
（2） 非功能特性大量委托给云原生架构来解决：比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
（3） 高度自动化的软件交付：基于云原生的自动化软件交付可以把应用自动化部署到成千上万的节点上。

1.3 云原生的原则

云原生具有以下原则：

（1） 服务化原则：通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代。
（2） 弹性原则：弹性是指系统的部署规模可以随着业务量的变化而自动伸缩。
（3） 可观测原则：通过日志、链路跟踪和度量等手段，使得多次服务调用的耗时、返回值和参数都清晰可见。
（4） 韧性原则：软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
（5） 所有过程自动化原则：让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
（6） 零信任原则：不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。
（7） 架构持续演进原则：架构具备持续演进的能力。

1.4 主要架构模式

云原生涉及的主要架构模式。

1.4.1 服务化架构模式

要求以应用模块为颗粒度划分一个应用软件，以接口契约（例如IDL）定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联互通，结合领域模型驱动（Domain Driven Design，DDD）、测试驱动开发（Test Driven Design，TDD）、容器化部署提升每个接口的代码质量和迭代速度。

1.4.2 Mesh化架构模式

Mesh化架构是把中间件框架（如RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。

1.4.3 Serverless模式

业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发。开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等，将应用的整个运行都委托给云。Serverless模式适合事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

1.4.4 存储计算分离模式

分布式环境中的CAP困难主要是针对有状态应用，由于一致性（Consistency，C），可用性（Available，A），分区容错性（Partition Tolerance，P）三者无法同时满足，最多满足其中两个。所以无状态应用不存在一致性这个维度，可以获得很好的可用性和分区容错性，因而获得更好的弹性。

1.4.5 分布式事务模式

由于业务需要访问多个微服务，所以会带来分布式事务问题，否则数据就会出现不一致。因此架构师需要根据不同的场景选择合适的分布式事务模式，常用的有：
（1）XA模式：由于XA规范是实现分布式事务处理的标准，通常采用两阶段提交（2 Prepare Commit，2PC）的方法，具有很强的一致性，但是由于需要两次网络交互，所以性能差。
（2）基于消息的最终一致性（BASE）：在可用性和一致性相冲突的情况下，为了权衡二者，BASE提出只要满足基本可用（BA）和最终一致性（E），接受数据的软状态或未确定状态（S），来优先实现性能，所以这类系统通常具备很高的性能。但是由于应用的特点，选择可用性和一致性的妥协方案，导致通用性很差。
（3）TCC模式：采用Try-Confirm-Cancel二阶段模式，事务隔离行可控，高效，但需要应用代码将业务模型拆成二阶段，所以对业务侵入性强，设计开发维护等成本很高。
（4）SAGA模式：每个正向事务都对应一个补偿事务，若正向事务执行失败，则会执行补偿事务进行回滚。所以开发维护成本高。
（5）开源项目SEATA的AT模式：它将TCC模式中的二阶段委托给底层代码框架，并且取消了行锁，所以非常高性能且无代码开发工作量，且可以自动化执行回滚操作，但存在一些使用场景限制。

1.4.6 可观测架构

可观测架构包括Logging、Tracing、Metrics，其中Logging提供多个级别跟踪，例如INFO/DEBUG/WARNING/ERROR；Tracing收集一个请求从前端到后端的访问日志聚合，形成完整调用链路跟踪；Metrics则提供对系统量化的多维度度量，包括并发度、耗时、可用时长、容量等。

1.4.7 事件驱动架构

事件驱动架构（Event Driven Architecture，EDA）是一种应用/组件间的集成架构模式。适用于增强服务韧性、数据变化通知、构建开放式接口、事件流处理、命令查询的责任分离（Command Query Responsibility Segregation，CQRS）把服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的API接口等。

1.5 典型的云原生架构的反模式

架构设计有时候需要根据不同的业务场景选择不同的方式，常见的云原生反模式有：

（1） 庞大的单体应用：缺乏依赖隔离，代码耦合，责任和模块边界不清晰，模块间接口缺乏治理，变更影响扩散，不同模块间的开发进度和发布时间难以协调，一个子模块不稳定导致整个应用都变慢，扩容时只能整体扩容而不能达到瓶颈的模块单独扩容等。
（2） 单体应用“硬拆”为微服务：强行把耦合度高、代码质量少的模块进行服务化拆分；拆分后服务的数据是紧密耦合的；差分后成为分布式调用，严重影响性能。
（3） 缺乏自动化能力的微服务：人均负责模块数上升，人均工作量增大，也增加了软件开发成本。

二、云原生架构相关技术

1.1 容器技术

容器 作为标准化软件基础单元，他将应用及其所依赖项打包发布，由于依赖项齐备，应用不再受环境限制，在不同计算环境间快读、可靠地运行。

容器部署模式与其他模式的比较，如图，传统、虚拟化、容器部署模式比较：

1.2 容器编排技术

容器编排技术 包括资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式API、可扩展性架构、可移植性。

1.3 微服务

微服务模式 将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用成为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这写微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。

微服务设计约束如下：

（1）微服务个体约束
一个设计良好的微服务应用，所完成的功能在业务域划分上应是相互独立的。与单体应用强行绑定语言和技术栈相比，这样做的好处是不同业务域有不同的技术选择权，比如推荐系统采用 Python实现效率可能比Java要高效得多。从组织上来说，微服务对应的团队更小，开发效率也更高。“一个微服务团队一顿能吃掉两张披萨饼”“一个微服务应用应当能至少两周完成一次迭代”,都是对如何正确划分微服务在业务域边界的隐喻和标准。总结来说，微服务的“微”并不是为了微而微，而是按照问题域对单体应用做合理拆分。进一步，微服务也应具备正交分解特性，在职责划分上专注于特定业务并将之做好，即SOLID原则中单一职责原则 (Single Responsibility Principle,SRP)。 如果当一个微服务修改或者发布时，不应该影响到同一系统里另一个微服务的业务交互。

（2）微服务与微服务之间的横向关系
在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的横向关系。微服务的可发现性是指当服务A 发布和扩缩容的时候，依赖服务 A 的服务B 如何在不重新发布的前提下，如何能够自动感知到服务A 的变化?这里需要引入第三方服务注册中心来满足服务的可发现性；特别是对于大规模微服务集群，服务注册中心的推送和扩展能力尤为关键。微服务的可交互性是指服务A 采用什么样的方式可以调用服务 B。 由于服务自治的约束，服务之间的调用需要采用与语言无关的远程调用协议，比如 REST 协议很好地满足了“与语言无关”和“标准化”两个重要因素，但在高性能场景下，基于 IDL的二进制协议可能是更好的选择。另外，目前业界大部分微服务实践往往没有达到HATEOAS启发式的 REST 调用，服务与服务之间需要通过事先约定接口来完成调用。为了进一步实现服务与服务之间的解耦，微服务体系中需要有一个独立的元数据中心来存储服务的元数据信息，服务通过查询该中心来理解发起调用的细节。伴随着服务链路的不断变长，整个微服务系统也就变得越来越脆弱，因此面向失败
设计的原则在微服务体系中就显得尤为重要。对于微服务应用个体，限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配。为进一步提升系统吞吐能力、充分利用好机器资源，可以通过协程、 R x模型、异步调用、反压等手段来实现。

（3）微服务与数据层之间的纵向约束

在微服务领域，提侣数据存储隔离 (Data Storage Segregation,DSS) 原则，即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的API来访问。如若不然，则造成数据层产生耦合，违背了高内聚低耦合的原则。同时，出于性能考虑，通常采取读写分离(CQRS) 手段。同样，由于容器调度对底层设施稳定性的不可预知影响，微服务的设计应当尽量遵循无状态设计原则，这意味着上层应用与底层基础设施的解耦，微服务可以自由在不同容器间被调度。对于有数据存取(即有状态)的微服务而言，通常使用计算与存储分离方式，将数据下沉到分布式存储，通过这个方式做到一定程度的无状态化。

（4）全局视角下的微服务分布式约束
从微服务系统设计一开始，就需要考虑以下因素：高效运维整个系统，从技术上要准备全自动化的CI/CD流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。面对复杂系统，全链路、实时和多维度的可观测能力成为标配。为了及时、有效地防范各类运维风险，需要从微服务体系多种事件源汇聚并分析相关数据，然后在中心化的监控系统中进行多维度展现。伴随着微服务拆分的持续，故障发现时效性和根因精确性始终是开发运维人员的核心诉求。

1.4 无服务技术

无服务技术的特点：

(1)全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；

(2)通用性，结合云 BaaSAPI的能力，能够支撑云上所有重要类型的应用；

(3)自动弹性伸缩，让用户无需为资源使用提前进行容量规划；

(4)按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

1.5 服务网络

服务网格 (ServiceMesh) 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦 。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能性从业务进程剥离到另外进程中，服务网格以无侵入的方式实现了应用轻量化。

如图，服务网格的典型架构：

在这张架构图中，服务A 调用服务B 的所有请求，都被其下的服务代理截获，代理服务A 完成到服务B 的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面 (Control Plane) 上配置。