系统架构设计师 · 复习笔记 17 / 22 课时

云原生架构
设计理论与实践

Cloud Native Architecture — 让业务回归业务,把非功能交给云

第 14 章   教材第 2 版
PART · 一

云原生架构定义

§
云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化地剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。
核心公式
云应用代码 = 业务代码 + 三方软件 + 处理非功能特性的代码(剥离)
PART · 二

云原生架构特点

PART · 三

云原生的七大原则

⌘

口诀记忆:服 · 弹 · 观 · 韧 · 自 · 零 · 演

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

主要架构模式

⊕
模式 01 服务化架构模式
以应用模块为颗粒度划分一个应用软件,以接口契约(例如 IDL)定义彼此业务关系,以标准协议(HTTP、gRPC 等)确保彼此的互联互通,结合:
  • 领域模型驱动 DDD(Domain Driven Design)
  • 测试驱动开发 TDD(Test Driven Design)
  • 容器化部署
从而提升每个接口的代码质量和迭代速度。
模式 02 Mesh 化架构模式
把中间件框架(如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK 与业务代码进一步解耦,从而使得:
  • 中间件升级对业务进程没有影响
  • 甚至迁移到另外一个平台的中间件也对业务透明
模式 03 Serverless 模式
业务流量到来 / 业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭/调度业务进程,等待下一次触发。开发者不用关心:应用运行地点、操作系统、网络配置、CPU 性能等。
适用场景:
  • 事件驱动的数据计算任务
  • 计算时间短的请求/响应应用
  • 没有复杂相互调用的长周期任务
模式 04 存储计算分离模式
分布式环境中的 CAP 困难主要针对有状态应用:
  • Consistency 一致性
  • Availability 可用性
  • Partition Tolerance 分区容错性
三者无法同时满足,最多满足其中两个。所以无状态应用不存在一致性这个维度,可以获得很好的可用性和分区容错性,因而获得更好的弹性。
模式 05 分布式事务模式 ★ 高频考点
由于业务需要访问多个微服务,所以会带来分布式事务问题,否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式:
XA 模式
传统采用模式。XA 规范是实现分布式事务处理的标准,通常采用两阶段提交(2PC)。具有很强的一致性,但需要两次网络交互,性能差。
BASE 模式
基于消息的最终一致性。可用性和一致性冲突时权衡二者:基本可用(BA)+ 软状态(S)+ 最终一致性(E)。通常具备很高的性能,但通用性有限。
TCC 模式
采用 Try - Confirm - Cancel 二阶段模式。事务隔离性可控,高效,但需将业务模型拆成二阶段,对业务侵入性强,设计开发维护成本高。
SAGA 模式
每个正向事务都对应一个补偿事务,若正向事务执行失败,则执行补偿事务进行回滚。开发维护成本高。
SEATA AT 模式
开源项目。将 TCC 模式中的二阶段委托给底层代码框架,并取消行锁。非常高性能 + 无代码开发工作量,且可自动执行回滚操作,但存在一些使用场景限制。
模式 06 可观测架构
可观测架构三大支柱:
  • Logging(日志):提供多个级别跟踪,例如 INFO / DEBUG / WARNING / ERROR。
  • Tracing(链路跟踪):收集一个请求从前端到后端的访问日志聚合,形成完整调用链路跟踪。
  • Metrics(度量):提供对系统量化的多维度度量,包括并发度、耗时、可用时长、容量等。
模式 07 事件驱动架构 EDA
EDA(Event Driven Architecture)是一种应用/组件间的集成架构模式。
适用场景:
  • 增强服务韧性
  • 数据变化通知
  • 构建开放式接口
  • 事件流处理
  • 命令查询的责任分离 CQRS(Command Query Responsibility Segregation):把对服务状态有影响的命令用事件来发起,而对服务状态没有影响的查询才使用同步调用的 API 接口
PART · 五

典型的云原生架构反模式

✕
反模式 1 · 庞大的单体应用

缺乏依赖隔离 → 代码耦合 → 责任和模块边界不清晰 → 模块间接口缺乏治理 → 变更影响扩散 → 不同模块间的开发进度和发布时间要求难以协调 → 一个子模块不稳定导致整个应用都变慢 → 扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容。

反模式 2 · 单体应用"硬拆"为微服务

强行把耦合度高、代码量少的模块进行服务化拆分;拆分后服务的数据是紧密耦合的;拆分后成为分布式调用,严重影响性能。

反模式 3 · 缺乏自动化能力的微服务

人均负责模块数上升 → 人均工作量增大 → 增加了软件开发成本。

PART · 六

容器技术

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

容器编排技术

⛬

容器编排技术包括以下能力:

资源调度 应用部署与管理 自动修复 服务发现与负载均衡 弹性伸缩 声明式 API 可扩展性架构 可移植性
PART · 八

微服务

◈
微服务模式将后端单体应用拆分为松耦合的多个子应用,每个子应用负责一组子功能。这些子应用称为"微服务",多个"微服务"共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立,通过解耦研发、测试与部署流程,提高整体迭代效率。
①微服务设计约束
  • 微服务个体约束:微服务应用的功能在业务领域划分上应是相互独立的。
  • 微服务与微服务之间的横向关系:在合理划分好微服务间的边界后,从可发现性和可交互性处理横向关系。
    • 可发现性:当服务 A 发布和扩/缩容时,依赖服务 A 的服务 B 在不重新发布的前提下,能够自动感知到服务 A 的变化。
    • 可交互性:服务 A 采用什么样的方式可以调用服务 B。
  • 微服务与数据层之间的纵向约束:提倡数据存储隔离原则(DSS,Data Storage Segregation),对于数据的访问都必须通过相对应的微服务提供的 API 来访问。
  • 全局视角下的微服务分布式约束:高效运维整个系统,从技术上实现全自动化的 CI/CD 流水线满足对开发效率的诉求,并在这个基础上支持蓝绿、金丝雀等不同发布策略,以满足对业务发布稳定性的诉求。
PART · 九

无服务器技术 Serverless

∅
①无服务器技术的特点
  • 全托管的计算服务 —— 客户只需要编写代码构建应用,无须关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作。
  • 通用性 —— 结合云 BaaS(后端云服务)API 的能力,能够支撑云上所有重要类型的应用。
  • 自动弹性伸缩 —— 让用户无须为资源使用提前进行容量规划。
  • 按量计费 —— 让企业的使用成本有效降低,无须为闲置资源付费。
②无服务器技术的关注点
  • 计算资源弹性调度:容错、资源利用率、性能、数据驱动
  • 负载均衡和流控
  • 安全性
PART · 十

服务网格 Service Mesh

◊
服务网格旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施,实现应用与平台基础设施的解耦。
①典型架构(教材图 17.3)

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

②主要技术
Istio Linkerd Consul