4.8 云原生架构
一句话讲明白
云原生＝应用从生下来就为云而设计：把弹性、韧性、安全、可观测这些"非业务"的活儿尽量甩给云平台，让业务代码又轻又快又能自动上线。
生活类比
开餐厅的两种方式：传统方式是自己盖厨房、买炉灶、雇维修工、自己盯着冰箱温度（传统架构，非功能性事务全自己扛）；云原生方式是进驻美食广场——水电、排烟、消防、收银、清洁由广场统一提供（云设施接管非功能特性），你只管把菜炒好（业务代码），客流暴涨时广场自动给你加窗口（弹性）。
正经定义
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰，具备轻量、敏捷、高度自动化的特点。
拆解与流程
一、发展概述（瀑布 → 敏捷 → DevOps → 云原生）
传统"瀑布式"开发造成上下游信息不对称、周期长；敏捷开发只解决了开发效率和版本速度，未打通运维；DevOps 是开发、技术运营和质量保障三者的交集，促进沟通协作与整合；云原生的容器、微服务等技术正是 DevOps 的前提条件，使持续交付成为可能。云原生还从一开始就与开源生态结合，并广泛应用于边缘计算、高性能计算（HPC）、AI、大数据场景。
二、架构定义：三大变化
- 代码结构发生巨大变化：云把三方软硬件能力升级为服务（对象存储、块存储、文件存储等），开发人员不再需要处理分布式网络、高可用、扩缩容等复杂问题。
- 非功能性特性大量委托：高可用交给虚拟机（底层硬件异常时热迁移）、容器（进程异常时节点下线/上线、流量切换）、云服务（有状态交给云服务 → 应用变"无状态"，中断降至分钟级）。
- 高度自动化的软件交付：容器以标准方式打包，屏蔽环境差异，以"面向终态"的方式完成安装、配置、运行和变更。 - 云原生的代码＝业务代码 + 三方软件 + 处理非功能特性的代码，只有业务代码是真正带来价值的核心。
三、基本原则（7 条，必背）
| 原则 | 一句话 |
|---|---|
| 服务化原则 | 代码规模超出小团队范围就拆分（微服务/小服务 MiniService），按生命周期分别迭代；是基于服务流量（非网络流量）做限流降级、熔断隔仓、灰度、反压、零信任的前提 |
| 弹性原则 | 部署规模随业务量自动伸缩，无需按容量规划准备固定资源，缩短采购上线周期、降低闲置成本 |
| 可观测原则 | 通过日志、链路跟踪和度量主动呈现一次点击背后的多次服务调用，下钻到三方调用、SQL、节点拓扑、网络响应 |
| 韧性原则 | 抵御软硬件异常的能力，核心目标是提升 MTBF（平均无故障时间）；含服务异步化、重试/限流/降级/熔断/反压、主从、集群、AZ 内高可用、单元化、跨 region 容灾、异地多活 |
| 所有过程自动化原则 | 通过 IaC、GitOps、OAM、Kubernetes Operator 与 CI/CD 流水线实现交付与运维自动化 |
| 零信任原则 | 默认不信任网络内外任何人/设备/系统，以身份为中心重构访问控制，从"网络中心化"走向"身份中心化" |
| 架构持续演进原则 | 架构本身必须具备持续演进能力，存量应用迁移要权衡迁出/迁入成本与风险 |
四、常用架构模式（7 种，必背）
- 服务化架构模式：以应用模块为颗粒度划分软件，以接口契约（IDL）定义业务关系，以标准协议（HTTP、gRPC）互联互通；典型是微服务和小服务（MiniService，一组关系密切、共享数据的服务）模式。
- Mesh 化架构模式：把中间件框架（RPC、缓存、异步消息）从业务进程分离，SDK 与业务代码解耦，业务进程只保留很"薄"的 Client，流量控制、安全等由 Mesh 进程完成。
- Serverless 模式：把"部署"从运维中收走，业务流量/事件到来时云启动或调度进程，处理完自动关闭。适合事件驱动的数据计算、计算时间短的请求/响应、无复杂互调用的长周期任务；不适合有状态应用、长时间后台运行的密集型计算任务、频繁外部 I/O 的应用。
- 存储计算分离模式：无状态应用不存在 CAP 中的 C 维度，可获得更好的 A 与 P（弹性）；暂态数据与持久数据尽量用云服务保存。
- 分布式事务模式：XA（强一致、性能差）、基于消息的最终一致性（高性能、通用性有限）、TCC（Try-Confirm-Cancel，隔离性可控、效率高，但对业务侵入强）、SAGA（每个正向事务对应一个补偿事务）、SEATA 的 AT 模式（高性能、零代码、自动回滚，但有场景限制）。
- 可观测架构：Logging（多级别详细跟踪）+ Tracing（请求全链路跟踪）+ Metrics（多维度度量）；目标是度量 SLO 从而优化 SLA。
- 事件驱动架构（EDA）：事件有 Schema 可校验，具备 QoS 保障与失败响应；用于增强服务韧性、CQRS（命令查询责任分离）、数据变化通知、构建开放式接口、事件流处理、事件触发响应。
五、案例要点：某快递公司核心业务上云
原架构 VMware + Oracle；改造三步：引入云原生数据库（OLTP 与 OLAP 拆分）、应用容器化（环境一致、提效）、微服务改造（按业务域拆分，用 Kubernetes 服务发现替代 OGG 同步）。架构分层：基础设施（裸金属服务器 + Kubernetes）→ 流量接入（云 DNS/PrivateZone + Ingress）→ 平台层（打通 DevOps、资源隔离、日志/链路/Metrics 集成）→ 应用服务层（每应用独立 Namespace）→ 运维管理（托管版容器服务）。效益：成本（按需付费）、稳定性（云产品提供 5 个 9＝99.999% 以上 SLA）、效率（持续集成缩短至分钟级）、赋能业务。业务体量：日订单千万量级、亿级物流轨迹、TB 级日增数据、1300+ 计算节点。
考试怎么考
- 题型：选择高频（7 原则、7 模式几乎是每年原题）；案例可能考"传统应用上云改造要从哪几方面入手"。
- 必背：7 原则（服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进）；7 模式；Serverless 适用与不适用；DevOps 是开发/技术运营/质量保障三者的交集；SLA 99.999%。
- 常见问法：
- "云原生架构原则有哪些？"→ 7 条全选（干扰项常故意漏掉"可观测""韧性"）。
- "Serverless 不适合哪类应用？"→ 有状态、长时间后台密集计算、频繁外部 I/O。
- "DevOps 指哪三者的交集？"→ 开发、技术运营、质量保障。
- 陷阱词：把"所有过程自动化"漏掉；把可观测等同于"监控/APM"（教材明确说不同）；把零信任说成"内网可信"。
易混辨析
| 对比 | 微服务 | 小服务 MiniService |
|---|---|---|
| 颗粒度 | 更细 | 一组关系密切的服务的组合，共享数据 |
| 适用 | 通用 | 非常大型的软件系统，避免接口过细导致调用损耗与治理复杂度 |
| 对比 | 弹性 | 韧性 |
|---|---|---|
| 管什么 | 规模随业务量伸缩 | 异常下的持续服务能力 |
| 指标 | 资源利用率、上线周期 | MTBF、容灾级别 |
一秒记忆
"服弹观韧自零演"（服务化、弹性、可观测、韧性、自动化、零信任、演进）——七原则； "服、网、无、存、事、观、件"（服务化、Mesh、Serverless、存储计算分离、分布式事务、可观测、事件驱动）——七模式； 云原生代码："业务代码是主角，另外两个是配角"。