☁️ 第六章 · 云原生架构
云原生架构
本章涵盖云计算服务模型、微服务架构、容器化技术、Kubernetes编排、Service Mesh、Serverless和DevOps等新兴技术考点，占综合知识考试7%-13%的分值。云原生是近年新增热门考点。
7%-13%考试分值占比
8知识模块
★★★★★重要程度
15章节测验题
云计算服务模型
核心考点📊IaaS / PaaS / SaaS 对比
| 对比维度 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 全称 | Infrastructure as a Service | Platform as a Service | Software as a Service |
| 中文 | 基础设施即服务 | 平台即服务 | 软件即服务 |
| 提供内容 | 虚拟机、存储、网络 | 运行环境+中间件+开发工具 | 完整的应用软件 |
| 用户管理 | OS及以上全部 | 应用+数据 | 仅配置和使用 |
| 云厂商管理 | 虚拟化层+硬件 | OS+中间件+运行时 | 全部 |
| 灵活性 | 最高 | 中 | 最低 |
| 典型产品 | AWS EC2、阿里云ECS | Heroku、Google App Engine | Office 365、钉钉、Salesforce |
| 适合人员 | 运维工程师 | 开发人员 | 终端用户 |
管理责任边界（常考）：从IaaS到SaaS，云厂商管理的层级越来越多，用户管理的层级越来越少。IaaS用户管理OS及以上；PaaS用户只需管理应用和数据；SaaS用户只负责配置和使用。
IaaS / PaaS / SaaS 责任边界图
SaaS — 云厂商管理全部｜用户仅使用
PaaS — 云厂商管理运行时+中间件｜用户管理应用+数据
IaaS — 云厂商管理虚拟化+硬件｜用户管理 OS 及以上
云厂商管理范围 ↑ —— 用户管理范围 ↓
🏢云部署模式
公有云：云服务商拥有基础设施，多租户共享资源。优点：成本低、弹性好。缺点：数据安全风险。适合：互联网应用、初创企业
私有云：企业自建或专属的云基础设施。优点：数据安全、可控性强。缺点：成本高、运维复杂。适合：金融机构、政府
混合云：公有云+私有云的组合。核心数据在私有云，弹性计算在公有云。适合：大多数中大型企业
社区云：多个具有共同关注点的组织共享。如行业联盟云
微服务核心组件
★★★★★🗺️微服务核心组件全景
| 组件类型 | 功能 | 典型产品 | 说明 |
|---|---|---|---|
| API网关 | 统一入口、路由转发、限流、认证 | Spring Cloud Gateway、Kong、Nginx | 所有外部请求的第一道关卡 |
| 服务注册发现 | 服务自动注册与发现 | Nacos、Consul、Eureka | 服务上线自动注册，下线自动摘除 |
| 配置中心 | 集中管理配置，支持热更新 | Nacos Config、Apollo、Spring Cloud Config | 避免配置硬编码，支持环境隔离 |
| 熔断降级 | 防止服务雪崩、故障隔离 | Sentinel、Hystrix、Resilience4j | 快速失败、服务降级保护 |
| 负载均衡 | 流量分配到多个服务实例 | Ribbon（客户端）、Nginx（服务端） | 轮询、加权、一致性哈希等策略 |
| 链路追踪 | 追踪跨服务调用链路 | SkyWalking、Zipkin、Jaeger | TraceID串联调用链，定位性能瓶颈 |
🔒熔断器模式详解
关闭状态（Closed）：正常状态，请求正常转发。持续监控失败率
打开状态（Open）：失败率达到阈值后，熔断器打开，请求直接返回错误（快速失败），不调用下游服务。经过设定的时间后进入半开状态
半开状态（Half-Open）：允许少量请求通过，如果成功则关闭熔断器，如果失败则重新打开
熔断器三状态（常考）：关闭（Closed）→ 打开（Open）→ 半开（Half-Open）。这是熔断器的标准状态转换流程。
熔断器三状态转换图
Closed
关闭
关闭
→
失败率
超阈值
超阈值
Open
打开
打开
→
超时后
自动进入
自动进入
Half-Open
半开
半开
半开状态请求成功 → 关闭｜请求失败 → 重新打开
微服务拆分原则
案例分析常考🎯DDD与限界上下文
领域驱动设计（DDD）：以业务领域为核心进行设计，将复杂的业务逻辑封装在领域模型中
限界上下文（Bounded Context）：定义领域模型的边界，每个限界上下文有独立的领域模型和通用语言。一个限界上下文对应一个微服务
通用语言（Ubiquitous Language）：领域专家和开发人员共同使用的语言，减少沟通成本
上下文映射：描述不同限界上下文之间的关系——共享内核、客户/供应商、防腐层（ACL）等
📏拆分原则与常见误区
| 原则 | 说明 | 注意事项 |
|---|---|---|
| 单一职责 | 每个微服务只负责一个业务能力 | 避免一个服务做太多事 |
| 高内聚低耦合 | 服务内部紧密相关，服务间依赖尽量少 | 服务间通过API通信 |
| 数据自治 | 每个微服务拥有独立的数据库 | 避免跨服务直接访问数据库 |
| 团队匹配 | 微服务边界与团队边界对齐（康威定律） | 一个团队负责一个服务 |
| 渐进式拆分 | 不要一开始就拆分过细 | 从单体开始，逐步拆分 |
⚠️微服务拆分常见误区
拆分过细：服务过多导致运维复杂度急剧上升，服务间调用链路过长，延迟增加，故障排查困难
分布式单体：虽然拆分为多个服务，但服务间高度耦合，修改一个服务需要同时修改多个服务
共享数据库：多个微服务共享同一数据库，导致数据耦合，违背了数据自治原则
过早拆分：在业务不稳定的情况下就进行微服务拆分，增加了不必要的复杂度
🔄微服务 vs SOA 对比
| 对比维度 | 微服务 | SOA |
|---|---|---|
| 服务粒度 | 小，单一职责 | 大，业务范围广 |
| 通信方式 | 轻量级（REST/RPC） | 重量级（SOAP/ESB） |
| 治理方式 | 去中心化 | 中心化（ESB） |
| 数据管理 | 每个服务独立数据库 | 可能共享数据库 |
| 部署方式 | 独立部署、容器化 | 整体部署或较重 |
| 技术栈 | 每个服务可选不同技术栈 | 通常统一技术栈 |
容器化技术
常考📦Docker核心概念
镜像（Image）：容器的模板，只读文件系统。包含运行应用所需的代码、运行时、库和配置。基于分层存储，可复用
容器（Container）：镜像的运行实例。可创建、启动、停止、删除。容器间相互隔离（Namespace）
仓库（Registry）：存储和分发镜像的场所。如Docker Hub、Harbor（私有仓库）
Dockerfile：定义镜像构建过程的文本文件。包含FROM、RUN、COPY、EXPOSE、CMD等指令
🔀Docker vs 虚拟机对比
| 对比维度 | Docker容器 | 虚拟机（VM） |
|---|---|---|
| 虚拟化层 | 操作系统层虚拟化 | 硬件层虚拟化 |
| 隔离机制 | Namespace + Cgroups | Hypervisor |
| 启动速度 | 秒级 | 分钟级 |
| 资源开销 | 小（共享宿主OS内核） | 大（每个VM有完整OS） |
| 性能 | 接近原生 | 有一定损耗 |
| 体积 | MB级别 | GB级别 |
| 隔离性 | 进程级隔离 | 完全隔离 |
| 操作系统 | 共享宿主OS内核 | 每个VM可运行不同OS |
核心区别：容器共享宿主机的操作系统内核，通过Namespace实现资源隔离，通过Cgroups实现资源限制；虚拟机通过Hypervisor虚拟硬件，每个VM有完整的操作系统。
Kubernetes编排
★★★★★📊K8s核心概念
| 概念 | 说明 | 类比 |
|---|---|---|
| Pod | K8s最小调度单元，包含一个或多个容器。共享网络命名空间和存储卷 | 逻辑主机（包含紧密相关的容器） |
| Service | 定义一组Pod的访问策略，提供稳定的网络端点。实现服务发现和负载均衡 | 负载均衡器/服务地址 |
| Deployment | 管理Pod的期望状态，支持声明式更新和回滚。控制ReplicaSet | 应用的声明式管理 |
| Namespace | 资源隔离的逻辑空间，用于多租户环境 | 虚拟集群 |
| Ingress | 管理外部访问集群内服务的HTTP/HTTPS路由规则 | API网关/反向代理 |
| ConfigMap | 存储非机密配置数据，以键值对形式。支持环境变量挂载和文件挂载 | 配置文件 |
| Secret | 存储机密数据（密码、Token、密钥），Base64编码 | 敏感配置 |
🔄K8s核心特性
HPA（水平Pod自动扩缩容）：根据CPU、内存或自定义指标自动调整Pod副本数
滚动更新（Rolling Update）：逐步替换旧版本Pod为新版本，保证服务不中断。可回滚
自愈（Self-Healing）：自动重启失败容器、替换不健康的Pod、在节点故障时重新调度
服务发现：Pod通过DNS名称或环境变量自动发现其他服务
常考陷阱：K8s的最小调度单元是Pod而不是Container。Service提供四层（TCP/UDP）负载均衡，Ingress提供七层（HTTP/HTTPS）路由。
Service Mesh（服务网格）
新兴热点📐Service Mesh核心概念
定义：Service Mesh是用于处理服务间通信的基础设施层。通过Sidecar代理透明地处理服务间通信，无需修改业务代码
Sidecar模式：在每个应用容器旁边部署一个代理容器（Sidecar），拦截所有进出应用的流量。Sidecar与应用容器共享Pod的网络命名空间
🏗️Istio架构
数据面（Data Plane）：由Envoy代理组成，负责实际的流量转发、负载均衡、认证等。每个服务实例旁都有一个Envoy Sidecar
控制面（Control Plane）：Istiod组件，负责配置管理、策略下发、证书管理。向数据面发送配置指令
核心功能：流量管理（路由/限流/熔断）、安全（mTLS认证/授权策略）、可观测性（指标/日志/追踪）
常考点：Service Mesh解决的核心问题是将服务间通信的逻辑从业务代码中剥离，实现业务逻辑与网络通信的关注点分离。
Serverless（无服务器计算）
新兴考点📌Serverless核心概念
FaaS（函数即服务）：用户只需编写函数代码，无需管理服务器。函数由事件触发执行，按需运行，自动扩缩容
BaaS（后端即服务）：提供现成的后端服务，如数据库、认证、存储。如Firebase、AWS Cognito
核心特点：按需执行、自动扩缩容、按实际使用量计费、无需运维
📊适用场景与限制
| 适用场景 | 不适用场景 |
|---|---|
| 事件驱动的任务（文件上传处理、定时任务） | 长时间运行的任务（函数有执行时间限制） |
| API后端（轻量级Web服务） | 需要保持状态的应用 |
| 数据处理管道（ETL中的转换步骤） | 冷启动敏感的场景（首次调用延迟高） |
| IoT数据处理 | 需要特定OS或硬件的场景 |
Serverless ≠ 没有服务器，而是开发者不需要关心服务器的管理。云厂商负责服务器的provisioning、维护、扩展。典型产品：AWS Lambda、阿里云函数计算。
DevOps与可观测性
常考🔄DevOps核心实践
CI/CD：持续集成（代码提交自动构建和测试）→ 持续交付（自动部署到预发布环境）→ 持续部署（自动部署到生产环境）
IaC（基础设施即代码）：用代码定义和管理基础设施。工具：Terraform、Ansible、CloudFormation。可版本控制、可复用
GitOps：以Git为单一事实来源，通过Git仓库的变更驱动基础设施和应用的部署。工具：ArgoCD、Flux
👁️可观测性三大支柱
| 支柱 | 工具 | 回答的问题 | 数据特点 |
|---|---|---|---|
| 日志（Logs） | ELK（Elasticsearch+Logstash+Kibana）、EFK | 发生了什么？ | 文本格式，包含时间、级别、消息 |
| 指标（Metrics） | Prometheus + Grafana | 系统状态如何？ | 数值型，时间序列数据，可聚合 |
| 链路追踪（Traces） | Jaeger、SkyWalking、Zipkin | 请求经历了什么？ | TraceID串联跨服务调用，记录每个步骤耗时 |
可观测性 vs 监控：监控是"已知未知"（我们知道要监控什么），可观测性是"未知未知"（通过数据发现我们不知道的问题）。可观测性 = 日志 + 指标 + 链路追踪。
章节测验
15题☁️ 第六章 · 云原生架构
第 1/15 题