主讲：老孙
适用：2026年下半年系统规划与管理师考试
预计阅读时间：45分钟
一、上节回顾
信息安全规划两讲讲完了。
今天进入 云原生系统规划——阶段二的倒数第二讲。
1.1 上一讲思考题点评
我看到一份精彩的"应急预案"作业，来自一位制造业 CIO：
"用 4 阶段方法重新设计我们工厂的应急预案——每年 2 次演练 + 4 级事件分级 + 跨部门协同，让我们应急能力提升一个档次。"
这就是规划师的视角——把方法论变成可执行的预案。
二、本讲导读
2.1 学习目标
学完这一讲，你应该能够：
- 【是什么】 准确说出云原生的 4 大特征、12 大要素；说出容器、K8s、微服务、Service Mesh 的核心理念。
- 【为什么】 理解为什么云原生是"现代应用架构的标配"。
- 【怎么用】 能为清华园物业评估"是否需要云原生"。
2.2 本讲在课程地图中的位置
本讲对标教材 第10章 云原生系统规划——阶段二的倒数第二讲。
【虚构案例提示】 本讲涉及"智慧邻里2.0项目""清华园物业""北京知知致用信息技术有限公司"均为培训教学所用的虚拟项目与虚构人物（详见第01讲首次案例声明）。
三、云原生：从"大教堂"到"乐高城"
3.1 云原生是什么
云原生（Cloud Native）：专为云环境设计的应用架构和开发理念。
CNCF（云原生计算基金会）定义：
云原生技术使组织能在公有云、私有云、混合云等动态环境中，构建和运行可弹性扩展的应用。代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
3.2 云原生的"4 大核心特征"
特征 1：容器化
应用打包为容器，标准化部署。
特征 2：微服务
把单体应用拆解为多个独立服务。
特征 3：DevOps
开发与运维一体化。
特征 4：持续交付
自动化、高频次发布。
4 大特征是必背考点。
3.3 云原生 vs 传统应用
| 维度 | 传统应用 | 云原生应用 |
|---|---|---|
| 部署 | 物理机/虚拟机 | 容器 |
| 架构 | 单体 | 微服务 |
| 发布 | 月度/季度 | 每天多次 |
| 扩展 | 垂直扩展 | 水平扩展 |
| 故障 | 影响大 | 单服务故障可隔离 |
| 升级 | 停机维护 | 滚动升级 |
| 类比 | 大教堂 | 乐高城 |
云原生是现代应用架构的标配。
四、容器与 Kubernetes
4.1 容器是什么
容器（Container）：轻量级、可移植的应用打包技术。
与虚拟机对比：
| 维度 | 虚拟机 | 容器 |
|---|---|---|
| 大小 | GB 级 | MB 级 |
| 启动 | 分钟级 | 秒级 |
| 隔离 | 强（独立 OS） | 弱（共享 OS） |
| 性能损耗 | 大 | 小 |
Docker 是容器的事实标准——必须知道。
4.2 Kubernetes（K8s）
Kubernetes：容器编排平台，源自 Google 内部 Borg 系统，2014 年开源。
K8s 的核心能力：
- 容器调度
- 自动扩缩容
- 滚动升级
- 服务发现
- 健康检查
- 配置管理
K8s 是云原生的"操作系统" ——必须掌握基本概念。
4.3 K8s 的核心概念
Pod：最小调度单位
Service：服务抽象，提供稳定 IP
Deployment：管理应用部署
Namespace：资源逻辑隔离
ConfigMap/Secret：配置和密钥
这是 2024 年新增重点考点。
五、微服务架构
5.1 微服务是什么
微服务（Microservices）：把单体应用拆解为多个独立可部署的小服务，每个服务围绕业务能力构建。
5.2 微服务的"6 大特征"
特征 1：服务独立
每个服务独立部署、独立扩展
特征 2：业务边界清晰
按业务能力划分服务
特征 3：技术栈灵活
不同服务可用不同语言/数据库
特征 4：去中心化数据
每个服务有自己的数据库
特征 5：自动化
自动构建、测试、部署
特征 6：容错设计
故障隔离、降级、限流
6 大特征是必考点。
5.3 微服务 vs 单体
| 维度 | 单体应用 | 微服务 |
|---|---|---|
| 复杂度（小型） | 低 | 高 |
| 复杂度（大型） | 高 | 中 |
| 扩展性 | 弱 | 强 |
| 故障影响 | 大 | 小 |
| 团队协作 | 难 | 易 |
| 运维成本 | 低 | 高 |
关键决策：小型项目用单体，大型项目用微服务。不要盲目微服务。
5.4 微服务的"陷阱"
新手做微服务常犯的错：
陷阱 1：拆得过细（500 个服务）
陷阱 2：服务间强耦合
陷阱 3：数据库共享
陷阱 4：缺乏统一治理
陷阱 5：运维负担爆炸
避开 5 大陷阱 = 微服务成功。
六、Service Mesh 服务网格
6.1 Service Mesh 是什么
Service Mesh（服务网格）：处理服务间通信的基础设施层。
核心能力：
- 流量管理
- 安全（mTLS）
- 可观测性
- 策略控制
典型产品：Istio、Linkerd、华为 ASM
6.2 Service Mesh 解决什么问题
传统微服务问题：
- 每个服务自己实现限流、熔断、监控
- 业务代码与基础设施代码混杂
- 难以统一治理
Service Mesh 把这些能力下沉到基础设施层——业务代码专注业务。
这是 2024 年新增重点考点。
七、云原生的"12 要素应用"
7.1 12 要素应用方法论
12 Factor App 是云原生应用设计的经典方法论：
- 基准代码
- 依赖
- 配置
- 后端服务
- 构建发布运行
- 进程
- 端口绑定
- 并发
- 易处理
- 开发-生产环境等价
- 日志
- 管理进程
12 要素是 2024 年新增重点考点。
7.2 12 要素的核心思想
- 配置与代码分离
- 无状态化
- 进程独立
- 日志流式输出
12 要素让应用"云友好"。
八、云原生规划的实战
8.1 云原生的"适用性评估"
不是所有项目都适合云原生：
适合云原生的场景：
- 业务变化快
- 弹性需求大
- 团队规模较大
- 长期演进项目
不适合云原生的场景：
- 小型项目
- 业务稳定
- 团队小
- 短期项目
清华园物业：项目偏中型，适合"轻量云原生"——容器化 + 部分微服务。
8.2 云原生的"成熟度模型"
L1 容器化：
- 应用打包为容器
- 简单的容器编排
L2 微服务化：
- 应用拆解为微服务
- 服务发现、API 网关
L3 服务网格化：
- 引入 Service Mesh
- 自动化治理
L4 全面云原生：
- DevSecOps 全自动化
- 自动化扩缩容
- 自动化运维
国内大多数企业在 L1-L2——这是发展空间。
8.3 案例锚点：清华园物业的云原生
清华园物业的云原生策略：
- 容器化：业主 APP、缴费、报修都用 Docker 容器
- 微服务：拆为 5 个核心服务（业主、缴费、报修、安防、增值）
- 不上 Service Mesh：规模不够，运维负担大
- 不上 K8s：用阿里云容器服务 ACK 托管
这是中型企业的"理性云原生"——不盲目追新。