所属篇章:下篇·案例分析考查形式:案例分析题 + 论文题难度等级:★★★★★(新教材重点章节,近年高频出题)
一、本章知识图谱
云原生架构├── 14.1 云计算基础(IaaS/PaaS/SaaS)├── 14.2 云原生核心概念├── 14.3 容器化技术(Docker/Kubernetes)├── 14.4 微服务架构设计├── 14.5 DevOps 与 CI/CD├── 14.6 Serverless 架构└── 14.7 典型案例分析二、核心考点详解
考点 1:云计算服务模型
| IaaS | ||||
| PaaS | ||||
| SaaS |
部署模型:公有云、私有云、混合云、社区云
考点 2:云原生核心概念
云原生(Cloud Native) 是专门为云环境设计和运行应用的方法论。
CNCF 定义的云原生技术栈:
- 容器化
Docker、containerd - 微服务
服务拆分、独立部署 - 服务网格
Istio、Linkerd - 声明式 API
Kubernetes 声明式配置 - 不可变基础设施
通过替换而非修改来更新
云原生 12 要素应用:
考点 3:容器化技术
3.1 Docker 核心概念
| 镜像(Image) | |
| 容器(Container) | |
| Dockerfile | |
| Registry |
3.2 Kubernetes(K8s)核心组件
控制平面:
| API Server | |
| etcd | |
| Controller Manager | |
| Scheduler |
工作节点:
| kubelet | |
| kube-proxy | |
| Container Runtime |
K8s 核心资源对象:
| Pod | |
| Deployment | |
| Service | |
| Ingress | |
| ConfigMap/Secret | |
| Namespace |
考点 4:微服务架构
微服务设计原则:
- 单一职责
每个服务围绕一个业务能力 - 自治性
独立开发、部署、扩展 - 去中心化
每个服务有自己的数据库 - 容错设计
熔断、降级、限流 - 可观测性
日志、指标、链路追踪
微服务关键模式:
| API 网关 | |
| 服务注册与发现 | |
| 断路器(Circuit Breaker) | |
| Saga 模式 | |
| CQRS | |
| 事件溯源 | |
| Sidecar |
考点 5:DevOps 与 CI/CD
DevOps 核心理念:开发(Dev)和运维(Ops)的协作与自动化。
CI/CD 流水线:
代码提交 → 构建 → 单元测试 → 代码扫描 → 打包 → 部署测试环境 → 集成测试 → 部署生产CI(持续集成):频繁合并代码,自动化构建和测试CD(持续交付/部署):自动化部署到各环境
考点 6:Serverless 架构
Serverless 特点:
无需管理服务器 按需自动伸缩 按执行量计费 事件驱动
两种形式:
| FaaS | ||
| BaaS |
三、案例分析题解析
【案例题】某互联网公司云原生改造
背景:某互联网公司原有单体应用部署在自建机房,面临发布周期长、扩展困难、运维成本高等问题。
问题:请设计云原生改造方案。
参考答案:
1. 应用拆分(微服务化)
将单体应用拆分为用户服务、订单服务、商品服务、支付服务等 每个服务独立数据库,通过 API 网关统一入口 使用消息队列实现服务间异步通信
2. 容器化部署
使用 Docker 将各服务打包为容器镜像 使用 Kubernetes 进行容器编排和管理 采用 Deployment + Service + Ingress 的标准部署模式
3. CI/CD 流水线
使用 GitLab CI / Jenkins 构建自动化流水线 代码提交后自动构建、测试、部署到测试环境 通过蓝绿部署或金丝雀发布上线生产环境
4. 可观测性体系
日志:ELK Stack 集中收集 指标:Prometheus + Grafana 监控 链路追踪:Jaeger / SkyWalking 全链路追踪
5. 容错设计
服务熔断:Sentinel / Hystrix 服务限流:令牌桶算法 服务降级:非核心功能自动降级
考点 7:服务网格(Service Mesh)
服务网格是微服务间通信的基础设施层,以 Sidecar 代理方式部署。
| 流量管理 | |
| 安全 | |
| 可观测性 | |
| 弹性 |
代表产品:Istio + Envoy、Linkerd
考点 8:云原生安全
云原生安全原则:
最小权限的容器运行 镜像扫描和签名验证 网络策略(Network Policy) 密钥管理(Vault、K8s Secrets) 运行时安全监控
考点 9:GitOps 与基础设施即代码
| IaC | ||
| GitOps | ||
| 配置管理 |
三、补充历年真题解析
真题 2022 年·综合知识
题目:在 Kubernetes 中,Pod 的最小调度单位是( )。
A. 容器 B. Pod C. Node D. Namespace
答案:B
解析:Pod 是 Kubernetes 的最小调度单位,一个 Pod 可以包含一个或多个容器,这些容器共享网络和存储。容器不是调度单位(A 错),Node 是运行 Pod 的机器(C 错)。
真题 2023 年·综合知识
题目:以下关于 Serverless 架构的叙述中,不正确的是( )。
A. 无需管理服务器B. 按执行时间计费C. 适合长时间运行的任务D. 自动伸缩
答案:C
解析:Serverless(如 AWS Lambda)通常有执行时间限制(通常不超过 15 分钟),不适合长时间运行的任务。Serverless 适合事件驱动、短时执行的场景。
真题 2023 年·案例分析
题目:某企业计划将单体应用迁移到云原生架构。请从容器化、服务拆分、CI/CD、可观测性四个方面设计迁移方案。
参考答案:
1. 容器化
将各服务打包为 Docker 容器镜像 使用多阶段构建减小镜像体积 镜像推送到私有 Registry
2. 服务拆分
基于 DDD 限界上下文拆分服务 每个服务独立数据库 使用 API 网关统一入口 服务间通过 gRPC 或消息队列通信
3. CI/CD
Git 提交触发自动构建和测试 使用 GitOps 方式管理部署(ArgoCD) 蓝绿部署或金丝雀发布
4. 可观测性
日志:Fluentd + Elasticsearch + Kibana 指标:Prometheus + Grafana 追踪:Jaeger 或 OpenTelemetry
考点 10:云原生架构原则
教材提出的云原生架构设计原则:
- 服务化原则
将应用拆分为独立服务 - 弹性原则
系统能够自动伸缩和容错 - 可观测原则
日志、指标、追踪全面覆盖 - 韧性原则
系统能够抵抗故障并自动恢复 - 所有过程自动化
CI/CD、自动伸缩、自动修复 - 零信任原则
不信任任何网络位置 - 架构持续演进
小步快跑、持续迭代
考点 11:主要云原生架构模式
| 聚合器微服务 | ||
| 代理微服务 | ||
| 链式微服务 | ||
| 分支微服务 | ||
| 事件驱动微服务 | ||
| 数据共享微服务 |
考点 12:典型云原生架构反模式
| 单体应用 | ||
| 分布式单体 | ||
| 数据库共享 | ||
| 服务粒度不当 | ||
| 忽视可观测性 | ||
| 缺乏弹性设计 |
四、补充历年真题解析
真题 2022 年·综合知识
题目:以下关于云原生架构反模式的叙述中,正确的是( )。
A. 分布式单体是推荐的架构模式B. 多个微服务共享同一数据库是良好的实践C. 服务粒度应基于 DDD 限界上下文确定D. 云原生架构不需要可观测性
答案:C
解析:服务粒度应基于 DDD 限界上下文确定,避免过细或过粗。分布式单体是反模式(A 错),数据库共享也是反模式(B 错),可观测性是云原生的核心原则(D 错)。
真题 2021 年·综合知识
题目:以下关于微服务架构的叙述中,正确的是( )。
A. 微服务必须使用相同的编程语言B. 每个微服务应该有独立的数据库C. 微服务间必须采用同步通信D. 微服务架构不需要服务注册与发现
答案:B
解析:微服务架构的核心原则是每个服务拥有独立的数据库,避免服务间的数据耦合。微服务可以使用不同语言(A 错),可以用异步通信(C 错),服务注册与发现是必需的(D 错)。
真题 2023 年·案例分析
题目:某电商平台的订单服务在促销期间出现级联故障,导致整个系统不可用。请分析可能的原因并提出解决方案。
参考答案:
问题分析:
订单服务依赖的下游服务(库存、支付)响应超时 未实施熔断机制,导致故障级联扩散 缺乏限流措施,流量超过系统承载能力 无降级策略,所有请求都走完整流程
解决方案:
- 熔断器模式(Circuit Breaker)
当下游服务失败率达到阈值时自动熔断,快速返回默认响应 - 限流
令牌桶算法限制请求速率,保护后端服务 - 服务降级
促销高峰期简化非核心功能(如评论、推荐) - 异步处理
将订单创建放入消息队列异步处理 - 超时与重试
设置合理超时时间,指数退避重试
四、补充考点
考点 11:容器编排与 Kubernetes 进阶
K8s 网络模型:每个 Pod 独立 IP、所有容器共享 Pod 网络、Pod 间可直接通信
考点 12:服务网格(Service Mesh)
核心能力:流量管理(金丝雀发布、A/B测试)、安全(mTLS双向认证)、可观测性(Tracing/Metrics)
流量镜像(Mirroring):将生产流量复制到新版本服务进行测试,不影响用户响应
考点 13:GitOps 与云原生 CI/CD
GitOps 工作流:开发者 Push 代码 → CI 构建镜像 → 更新 Git 仓库中的 K8s manifest → ArgoCD 自动同步部署
考点 14:可观测性(Observability)
Prometheus 架构:Pull 模型拉取指标 → TSDB 存储 → PromQL 查询 → Alertmanager 告警
分布式追踪核心:TraceID(全局唯一)+ SpanID(单个操作)实现全链路追踪
考点 15:Serverless 架构深入
冷启动优化:减小包体积、预置并发、运行时优化、层(Layers)复用
真题 2022 年·综合知识
题目:在 Kubernetes 中,关于 Service Mesh 的叙述正确的是( )。
A. Service Mesh 要求每个服务自行处理服务发现和负载均衡B. Service Mesh 通过 Sidecar 代理透明拦截服务间通信C. Service Mesh 只能处理 HTTP 协议流量D. Service Mesh 的控制平面负责实际数据转发
答案:B
解析:Service Mesh 通过在每个 Pod 中注入 Sidecar 代理(如 Envoy)透明拦截所有入站/出站流量。服务发现/负载均衡由 Mesh 处理(A 错),支持多协议(C 错),控制平面负责策略和配置下发,数据平面负责实际转发(D 错)。
真题 2023 年·综合知识
题目:以下关于可观测性三大支柱的叙述中,正确的是( )。
A. 日志、指标、链路追踪三者互相独立,无法关联B. 链路追踪中的 TraceID 用于标识单个操作C. Prometheus 采用 Push 模型采集指标数据D. 三大支柱结合可全面掌握分布式系统运行状态
答案:D
解析:可观测性三大支柱(Logging/Metrics/Tracing)结合可全面观察系统状态。三者可关联(A 错),TraceID 标识全链路,SpanID 标识单个操作(B 错),Prometheus 采用 Pull 模型(C 错)。
真题 2022 年·案例分析
题目:某公司计划将单体应用迁移到云原生架构,请设计迁移策略。
参考答案:
- 绞杀者模式(Strangler Fig)
逐步剥离单体功能到微服务,而非一次性重写 - 容器化打包
将单体应用 Docker 化,部署到 K8s - 数据库拆分
逐步将共享数据库拆分为服务独立数据库 - API 网关
在单体和新微服务间统一入口,透明路由 - 双写策略
迁移期间同时写入新旧数据库,确保数据一致性 - 可观测性建设
部署 Prometheus + Grafana + Jaeger,确保迁移过程可监控
五、本章小结
- 云服务模型
IaaS/PaaS/SaaS 的区分 - 云原生要素
容器化、微服务、DevOps、声明式 API - Kubernetes
控制平面和工作节点的核心组件 - 微服务模式
API 网关、断路器、Saga、CQRS - CI/CD
持续集成和持续交付的流水线设计 - Serverless
FaaS 和 BaaS 的特点,冷启动优化 - Service Mesh
Istio/Envoy,Sidecar 模式,流量管理 - GitOps
Git 为唯一真实来源,ArgoCD 自动同步 - 可观测性
日志/指标/链路追踪三大支柱 - 迁移策略
绞杀者模式、容器化、双写策略
夜雨聆风