17-云原生架构设计实践

Mon, 01 Jan 2024 00:00:00 +0000

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

云原生 on Liangweidong's blog