系规第10章：云原生系统规划完整学习笔记
学习目标
云原生不是“上云＋容器”的新名称，而是面向云重新设计应用架构、交付流程和运行方式，让弹性、韧性、安全、可观测和自动化成为平台能力。本文按教材10.1—10.4逐节展开。
这是“系规学习”的第7期。第10章篇幅不算最长，但“七原则、七模式、五步骤”很适合综合题和案例题。学习时抓住：为什么云原生—怎样设计—有哪些模式—按什么顺序建设。
本章地图：概念、原则、模式、路线
- 10.1 发展背景：云原生、12要素、DevOps和DevSecOps。
- 10.2 技术架构：定义、七项原则、七种模式和六项优势。
- 10.3 建设规划：顶层规划、分步实施的五步路线。
- 10.4 实践案例：按业务特征选择架构和迁移方式。
本章先澄清四个误区
- 使用云主机不等于云原生，应用仍可能是难扩展的传统单体。
- 使用容器不等于微服务，单体应用也能被装进容器。
- 拆成微服务不一定更敏捷，边界错误会带来调用、事务和治理复杂度。
- DevOps不只是工具流水线，核心是跨团队协作、快速反馈与持续改进。
10.1 发展背景：云原生到底“原生”在哪里
概念演进
早期云原生常与12要素、微服务、自服务、API协作、抗脆弱性联系。2015年CNCF成立后，容器、编排和微服务逐渐形成生态。2017年前后常用DevOps、持续交付、微服务、容器概括云原生；随后服务网格、不可变基础设施、声明式API、可观测性等被纳入。
CNCF语境下，云原生强调：
- 基于容器、服务网格、微服务、不可变基础设施和声明式API构建弹性应用
- 通过自动化形成高容错、易管理、可观察的松耦合系统
- 建立开放生态，使应用与具体云厂商服务适度解耦。
- 要素的学习重点
- 要素用于指导适合云平台的应用设计，核心思想包括代码基线统一、依赖显式声明、配置与代码分离、后端服务资源化、构建发布运行分离、无状态进程、端口绑定、水平扩展、快速启停、开发生产一致、日志事件流和管理任务一次性运行。
考试不一定要求逐字背全，但要理解其方向：无状态、配置外置、环境一致、自动交付、易扩展。
DevOps与DevSecOps
DevOps通过开发和运维协作，以自动化流水线和快速反馈缩短交付周期。可用“五个持续”理解其闭环：
- 持续集成
- 持续部署
- 持续交付
- 持续监控
- 持续反馈。
DevSecOps把安全嵌入需求、设计、编码、构建、测试、部署和运营全过程。安全不再是上线前最后一次检查，而是开发、测试、运维和安全团队共同责任。
10.2.1—10.2.2 架构定义与七项原则
云原生架构是一组面向云的架构原则和设计模式，其关键是把弹性、韧性、安全、可观测、灰度等非业务能力尽量从业务代码剥离，交给云基础设施和平台，从而让业务代码更专注业务价值。
七项设计原则
- 服务化：按生命周期和业务边界拆分单元，以接口契约协作，使服务可独立迭代和水平扩展。
- 弹性：部署规模随业务量自动伸缩，不再只依赖固定容量预留。
- 可观测：通过日志、链路追踪和指标主动理解分布式系统内部状态。
- 韧性：依赖组件异常时系统仍能抵御、降级、隔离和恢复。
- 所有过程自动化：通过声明式配置、面向终态交付，实现构建、部署、配置、运维自动化。
- 零信任：默认不信任内外部主体，以身份为中心持续认证、授权和控制访问。
- 架构持续演进：架构允许随业务、技术和反馈持续变化，而不是一次设计永久冻结。
记忆骨架：服、弹、观、韧、自、零、演。
最容易混淆的三组
- 弹性关注负载变化时“规模能否自动调整”；韧性关注故障发生时“系统能否承受和恢复”。
- 监控采集预先定义的状态；可观测性希望从日志、追踪和指标推断未知问题的内部原因。
- 自动化不是写几个脚本，而是以标准、声明式、可重复方式把全过程交给平台执行。
10.2.3 七种架构模式：不同问题需要不同解法
- . 服务化架构
以应用模块为粒度划分软件，用接口契约定义关系、标准协议互通，并结合DDD、测试驱动和容器化提高独立交付能力。典型形态：
- 微服务：粒度较小、独立部署、数据自治
- 小服务：一组关系紧密且可能共享数据的服务组合，避免超大型系统拆得过细。
拆分依据应是业务边界与生命周期，而不是按技术层或开发人数机械拆分。
- . Mesh化架构
服务网格把通信、路由、熔断、安全等中间件能力从业务进程剥离到代理层，使SDK与业务代码解耦，便于跨语言治理和统一升级。它解决的是服务间通信治理，不替代业务服务设计。
- . Serverless
Serverless把服务器配置、容量和部署细节交给平台，开发者聚焦函数或业务逻辑。适合事件驱动、突发负载、短时任务等场景，但并非适用于所有应用；长时间运行、强状态、极端低时延或需要深度环境控制时需谨慎。
- . 存储计算分离
把有状态存储与无状态计算解耦。计算节点更容易弹性扩缩和替换，数据交由独立存储服务保障持久性、可用性和扩展。无状态应用不涉及自身数据副本一致性，更容易获得良好可用性和分区容错能力。
- . 分布式事务
微服务通常拥有私有数据源，一个业务跨多个服务时会出现一致性问题。架构师应根据一致性、可用性、性能和业务补偿能力选择事务模式，不能沿用单库事务思路强行覆盖全部场景。
- . 可观测架构
三大支柱：
- Logging：事件与详细上下文
- Tracing：请求跨服务的完整调用链
- Metrics：系统量化指标。
目标是度量SLO并优化SLA。应定义并发度、耗时、可用时长、容量、错误率等服务目标。
- . 事件驱动架构
EDA通过带有Schema和服务质量保障的事件实现组件解耦，可用于增强韧性、CQRS、数据变化通知、开放接口、事件流处理和事件触发响应。
口诀：服、网、无、分、事、观、驱，对应服务化、Mesh、Serverless、存算分离、分布式事务、可观测、事件驱动。
六项优势
云原生具有高可扩展性、高可用性、灵活性、安全性、成本效益和高度自动化等优势。但优势不是自动获得的：错误拆分、治理缺失、成本不可见或安全责任不清，反而会增加复杂度。
10.3 建设规划：五步路线不能颠倒
教材提出“顶层规划＋分步实施”的五步路线：
- 微服务采用及运行环境容器云平台构建
- 服务管理和治理
- 持续交付及安全
- 自服务敏捷响应基础设施
- 增强生产环境韧性和安全性。
第一步：微服务＋容器云
- 识别适合改造的系统和业务边界
- 使用DDD等方法拆分服务，不追求服务越小越好
- 建设容器与编排平台，提供部署、资源调度、健康检查、故障恢复和弹性
- 规划服务器、存储、网络、培训和迁移项目
- 可参考主数据和通用数据模型设计可复用服务。
容器平台和微服务改造可以分别立项并多次迭代。不要一次性重写所有系统。
第二步：服务管理和治理
建设注册发现、配置、路由、负载均衡、限流、熔断、弹性和API治理。Kubernetes、Service Mesh或相关框架可提供不同层次能力。
要区分：
- 微服务API主要支撑服务内部协作
- OpenAPI通过API网关面向跨平台、跨组织或生态开放。
第三步：持续交付及安全
以DevOps构建持续集成、部署、交付、监控、反馈闭环，同时把认证权限、代码扫描、依赖检查、镜像检查、容器、接口和运行时安全嵌入流水线，形成DevSecOps。
第四步：自服务敏捷基础设施
基础设施可分为：
- 基础设施资源：统一封装异构云、计算、存储和网络
- 支撑平台：容器云、持续交付等开发运行运维平台
- 纯技术工具：消息、日志、配置、监控、告警、认证、权限、调度、AI等公共服务。
通过门户、目录、模板和API让团队按规则自助获取能力，减少人工工单和重复建设。
第五步：增强生产韧性和安全
通过故障注入、混沌工程、限流降级、隔离、备份恢复和应急演练主动发现弱点并修复。混沌工程不是在生产环境随意制造事故，而是在边界、监控、回滚和授权明确的条件下验证假设。
安全同样持续演进：设计时减少漏洞，流水线中检测，运行时防护，事件后复盘。
10.4 案例、三门考试与闭卷自测
案例常见问题
- 为追求“先进”一次性拆分所有系统，没有业务优先级和迁移路线
- 只建容器平台，没有微服务治理、可观测和持续交付
- 服务颗粒度过细，调用链和分布式事务失控
- 共享数据库导致服务耦合，或私有数据源后没有一致性策略
- 仅有CPU监控，没有日志、追踪、SLO和业务指标
- 流水线速度很快，却没有代码、镜像、权限和运行时安全
- 扩容依靠人工，公共能力仍通过工单申请
- 从未做故障演练，所谓高可用只存在设计文档中。
综合题
重点识别：
- 云原生概念和DevOps/DevSecOps
- 七项原则及弹性、韧性、可观测区别
- 七种架构模式的场景
- Logging、Tracing、Metrics
- 五步实施路线和每一步能力。
案例题答题模板
- 从业务价值和现状评估确定改造范围与优先级
- 按领域边界拆分服务并建设容器运行平台
- 建设注册发现、配置、流量、API和服务网格治理
- 构建CI/CD和DevSecOps，统一制品与环境
- 建立日志、追踪、指标和SLO
- 沉淀可自助获取的公共技术服务
- 通过弹性、隔离、降级、混沌演练和安全运营增强生产韧性
- 分阶段迁移、度量成效并持续演进。
论文
可按“背景痛点—现状评估—目标架构—七原则应用—五步路线—风险控制—成效指标—持续演进”组织。应写清旧系统如何渐进迁移、如何处理数据与事务、如何保证业务连续，不能只罗列容器和微服务名词。
闭卷自测
- 云原生与普通上云、容器化有什么区别？
- DevOps和DevSecOps的核心是什么？
- 七项设计原则是什么？
- 如何区分弹性、韧性和可观测？
- 七种架构模式分别解决什么问题？
- Logging、Tracing、Metrics分别提供什么能力？
- 云原生五步建设路线是什么？
- 微服务API和OpenAPI有什么区别？
- 自服务敏捷基础设施包括哪三部分？
- 为什么混沌工程要放在能力成熟后受控开展？
写在最后
第10章的稳定骨架是：
七项原则控制方向，七种模式解决问题，五步路线安排建设顺序。
云原生转型真正改变的是架构、组织协作、交付流程和运营方式。第一轮先背“服弹观韧自零演”和五步路线；第二轮再补七种模式、可观测与每一步的实施细节。
我是陈文茂，正在用自己的方式重新整理系统规划与管理师学习资料。
如果这篇对你有帮助，欢迎点赞、在看、转发。