17-云原生架构设计实践（第17小时）
软考-系统架构设计师 | 第4篇 架构设计实践知识 出题形式：下午案例分析题（必出 25 分）+ 上午选择题（2-4 分）+ 论文题 分值占比：约 25-30 分（重点！必出案例）
0. 考点分析
- 云原生定义与特点：剥离非业务代码、委托非功能性
- 云原生 7 大原则：服务化、弹性、可观测、韧性、自动化、零信任、持续演进
- 6 大架构模式：服务化、Mesh 化、Serverless、存储计算分离、分布式事务、可观测、事件驱动
- 5 种分布式事务模式：XA / BASE / TCC / SAGA / SEATA AT
- 容器 vs 虚拟化 vs 传统部署
- Serverless 4 特点
- Service Mesh（Istio/Linkerd/Consul）
- 3 种云原生反模式
1. 核心架构知识
1.1 云原生架构内涵
定义：云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化地剥离，让云设施接管应用中原有的大量非功能特性（弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
应用特点：
- 代码结构发生巨大变化：不再需要掌握文件及其分布式处理技术、各种复杂的网络技术
- 非功能性特性大量委托：高可用、容灾、安全、可运维、易用、可测试、灰度等
- 高度自动化的软件交付：自动部署到成千上万的节点上
1.2 云原生 7 大原则
| 原则 | 含义 |
|---|---|
| 服务化原则 | 通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代 |
| 弹性原则 | 系统的部署规模可以随着业务量的变化而自动伸缩 |
| 可观测原则 | 通过日志、链路跟踪和度量等手段，使多次服务调用的耗时、返回值和参数都清晰可见 |
| 韧性原则 | 软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力 |
| 所有过程自动化原则 | 让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化 |
| 零信任原则 | 不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础 |
| 架构持续演进原则 | 架构具备持续演进能力 |
1.3 云原生 6 大架构模式
1.3.1 服务化架构模式
- 以应用模块为颗粒度划分应用软件
- 以**接口契约（IDL）**定义业务关系
- 以**标准协议（HTTP、gRPC）**确保互联互通
- 结合 DDD（领域驱动设计）、TDD（测试驱动开发）、容器化部署
1.3.2 Mesh 化架构模式
- 把中间件框架（RPC、缓存、异步消息）从业务进程中分离
- 中间件 SDK 与业务代码进一步解耦
- 中间件升级对业务进程没有影响
1.3.3 Serverless 模式
- 业务流量到来/事件发生时，云启动/调度业务进程
- 处理完成后自动关闭/调度业务进程
- 开发者不用关心应用运行地点、操作系统、网络配置、CPU 性能
- 适用场景：事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务
1.3.4 存储计算分离模式
- 分布式环境中的 CAP 困难（C-一致性、A-可用性、P-分区容错性）最多满足其中两个
- 无状态应用不存在一致性维度，可获得更好的可用性和分区容错性，因而弹性更好
1.3.5 分布式事务模式（5 种对比）
| 模式 | 机制 | 优点 | 缺点 |
|---|---|---|---|
| XA 模式 | 2PC 两阶段提交 | 强一致性 | 性能差（两次网络交互） |
| BASE 模式 | 基于消息的最终一致性 | 性能高 | 通用性有限（最终一致） |
| TCC 模式 | Try-Confirm-Cancel 二阶段 | 隔离性可控，高效 | 业务侵入性强，开发维护成本高 |
| SAGA 模式 | 正向事务 + 补偿事务 | 长事务支持 | 开发维护成本高 |
| SEATA AT 模式 | 二阶段委托给框架 + 取消行锁 | 高性能，无代码工作量 | 有使用场景限制 |
1.3.6 可观测架构（3 大支柱）
| 支柱 | 作用 |
|---|---|
| Logging | 提供多个级别跟踪，如 INFO/DEBUG/WARNING/ERROR |
| Tracing | 收集从前端到后端的访问日志聚合，形成完整调用链路跟踪 |
| Metrics | 提供系统量化的多维度度量（并发度、耗时、可用时长、容量） |
1.3.7 事件驱动架构（EDA）
应用/组件间的集成架构模式。适用于：
- 增强服务韧性
- 数据变化通知
- 构建开放式接口
- 事件流处理
- CQRS（命令查询的责任分离）：把对服务状态有影响的命令用事件发起，对状态没有影响的查询才使用同步 API
1.4 云原生反模式（3 种）
- 庞大的单体应用：缺乏依赖隔离，代码耦合，整体扩容难
- 单体应用"硬拆"为微服务：强行拆分耦合度高、代码量少的模块；拆分后分布式调用严重影响性能
- 缺乏自动化能力的微服务：人均负责模块数上升，工作量增大
1.5 云原生相关技术
1.5.1 容器技术
容器作为标准化软件基础单元：将应用及其所有依赖项打包发布，由于依赖项齐备，应用不再受环境限制，在不同计算环境间快速、可靠地运行。
部署模式对比：
| 维度 | 传统部署 | 虚拟化部署 | 容器部署 |
|---|---|---|---|
| OS | 共享 | 每 VM 独立 OS | 共享 OS |
| 启动速度 | 最慢 | 慢 | 秒级 |
| 资源占用 | 大 | 中 | 小 |
| 隔离性 | 弱 | 强 | 中 |
1.5.2 容器编排技术
8 大能力：
- 资源调度
- 应用部署与管理
- 自动修复
- 服务发现与负载均衡
- 弹性伸缩
- 声明式 API
- 可扩展性架构
- 可移植性
1.5.3 微服务设计 4 大约束
| 约束 | 内容 |
|---|---|
| 微服务个体约束 | 在业务领域划分上应是相互独立的 |
| 微服务之间横向关系 | 处理可发现性（自动感知变化）和可交互性（调用方式） |
| 微服务与数据层纵向约束 | 提倡 DSS（数据存储隔离），数据访问必须通过对应微服务 API |
| 全局分布式约束 | 全自动 CI/CD 流水线，支持蓝绿、金丝雀发布策略 |
1.5.4 无服务器（Serverless）4 大特点
- 全托管的计算服务：客户只编写代码，无须关注开发、运维、安全、高可用
- 通用性：结合 BaaS API 支撑云上所有重要类型应用
- 自动弹性伸缩：无须为资源使用提前容量规划
- 按量计费：成本有效降低，无须为闲置资源付费
关注点：计算资源弹性调度（容错、资源利用率、性能、数据驱动）、负载均衡和流控、安全性
1.5.5 服务网格（Service Mesh）
目的：将微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。
架构：服务 A 调用服务 B 的所有请求都被其下的服务代理截获，代理服务 A 完成到服务 B 的服务发现、熔断、限流等策略，控制平面（Control Plane）配置策略。
主要技术：Istio、Linkerd、Consul
1.6 实践案例
案例 1：电商大促场景的云原生实践
- 服务化：订单、商品、用户、支付拆分为微服务
- 弹性：K8s HPA 根据 CPU/流量自动扩缩容
- 韧性：Sentinel 限流熔断
- 可观测：Prometheus + Grafana + Jaeger
案例 2：Serverless 文件处理
- 用户上传文件 → 触发函数计算 → 处理完成后自动销毁
- 适用场景：图片压缩、日志分析、转码
2. 关键概念速查
| 概念 | 定义/说明 | 常见考点 |
|---|---|---|
| 云原生 | 基于云原生技术的架构原则和设计模式集合 | 7 大原则、6 大模式 |
| IDL | Interface Description Language | 接口契约 |
| DDD | Domain-Driven Design | 领域驱动设计 |
| TDD | Test-Driven Design | 测试驱动开发 |
| CAP | Consistency/Availability/Partition tolerance | 三选二 |
| 2PC | Two-Phase Commit | 两阶段提交 |
| TCC | Try-Confirm-Cancel | 业务侵入性强 |
| SAGA | 长事务拆分 | 补偿事务 |
| BASE | Basically Available/Soft state/Eventually consistent | 弱一致 |
| XA | 分布式事务规范 | 强一致但慢 |
| SEATA AT | 阿里分布式事务 | 自动回滚 |
| CQRS | Command Query Responsibility Segregation | 命令查询分离 |
| EDA | Event-Driven Architecture | 事件驱动 |
| Serverless | 无服务器 | 4 大特点 |
| Service Mesh | 服务网格 | Istio/Linkerd |
| HPA | Horizontal Pod Autoscaler | K8s 弹性伸缩 |
| 蓝绿发布 | Blue-Green Deployment | 两套环境切换 |
| 金丝雀发布 | Canary Release | 灰度发布 |
| DSS | Data Storage Segregation | 数据存储隔离 |
3. 典型例题（案例分析题）
例题 1：选择题（陷阱题）
题目：云计算无法为企业带来的改进是（ ）。
A. 通过 DevSecOps 应用开发模式，业务功能开发更加敏捷，提升迭代速度，成本更低 B. 企业软件架构可以获得强大的可伸缩性和高可用性 C. 结合云平台全方位企业级安全服务和安全合规能力，保障企业应用在云上安全构建 D. 企业的开发人员只须关注业务代码部分的开发，非业务功能可以完全委托给云原生架构来解决
参考答案：D 解析：云原生架构可以将非业务代码部分最大化剥离，让云设施接管大量非功能特性，但无法接管所有的非功能特性。
例题 2：选择题
题目：下列关于云原生架构原则的描述，错误的是（ ）。
A. 服务化原则、弹性原则、韧性原则 B. 可观测原则、所有过程自动化原则 C. 零信任原则、接口隔离原则 D. 架构持续演进原则
参考答案：C 解析：接口隔离原则是面向对象设计原则，不是云原生架构原则。
例题 3：选择题（陷阱题）
题目：关于微服务的描述，错误的是（ ）。
A. 微服务是将后端单体应用拆分为松耦合的多个子应用 B. 微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率 C. 微服务与数据层之间的纵向约束的含义是：在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的关系 D. 驾驭微服务的前提是高效运维整个系统，从技术上要准备全自动化的 CI/CD 流水线
参考答案：C 解析：可发现性和可交互性是横向关系。正确的纵向约束是：对于微服务的私有数据的访问都必须通过当前微服务提供的 API 来访问（DSS 数据存储隔离原则）。
例题 4：选择题
题目：无服务器技术的特点之一是全托管的计算服务：客户只需要编写代码构建应用，无须关注同质化的、负担繁重的基于服务器等基础设施的（ ）等工作。
A. 开发、测试、发布、交付 B. 开发、运维、安全、高可用 C. 机房建设、服务器装机、操作系统安装、软件安装 D. 资源调度、性能压测、负载均衡、数据统计
参考答案：B 解析：无服务器免去的是开发、运维、安全、高可用等负担。
例题 5：选择题
题目：容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受（ ）限制，在不同计算环境间快速、可靠地运行。
A. 环境 B. 操作系统 C. 硬件 D. 网络
参考答案：A 解析：B、C、D 都有局限性，A 最贴切——容器消除了对环境（OS、硬件、网络）的依赖。
4. 论文素材
本章是论文题出题范围，以下 3 个题目方向可以重点准备：
论云原生架构在企业数字化转型中的应用
- 写作要点：7 大原则、容器+编排、Serverless 实践
- 实战案例：从传统单体迁移到 K8s + 微服务的过程
论微服务架构的分布式事务处理方案选择
- 写作要点：CAP 理论、5 种事务模式对比、SEATA AT 实践
- 实战案例：电商订单+库存+支付的事务一致性
论云原生应用的可观测性体系构建
- 写作要点：Logging/Tracing/Metrics 三大支柱
- 实战案例：Prometheus + Grafana + Jaeger 监控体系
5. 高频考点
- 7 大原则：每年必考，零信任/接口隔离的区分
- 6 大架构模式：服务化/Mesh 化/Serverless/存储计算分离/分布式事务/事件驱动
- 5 种分布式事务模式对比：CAP 理论与 BASE 妥协
- 容器 vs 虚拟化：部署模式对比
- 微服务 4 大约束：横纵向约束区分
- Serverless 4 大特点：免去开发/运维/安全/高可用
- 可观测 3 大支柱：Logging/Tracing/Metrics
- Service Mesh 主要技术：Istio/Linkerd/Consul