软考架构师·云原生微服务架构及服务治理 深挖总文档

适用：系统架构设计师（高级）· 架构设计/系统可靠性/前沿技术专题
结构：理论深挖 → 计算题型 → 易混点辨析 → 双轨口诀 → 速记总表 → 背诵路线
进阶：第八章补充 Serverless/边缘/GitOps/eBPF/多集群/Operator/OPA/混沌/供应链安全 九大进阶主题

---

〇、思维导图（全章概览）

云原生微服务架构及服务治理
│
├─ 1. 云原生基石（CNCF定义四要素）
│   ├─ 容器化（Docker/OCI）
│   ├─ 服务网格（Service Mesh：Istio/Linkerd/Cilium）
│   ├─ 不可变基础设施（Immutable Infrastructure）
│   └─ 声明式API（Declarative API：K8s YAML/Helm）
│
├─ 2. 12-Factor应用（十二要素）
│   ├─ 代码库/依赖/配置/后端服务
│   ├─ 构建/发布/运行分离
│   └─ 并发/易处理/日志/管理进程
│
├─ 3. 微服务架构特征（Sam Newman六要素）
│   ├─ 小而自治/独立部署/异构技术/去中心化治理
│   ├─ 业务能力划分/分布式数据管理
│   └─ 拆分粒度权衡（粗vs细）
│
├─ 4. 服务治理三大层
│   ├─ 通信层：注册发现/负载均衡/API网关
│   ├─ 韧性层：熔断/降级/限流/重试/超时/隔离
│   └─ 观测层：链路追踪/指标/日志/拓扑
│
├─ 5. 服务网格（Service Mesh）深挖
│   ├─ Sidecar模式/数据面(xEnvoy)/控制面(Istiod)
│   ├─ xDS协议(ADS/CDS/EDS/LDS/RDS)
│   ├─ 流量治理：虚拟服务/目标规则/网关
│   └─ 安全治理：mTLS/授权策略/PeerAuthentication
│
├─ 6. 容器编排（Kubernetes核心）
│   ├─ Pod/Deployment/Service/Ingress
│   ├─ 调度器/驱逐/资源限额/HPA/VPA
│   └─ 声明式 reconcile 控制循环
│
├─ 7. 计算题型
│   ├─ 微服务拆分粒度/通信开销
│   ├─ 熔断器参数(Half-Open时间窗/失败率阈值)
│   ├─ 限流算法(令牌桶/漏桶/滑动窗口)
│   ├─ 容量规划(Pod数/资源Request/Limit)
│   └─ 服务网格性能开销/可用性
│
├─ 8. 易混点辨析（10项）
├─ 9. 双轨口诀（顺口溜+谐音）
├─ 10. 速记总表 + 背诵路线
│
└─ 进阶专题（第八章补充扩展）
    ├─ Serverless/FaaS：冷启动/计费/Knative
    ├─ 边缘计算：KubeEdge/k3s/OpenYurt/边缘自治
    ├─ GitOps：ArgoCD/Flux/Pull模型/漂移检测
    ├─ eBPF：Cilium/Sidecarless/内核可编程
    ├─ 多集群：Karmada/ClusterAPI/两地三中心
    ├─ Operator：CRD+Controller/Day-2运维
    ├─ 策略即代码：OPA/Gatekeeper/Kyverno
    ├─ 混沌工程：Chaos Mesh/稳态假设
    ├─ 镜像供应链安全：Sigstore/SBOM/Trivy
    ├─ 进阶计算题型（5题含变式）
    ├─ 进阶易混点（8项）
    └─ 进阶双轨口诀 + 进阶速记总表

---

一、理论深挖

1.1 云原生定义（CNCF权威定义）

Cloud Native 是一种技术体系，它利用容器的打包、动态调度、面向微服务的管理方式，使应用具备弹性、可观测、可移植特征。

CNCF 定义四要素（2024 更新版，原"微服务"被"服务网格"替代以强调基础设施解耦）：

要素	含义	代表技术	软考考点
容器化	应用+依赖打包为标准镜像，环境一致	Docker、containerd、OCI	不可变基础设施基础
服务网格	以Sidecar代理接管服务间通信与治理	Istio、Linkerd、Cilium	数据面/控制面分离
不可变基础设施	部署后不修改，变更即替换	镜像、K8s Pod	滚动更新/回滚机制
声明式API	描述"期望状态"而非"执行步骤"	K8s YAML、Helm、Terraform	reconcile 控制循环

关键原理：reconcile 控制循环（K8s 核心思想）

观测当前状态 → 计算期望与当前差异 → 执行动作使当前趋近期望 → 循环

数学化描述：设期望状态 S_desired，当前状态 S_actual，控制器每轮执行使 ‖S_desired - S_actual‖ → 0，即最终一致性收敛。

1.2 12-Factor 应用（十二要素，Heroku 2011）

软考高频考点，务必背全 12 条：

序号	要素	含义	云原生落地
Ⅰ	代码库	一份基准代码库，多份部署	GitOps、Monorepo
Ⅱ	依赖	显式声明依赖	requirements.txt、pom.xml
Ⅲ	配置	配置存环境变量，不入代码	ConfigMap、Secret
Ⅳ	后端服务	把后端服务当附加资源	DB/MQ 可替换
Ⅴ	构建/发布/运行	三阶段严格分离	CI/CD 流水线
Ⅵ	进程	应用以一个/多个无状态进程运行	K8s Pod 无状态
Ⅶ	端口绑定	自身监听端口提供服务	Spring Boot 内嵌容器
Ⅷ	并发	通过进程水平扩展	K8s HPA 扩缩容
Ⅸ	易处理	启动快、优雅终止	就绪/存活探针
Ⅹ	开发生产等价	缩小环境差异	容器镜像统一
Ⅺ	日志	当事件流，不管理日志文件	stdout→EFK
Ⅻ	管理进程	一次性管理任务与进程分离	Job、CronJob

1.3 微服务架构特征

Sam Newman 六大特征：

1. 小而自治：服务独立变更、独立部署、独立技术栈
2. 围绕业务能力建模：按领域驱动设计（DDD）的限界上下文划分
3. 异构技术栈：每个服务可选最合适语言/存储
4. 去中心化数据管理：每个服务独享数据库，避免共享库
5. 去中心化治理：无统一技术标准强制
6. 基础设施自动化：CI/CD 必备

微服务拆分原则（DDD 限界上下文）：

原则	说明	反模式
单一职责	一个服务一个业务能力	上帝服务（God Service）
高内聚低耦合	服务内高内聚，服务间松耦合	分布式单体
独立数据	不共享数据库	共享库导致强耦合
接口稳定	对外契约稳定	频繁破坏性变更

拆分粒度权衡（核心考点）：

设服务数为 n，单服务内复杂度为 O(1)，服务间通信复杂度为 O(n²)，则总复杂度：

C(n) = α·n·C_intra + β·n²·C_inter

• 粒度过粗（n 小）：C_intra 大，单服务难维护
• 粒度过细（n 大）：C_inter 主导，通信开销爆炸
• 最优粒度：令 dC/dn = 0，得 n* = α·C_intra / (2β·C_inter)

软考口诀：粗则内聚大难维护，细则通信多开销炸，取中权衡最优解。

1.4 服务治理三大层

1.4.1 通信层

① 服务注册与发现

模式	说明	代表	优劣
客户端发现	客户端查注册中心再直连	Eureka、Nacos	灵活但客户端复杂
服务端发现	经负载均衡器路由	K8s Service、Envoy	客户端简单但多一跳
服务网格	Sidecar 代理自动注册	Istio	透明但资源开销

② 负载均衡算法

算法	说明	适用
轮询(RR)	依次分配	同质节点
加权轮询(WRR)	按权重分配	异构节点
最少连接(LC)	选当前连接最少	长连接
一致性哈希	相同请求固定节点	会话保持
随机	随机选	简单场景
P2C(Power of 2 Choice)	随机选2个取较优	Envoy 默认

一致性哈希原理（软考计算题常考）：

• 节点映射到 0~2³²-1 哈希环
• 请求 key 哈希后顺时针找最近节点
• 虚拟节点解决数据倾斜：每物理节点开 v 个虚拟节点
• 增删节点只影响 1/v 比例流量

③ API 网关

职责：路由、认证、限流、熔断、日志、协议转换、聚合。

网关	特点	适用
Spring Cloud Gateway	响应式、Java 生态	Spring 微服务
Kong	插件丰富、高性能	多语言
APISIX	云原生、动态配置	K8s 环境
Zuul	Netflix、已过时	遗留系统

1.4.2 韧性层（Resilience，高频考点）

① 熔断器（Circuit Breaker）三态模型

        失败率≥阈值            定时探测成功
  Closed ────────→ Open ────────────→ Half-Open
    ↑                                    │
    │          探测成功                  │ 探测失败
    └────────────────────────────────────┘

状态	行为
Closed	正常放行，统计失败率
Open	直接拒绝/走降级，不调用下游
Half-Open	放行少量试探请求，成功则恢复，失败则回 Open

核心参数：

• failureRateThreshold：失败率阈值（如 50%）
• slowCallRateThreshold：慢调用比例阈值
• minimumNumberOfCalls：最小样本数（如 100）
• waitDurationInOpenState：Open 持续时间（如 60s）
• permittedNumberOfCallsInHalfOpenState：Half-Open 试探数（如 10）

② 降级（Fallback）

• 主动降级：大促时关闭非核心功能
• 被动降级：熔断后返回默认值/缓存/兜底
• 区别：熔断是"不调用"，降级是"返回替代结果"

③ 限流算法（计算题重点）

令牌桶（Token Bucket）：

• 容量 C，以速率 r 填充令牌
• 请求到达：有令牌则消耗1个放行，无则拒绝
• 特点：允许突发（桶满时一次性取多个）
• 公式：任意时间 t 内最大放行数 ≤ C + r·t

漏桶（Leaky Bucket）：

• 容量 C，以固定速率 r 漏出
• 请求到达：桶未满入桶，满则拒绝
• 特点：平滑流量，不允许突发
• 输出速率恒定 r

滑动窗口（Sliding Window）：

• 窗口大小 W，窗口内最多 N 请求
• 精度高但内存开销大
• Sentinel 默认用滑动窗口统计

④ 重试与超时

• 重试幂等性：仅幂等操作可重试（GET/PUT）
• 超时设置：总超时 = 重试次数 × 单次超时 + 重试间隔
• 指数退避：backoff = base × 2^attempt，避免惊群
• 重试放大效应：A→B→C，若每层重试3次，最坏 3×3×3=27 次调用！需设重试预算

⑤ 舱壁隔离（Bulkhead）

• 线程池隔离：不同下游用独立线程池
• 信号量隔离：轻量级，不创建线程
• 防止一个下游拖垮全局线程资源

1.4.3 观测层

可观测性三支柱：

支柱	说明	代表技术	数据特征
指标(Metrics)	聚合数值数据	Prometheus	时序数据
日志(Logs)	离散事件文本	ELK/EFK	事件流
链路追踪(Tracing)	请求跨服务路径	Jaeger/Zipkin	Span 树

分布式追踪核心概念：

• Trace：一次完整请求，唯一 TraceId
• Span：一次操作，有 SpanId + ParentSpanId
• 上下文传播：W3C TraceContext（traceparent header）
• 采样：降低开销，头部采样/尾部采样

OpenTelemetry 统一标准：CNCF 主推，统一 Metrics/Logs/Traces API。

1.5 服务网格（Service Mesh）深挖

1.5.1 Sidecar 模式

┌─────────────────────────────────┐
│            Pod                  │
│  ┌──────────┐   ┌──────────┐   │
│  │ 业务容器  │──→│ Sidecar  │──→│ 外部
│  │ (App)    │   │ (Envoy)  │   │
│  └──────────┘   └──────────┘   │
│        ↑              ↑         │
│        └── 同Pod共享网络栈 ──┘  │
└─────────────────────────────────┘

• Sidecar 与业务容器同 Pod，共享网络命名空间
• 所有进出流量经 Sidecar 代理（透明拦截）
• 业务无感知治理逻辑，语言无关

1.5.2 数据面与控制面分离

平面	职责	Istio 实现	性能关注
数据面	实际转发流量、执行策略	Envoy	延迟、吞吐
控制面	下发配置、证书管理	Istiod(Pilot+Citadel+Galley)	配置下发延迟

xDS 协议（Envoy 动态配置）：

xDS	全称	内容
LDS	Listener Discovery	监听器配置
RDS	Route Discovery	路由规则
CDS	Cluster Discovery	上游集群
EDS	Endpoint Discovery	集群端点
ADS	Aggregated Discovery	聚合以上所有

1.5.3 Istio 流量治理资源

CRD	作用	示例字段
VirtualService	定义路由规则	match、route、fault、retry
DestinationRule	定义负载均衡/熔断/连接池	trafficPolicy、outlierDetection
Gateway	入口流量网关	servers、selector
ServiceEntry	外部服务纳入网格	hosts、location

Istio 熔断（outlierDetection）：

trafficPolicy:
  outlierDetection:
    consecutive5xxErrors: 5        # 连续5次5xx踢出
    interval: 10s                  # 检测间隔
    baseEjectionTime: 30s          # 基础踢出时长
    maxEjectionPercent: 50         # 最大踢出比例

1.5.4 安全治理

能力	机制	Istio 资源
双向TLS	自动证书轮转	PeerAuthentication
授权	基于身份的访问控制	AuthorizationPolicy
审计	访问日志	Telemetry API
零信任	默认拒绝，显式放行	DENY + ALLOW 策略

1.6 容器编排 Kubernetes 核心

控制平面组件：

• kube-apiserver：唯一入口，REST API
• etcd：强一致 KV 存储（Raft 协议）
• kube-scheduler：调度 Pod 到节点
• kube-controller-manager：运行各种控制器
• cloud-controller-manager：云厂商集成

工作节点组件：

• kubelet：节点代理，向 API Server 汇报
• kube-proxy：维护 Service 规则（iptables/IPVS）
• container runtime：containerd/CRI-O

调度资源模型：

节点可调度资源 = NodeCapacity - system-reserved - kube-reserved
Pod 调度条件：Pod.requests ≤ 节点可调度资源

HPA（水平扩缩容）公式：

期望副本数 = ceil(当前副本数 × (当前指标 / 目标指标))

例：当前 4 副本，CPU 利用率 80%，目标 50%：
期望 = ceil(4 × 80/50) = ceil(6.4) = 7

1.7 云原生 vs 微服务 vs SOA 关系（高频辨析）

维度	SOA	微服务	云原生
通信	ESB 总线	REST/gRPC	Service Mesh
治理	中心化ESB	去中心化(每服务自治理)	基础设施透明治理
部署	应用服务器	独立部署	容器+编排自动化
数据	可共享库	独享数据库	独享+声明式存储
技术	统一标准	异构允许	异构+不可变
关系	微服务是SOA演进	云原生是微服务最佳实践载体	—

软考结论：云原生 ⊃ 微服务 ⊃ SOA 的精细化演进，云原生为微服务提供标准化基础设施。

---

二、计算题型（10题，含变式）

题型1：微服务拆分粒度与通信开销

【题1】 某系统按业务拆分为 n 个微服务，服务内复杂度系数 α=2，服务间通信复杂度系数 β=0.5，单服务内复杂度 C_intra=10，单次跨服务通信复杂度 C_inter=4。求最优服务数 n* 及对应总复杂度。

解：

总复杂度函数：C(n) = α·n·C_intra + β·n²·C_inter

代入：C(n) = 2·n·10 + 0.5·n²·4 = 20n + 2n²

求导令其为0：dC/dn = 20 + 4n = 0 → n = -5（舍去负值）

注：此二次项系数为正，函数开口向上，在 n≥1 时单调递增，说明在给定参数下通信开销主导，粒度越粗越好。这提示我们 β·C_inter 过大时不宜细拆。

变式： 若 β=0.05（通信开销大幅降低，如引入 Service Mesh 优化），求 n*。

C(n) = 20n + 0.05·n²·4 = 20n + 0.2n²，仍单调递增。

再变式（更典型）： 设服务内复杂度随 n 增加而下降，建模为 C_intra(n) = K/n（K=1000），通信为 β·n²·C_inter，β=0.5，C_inter=4。

C(n) = α·n·(K/n) + β·n²·C_inter = α·K + 2n²

仍单调递增——说明纯二次通信模型下细拆无益。正确建模应让服务内复杂度随 n 递减更快，如 C_intra(n) = K/n²：

C(n) = α·n·(K/n²) + β·n²·C_inter = α·K/n + β·C_inter·n²

dC/dn = -α·K/n² + 2β·C_inter·n = 0 → 2β·C_inter·n³ = α·K → n* = (α·K/(2β·C_inter))^(1/3)

代入 α=2, K=1000, β=0.5, C_inter=4：n* = (2000/4)^(1/3) = 500^(1/3) ≈ 7.94 → 取 8

结论：最优拆分为 8 个微服务。

---

题型2：熔断器状态转换

【题2】 熔断器配置：失败率阈值 50%，最小样本数 100，Open 持续 60s，Half-Open 试探 10 个。当前 Closed 状态，已统计 100 次请求，其中 55 次失败。描述状态转换。

解：

1. 失败率 = 55/100 = 55% ≥ 50% 阈值 → 转入 Open
2. Open 状态持续 60s，期间所有请求直接拒绝/走降级
3. 60s 后 → 转入 Half-Open，放行 10 个试探请求
4. 若 10 个中 ≥1 个失败 → 回到 Open，重置 60s 计时
5. 若 10 个全部成功 → 回到 Closed，重置统计

变式： 若 Half-Open 阶段要求"连续 N 次成功才恢复"，N=3，则需连续3个试探成功才回 Closed，任一失败即回 Open。

---

题型3：令牌桶限流计算

【题3】 令牌桶容量 C=100，填充速率 r=10 个/秒。某时刻桶满，随后 5 秒内来了 200 个请求，求放行数。

解：

• 初始令牌 = 100（桶满）
• 5 秒内新增令牌 = 10×5 = 50
• 可用令牌总量 = 100 + 50 = 150
• 请求 200 个 > 150 → 放行 150 个，拒绝 50 个

变式： 若初始桶中令牌为 60，其余不变，求放行数。

可用 = 60 + 50 = 110 < 200 → 放行 110，拒绝 90。

---

题型4：漏桶限流计算

【题4】 漏桶容量 C=50，漏出速率 r=20 个/秒。初始桶空，瞬间涌入 80 个请求，求第1秒内漏出数及拒绝数。

解：

• 涌入 80 个：桶容量 50，入桶 50，拒绝 30 个
• 第1秒漏出 = min(50, 20×1) = 20 个
• 桶中剩余 = 50 - 20 = 30

对比令牌桶： 漏桶输出恒定平滑，不允许突发；令牌桶允许突发（本例可瞬时放行50）。

---

题型5：滑动窗口限流

【题5】 滑动窗口大小 W=1秒，窗口内限 N=100 请求。采用 10 个格子（每格100ms）。t=0.0s 时来 80 请求，t=0.5s 时来 40 请求，求各时刻放行情况。

解：

• t=0.0s：窗口内 0 请求，来 80，0+80=100 ≤ 100 → 放行 80，窗口计数=80
• t=0.5s：窗口内仍 80（1秒窗口未过期），来 40，80+40=120 > 100 → 放行 20，拒绝 20，窗口计数=100

变式： 若 t=1.1s 时又来 60 请求，此时 t=0.0s 的 80 已滑出窗口，窗口内仅 t=0.5s 的 100（含放行20+拒绝20？否，只统计放行的100）。

注意：窗口计数只统计已放行请求。t=1.1s 时窗口 [0.1s, 1.1s] 内有 t=0.5s 放行的 20 个（80已滑出），来 60，20+60=80 ≤ 100 → 放行 60。

---

题型6：重试放大效应

【题6】 调用链 A→B→C，每层超时 2s，重试 3 次（含首次），无重试预算控制。C 宕慎超时，求最坏情况下 A 的总耗时及对 C 的总调用次数。

解：

• 每层重试3次 → 最坏调用次数 = 3×3×3 = 27 次
• 每层超时2s，串行最坏 = (2s×3)×3×3 = 54s？不对，需正确建模。

正确建模（每层串行重试，下层每次又触发其重试）：

• A 调 B：3次，每次 B 调 C：3次，每次 C 超时2s
• 单次 A→B→C 链耗时 = 2s（C超时，B单次超时2s内）
• B 的3次重试 = 3×2s = 6s（B单层总超时）
• A 的3次重试 = 3×6s = 18s

总耗时 18s，对 C 总调用 27 次。

治理建议： 设置重试预算，如 A 层不重试或仅重试1次，限制总调用 ≤ 5 次。

---

题型7：K8s HPA 扩缩容

【题7】 Deployment 当前 4 副本，HPA 目标 CPU 利用率 50%，当前实测 80%。求期望副本数。

解：

公式：期望 = ceil(当前 × (当前指标/目标指标)) = ceil(4 × 80/50) = ceil(6.4) = 7

变式： 若当前 10 副本，CPU 30%，目标 50%，期望 = ceil(10×30/50) = ceil(6) = 6，缩容到 6。

再变式（多指标）： 同时看 CPU 和内存，CPU 算出 7，内存算出 5，取较大值 7（HPA 多指标取 max）。

---

题型8：一致性哈希虚拟节点

【题8】 3 个物理节点，开 150 个虚拟节点，哈希环空间 2³²。求每个虚拟节点平均负责的环空间及增删1节点影响的流量比例。

解：

• 总虚拟节点 = 3×150 = 450
• 每虚拟节点平均空间 = 2³² / 450 ≈ 954万
• 增1物理节点（+150虚拟节点）：影响比例 ≈ 150/450 = 1/3
• 理论上增删1节点只影响 1/(n+1) 流量，n=3 → 1/4，虚拟节点使实际接近理论值

---

题型9：服务网格性能开销

【题9】 引入 Istio 后，每跳增加 Sidecar 延迟：P99 增加 8ms。某请求链路跨 5 个服务（4 跳服务间调用 + 1 跳入口）。求端到端 P99 延迟增加量。

解：

• 入口 Gateway Sidecar：1 跳 +8ms
• 服务间 4 跳，每跳 2 个 Sidecar（出+入）= 4×2 = 8 次 Sidecar = 8×8ms = 64ms
• 总增加 = 8 + 64 = 72ms

注：实际 Istio 优化后单跳增量约 2-8ms，本题用 8ms 估算上限。

变式： 若改用 Cilium eBPF 模式（无 Sidecar，内核态），单跳增量 1ms，总增加 = 9×1 = 9ms。

---

题型10：可用性计算（服务网格 vs 直连）

【题10】 单服务可用性 99.9%（年宕机 8.76h）。链路 5 服务串联。求：(a) 直连总可用性；(b) 引入 Sidecar（单 Sidecar 可用性 99.99%）后总可用性。

解：

(a) 直连：0.999^5 = 0.99501 ≈ 99.501%，年宕机 ≈ 43.8h

(b) 每跳经 2 个 Sidecar，4 跳服务间 = 8 个 Sidecar 串联 + 入口1个 = 9 个 Sidecar
Sidecar 总可用性 = 0.9999^9 ≈ 0.99910
总可用性 = 0.999^5 × 0.9999^9 = 0.99501 × 0.99910 ≈ 0.99411 ≈ 99.411%

结论： Sidecar 引入约 0.09% 可用性损耗，需通过 Sidecar 高可用设计弥补。

---

三、易混点辨析（10项高频易错）

#	易混点	辨析	记忆要点
1	Sidecar vs SDK治理	Sidecar 语言无关、透明但资源开销；SDK 语言相关、无额外跳但侵入业务	Sidecar=基础设施层，SDK=应用层
2	Istio vs Spring Cloud	Istio 基础设施层治理(运维负责)；Spring Cloud 应用层治理(开发负责)	Istio 换语言不用改代码
3	API网关 vs 服务网格	网关管南北向(外部→内部)；网格管东西向(服务间)	网关=大门，网格=内部走廊
4	熔断 vs 降级	熔断=不调用下游(保护被调方)；降级=返回替代结果(保护调用方体验)	熔断是因，降级是果
5	令牌桶 vs 漏桶	令牌桶允许突发(取多个令牌)；漏桶平滑输出(恒定速率)	令牌桶=可攒，漏桶=匀速漏
6	终态一致性 vs 强一致	K8s reconcile 是终态一致(最终收敛)；etcd 是强一致(Raft)	K8s控制器=终态，etcd=强一致
7	HPA vs VPA	HPA 水平扩缩(改副本数)；VPA 垂直扩缩(改资源配额)	HPA 改数量，VPA 改大小
8	微服务 vs SOA	微服务去中心化、独立部署、异构；SOA 中心化ESB、共享、统一	微服务=去ESB
9	12-Factor配置 vs ConfigMap	12-Factor要求配置入环境变量；ConfigMap是K8s落地实现	ConfigMap是手段，环境变量是原则
10	mTLS vs 普通TLS	mTLS双向认证(双方验证书)；普通TLS单向(客户端验服务端)	mTLS=互信，零信任基础

---

四、双轨口诀

4.1 顺口溜（押韵概括）

云原生四要素：

容器打包服务装，网格治理 Sidecar 帮，
不可变基替换上，声明 API 控循环。

12-Factor（12句）：

一库多部代码库，显式声明依赖图，
配置环境不入码，后端服务附加挂，
构建发布运行分，无状态进程快启停，
端口绑定自监听，并发扩展水平增，
易处理探针活，开发生产环境同，
日志事件流输出，管理进程独立走。

服务治理三层：

通信注册加网关，负载均衡路由转，
韧性熔断降级限，重试超时舱壁隔，
观测指标日志链，三柱撑起可观测。

熔断三态：

Closed 放行统计忙，Open 拒绝降级上，
Half-Open 试探放，成功恢复失败挡。

限流两桶：

令牌桶能攒突发，漏桶匀速平滑下，
滑动窗口精度佳，窗口大小定误差。

服务网格：

数据面 Envoy 转发忙，控制面 Istiod 配置下，
xDS 动态推配置，mTLS 双向证书加。

4.2 谐音联想记忆

知识点	谐音口诀	联想
云原生四要素	“容网不声”	容(容器)网(网格)不(不可变)声(声明式)→“容易网不住声音”
12-Factor前6	“码依配后构”	码(代码库)依(依赖)配(配置)后(后端服务)构(构建发布运行)→“马一配后够”
熔断三态	“闭开半”	Closed→Open→Half-Open→“闭开半，半开试探”
限流三算法	“令漏滑”	令牌桶、漏桶、滑动窗口→“令路滑”（令牌路上滑）
服务治理三层	“通韧观”	通信、韧性、观测→“通认官”（通认的官）
可观测三柱	“指日链”	指标、日志、链路→“只日链”（只有日链）
xDS五协议	“LRCEA”	LDS/RDS/CDS/EDS/ADS→“路集端聚总”
Sidecar vs SDK	“旁车透明侵入显”	Sidecar旁车透明，SDK侵入显式
南北vs东西	“南门东廊”	网关=南门(南北)，网格=东廊(东西)
HPA vs VPA	“水改数垂改量”	HPA水平改数量，VPA垂直改容量

---

五、速记总表（考前速查）

5.1 核心概念速查

主题	核心公式/结论	一句话
云原生四要素	容器+网格+不可变+声明式	CNCF定义
reconcile循环	‖S_desired - S_actual‖ → 0	终态一致收敛
微服务最优粒度	n* = (αK/2βC_inter)^(1/3)	内聚通信权衡
熔断三态	Closed→Open→Half-Open	失败率触发
令牌桶	放行 ≤ C + r·t	允许突发
漏桶	输出恒定 r	平滑流量
滑动窗口	窗口W内≤N	高精度限流
HPA	ceil(当前×当前指标/目标指标)	水平扩缩
重试放大	3层×3次=27次	需重试预算
一致性哈希	增删影响1/(n+1)	虚拟节点均衡
Sidecar延迟	每跳+2~8ms	网格开销
串联可用性	∏pᵢ	相乘递减

5.2 技术选型速查

场景	推荐	理由
Java微服务治理	Spring Cloud	生态成熟，侵入式
多语言微服务	Istio Service Mesh	语言无关，透明治理
限流允许突发	令牌桶	攒令牌应对峰值
限流严格平滑	漏桶	恒定速率保护下游
高精度限流	滑动窗口	时间维度精确
服务发现(K8s)	K8s Service+DNS	原生集成
服务发现(非K8s)	Nacos/Consul	功能丰富
API网关(云原生)	APISIX/Kong	高性能插件化
链路追踪	Jaeger+OpenTelemetry	CNCF标准
指标监控	Prometheus+Grafana	事实标准
容器编排	Kubernetes	事实标准

5.3 易混点速查

对比	关键区别
Sidecar vs SDK	透明 vs 侵入
Istio vs SpringCloud	基础设施层 vs 应用层
网关 vs 网格	南北 vs 东西
熔断 vs 降级	不调用 vs 返回替代
令牌桶 vs 漏桶	突发 vs 平滑
HPA vs VPA	改数量 vs 改容量
mTLS vs TLS	双向 vs 单向

5.4 进阶速记（见 §8.13）

Serverless/边缘/GitOps/eBPF/多集群/Operator/OPA/混沌/供应链安全 的速记表见 8.13 进阶速记总表。

---

六、典型考题方向（软考架构师）

1. 架构风格选择题：给定场景选云原生/微服务/SOA，考特征辨析
2. 服务治理设计题：给定微服务系统，设计熔断+限流+降级方案
3. 服务网格辨析题：Istio 数据面/控制面、Sidecar 优劣
4. 12-Factor 应用题：判断某应用是否符合规，给出改造建议
5. 限流算法计算题：令牌桶/漏桶放行数计算
6. HPA 扩缩容计算题：给定指标算期望副本数
7. 可用性/性能分析题：串联可用性、Sidecar 延迟开销
8. 质量属性映射题：云原生如何满足弹性/可观测/可移植
9. 康威定律应用题：组织架构与微服务边界对齐
10. 容器编排调度题：K8s 资源模型、调度条件

---

七、背诵路线建议

第1遍（框架）：云原生四要素 + 12-Factor + 微服务六特征 + 治理三层
    ↓
第2遍（治理）：熔断三态 + 限流三算法 + 重试超时 + 舱壁隔离
    ↓
第3遍（网格）：Sidecar + 数据面/控制面 + xDS + Istio CRD + mTLS
    ↓
第4遍（计算）：令牌桶/漏桶/HPA/可用性/重试放大/一致性哈希 6类公式
    ↓
第5遍（易混）：10个易混点表格 + 速记总表
    ↓
第6遍（口诀）：顺口溜全背 + 谐音联想辅助
    ↓
第7遍（进阶）：Serverless/边缘/GitOps/eBPF/多集群/Operator 六进阶
    ↓
第8遍（进阶计算）：冷启动计费/边缘延迟/eBPF性能/多集群可用性 4类公式
    ↓
第9遍（进阶易混+口诀）：8个进阶易混点 + 8段进阶顺口溜
    ↓
考前：只看速记总表(5.1+8.13) + 易混点速查(三+8.11)

---

八、云原生进阶专题（补充扩展）

覆盖：Serverless / 边缘计算 / GitOps / eBPF / 多集群 / Operator / 策略即代码 / 混沌工程 / 镜像供应链安全
结构：理论深挖 → 进阶计算题型 → 进阶易混点 → 进阶双轨口诀

8.1 Serverless / FaaS 深挖

定义（CNCF）：Serverless 是一种执行模型，云服务商动态分配资源、按实际用量计费、零缩放到零。分两类：

• FaaS（Function as a Service）：事件驱动的函数执行，如 AWS Lambda、Azure Functions、阿里云FC
• BaaS（Backend as a Service）：后端服务托管，如 Auth0、Firebase、对象存储

核心特征：

特征	说明	架构影响
按需计费	毫秒级计费，闲置不计费	成本最优但冷启动有延迟
自动缩放到零	无请求时实例回收	节省资源但首次请求慢
事件驱动	由 HTTP/MQ/定时器触发	解耦调用方与被调方
无状态	函数实例不可持有状态	状态外置到 Redis/DB
运维零感知	不管理服务器/容器	开发聚焦业务逻辑

冷启动延迟分析（高频考点）：

冷启动 = 容器创建 + 镜像加载 + 运行时初始化 + 代码加载 + 首次执行

T_cold = T_image + T_runtime + T_code + T_init
T_warm = T_invoke   (实例已存在，仅执行函数)

典型延迟（Java vs Python vs Go）：

语言	T_cold	T_warm	原因
Java	1~3s	10~50ms	JVM 启动+类加载重
Python	200~800ms	5~20ms	解释器启动中等
Go	50~200ms	2~10ms	静态编译启动快
Rust	30~100ms	1~5ms	静态编译+无GC

计费模型对比：

模型	公式	适用
FaaS按请求	Cost = Σ(执行次数 × 单次时长 × 单价)	突发/稀疏流量
实例按时长	Cost = 实例数 × 时长 × 单价	持续稳定流量
临界点	当 QPS × 单次时长 ≥ 实例单价时，实例更划算	流量阈值计算

Knative（K8s上的Serverless标准）：

• Serving：自动缩放到零、流量路由、版本灰度
• Eventing：事件源→触发器→服务的事件链
• PodAutoscaler（KPA）：基于并发请求数扩缩，支持缩到0

架构影响：

• 优势：成本最优、自动扩缩、聚焦业务
• 劣势：冷启动延迟、 Vendor Lock-in、长任务不适合、调试困难
• 适用：突发流量、事件触发、Webhook、ETL步骤；不适用：长连接、有状态、低延迟敏感

8.2 边缘计算 / Edge Native

定义：将计算从中心云下沉到数据源附近，降低延迟、节省带宽、支持离线自治。

云边协同三模型：

模型	说明	代表
中心管控+边缘执行	控制面在云，数据面在边缘	KubeEdge
边缘自治+云端同步	边缘可离线独立运行，恢复后同步	OpenYurt
轻集群统一管理	边缘作为集群节点统一纳管	k3s + Rancher

核心技术：

技术	特点	适用
KubeEdge	K8s原生边缘扩展，边缘自治，MQTT支持	IoT/工业边缘
k3s	轻量K8s（单二进制<100MB），去etcd用SQLite	资源受限边缘
OpenYurt	阿里开源，节点池模型，云边隧道	多地域边缘
MicroK8s	Canonical轻量K8s，snap安装	开发/边缘

边缘自治原理：

• 边缘节点断网时，本地 kubelet 继续按已下发配置运行 Pod
• 元数据缓存本地，恢复网络后与云端 reconcile 同步
• 边缘设备孪生（Device Twin）：期望状态 vs 报告状态，类似 K8s 控制循环

延迟优势计算：

T_中心 = T_传输到云 + T_处理 + T_返回 ≈ 2×RTT_云 + T_处理
T_边缘 = T_本地处理 ≈ T_处理 (RTT可忽略)
延迟降低 = T_中心 - T_边缘 ≈ 2×RTT_云

架构影响：

• 5G+边缘使 AR/VR/自动驾驶的毫秒级延迟可行
• 边缘自治要求应用无状态化、幂等设计
• 云边数据一致性需用最终一致+冲突解决（CRDT）

8.3 GitOps

定义（Weaveworks提出）：以 Git 仓库作为系统期望状态的唯一真实来源，自动同步到运行环境。

四原则：

原则	说明	落地
声明式	系统状态用声明式描述	K8s YAML / Helm / Kustomize
版本控制	全部状态存Git，有完整历史	Git commit = 部署版本
自动应用	Git变更自动应用到集群	ArgoCD / Flux 持续同步
持续协调	系统漂移自动纠正	reconcile 循环

ArgoCD vs Flux 对比：

维度	ArgoCD	Flux
UI	有Web UI + CLI	仅CLI（Flux v2）
同步模型	Pull（集群拉Git）	Pull
多源	支持（多repo合并）	支持
应用定义	Application CRD	Kustomization/HelmRelease CRD
灰度	原生支持（Analysis+Rollout）	需Flagger
生态	CNCF Graduated	CNCF Graduated

Push vs Pull 模型：

模型	说明	优劣
Push（CI/CD）	CI构建后kubectl apply	简单但集群需开放凭据
Pull（GitOps）	集群内Agent拉Git同步	集群不暴露，安全更好

漂移检测：

• 系统实际状态 vs Git期望状态不一致即为漂移
• ArgoCD 默认3分钟拉一次Git（可配置）
• 手工 kubectl 改了集群 → 漂移 → ArgoCD 自动纠正（或告警）

架构影响：

• 部署即Git提交，回滚即Git revert，审计即Git log
• 环境隔离用不同分支/dir：dev/staging/prod
• 密钥管理需配合 Sealed-Secrets / SOPS / External Secrets

8.4 eBPF

定义：eBPF（extended Berkeley Packet Filter）是Linux内核可编程虚拟机，允许在不修改内核源码、不加载内核模块的情况下，在内核态运行沙箱程序。

核心原理：

用户态编写eBPF程序 → Verifier验证安全性 → JIT编译为原生码 → 内核态执行

Verifier保证：

• 有界循环、无越界访问、无空指针、无除零
• 程序必须在有限时间内终止

云原生应用：

场景	技术	优势
网络数据面	Cilium	绕过iptables/netfilter，吞吐提升3~5倍
可观测性	Pixie	内核态采集，无需Sidecar/SDK
安全审计	Tetragon	内核事件实时检测，绕过用户态hook
性能分析	bpftrace	内核级火焰图，无开销

Cilium vs Calico vs iptables：

方案	数据面	性能	适用
iptables	内核netfilter	O(n)规则匹配，大规模慢	小规模/K8s默认
Calico(eBPF)	eBPF	O(1)查找，高速	大规模网络
Cilium	eBPF+Envoy	最高吞吐+Service Mesh	大规模+网格

Sidecarless模式（Cilium Service Mesh）：

• 传统 Sidecar：每Pod注入Envoy，+2~8ms/跳延迟
• Cilium Sidecarless：eBPF在内核处理mTLS+路由，无Sidecar
• 延迟降低：从 +2~8ms/跳 降到 +0.1~0.5ms/跳

架构影响：

• eBPF使内核成为可编程数据面，绕过用户态上下文切换
• Sidecarless是Service Mesh下一代演进方向
• 需要内核版本≥4.18（或≥5.4推荐）

8.5 多集群管理

驱动场景：

• 多云多活（AWS+阿里云+自建，避免Vendor Lock-in）
• 多地域容灾（两地三中心、三地五中心）
• 弹性溢出（常态自建，峰值溢出到云）
• 多租户隔离（每租户独立集群）
• 混合云（边缘+中心统一管理）

核心方案对比：

方案	模型	特点	成熟度
KubeFed v2	联邦集群	已停止维护，被Karmada替代	弃用
Karmada	联邦调度+应用分发	华为开源，CNCF Sandbox，支持跨集群调度	活跃
Cluster API	声明式集群生命周期	管理集群的创建/升级/销毁	CNCF项目
Argo CD多集群	GitOps+多集群	一套Git管多集群	成熟
Submariner	跨集群网络互通	Pod/Service跨集群直连	活跃

Karmada核心CRD：

• PropagationPolicy：定义应用分发到哪些集群、副本分配策略
• ResourceBinding：记录资源在各集群的绑定状态
• OverridePolicy：集群差异化配置（如不同region的镜像）

跨集群可用性计算：

多活集群可用性 = 1 - ∏(1 - A_i)
两地三中心：A = 1 - (1-0.999)²×(1-0.9999) ≈ 0.9999999 (7个9)

RTO/RPO目标：

架构	RTO	RPO	说明
主备（异步复制）	分钟级	秒级	数据可能丢
主备（同步复制）	秒级	0	数据不丢
双活	0	0	实时切换
多活	0	0	任一节点可服务

架构影响：

• 多集群使应用跨云跨地域，提升可用性、降低Vendor Lock-in
• 跨集群服务发现需全局DNS / 全局Service Mesh（Istio Multi-Primary）
• 数据一致性是难点：跨集群事务用Saga，强一致用Spanner/TiDB

8.6 Operator模式

定义：Operator = CRD（自定义资源）+ 控制器（管理逻辑），将人类运维知识编码为自动化控制器。

核心思想：

CRD定义"期望状态"（如：RedisCluster{replicas:3, version:7.0}）
控制器reconcile：观测实际 → 计算 → 执行 → 收敛到期望

Operator典型职责：

职责	说明	示例
部署	创建底层资源	创建StatefulSet+Service
扩缩容	修改副本数	Redis扩容自动rebalance
升级	滚动更新版本	MySQL主从滚动升级
备份恢复	定期备份+PITR	CronJob备份到S3
故障恢复	自动主从切换	主库宕机选从提升
配置管理	动态配置下发	热更新参数

Operator vs Helm vs 手动运维：

维度	手动运维	Helm	Operator
安装	手工	一键	一键
升级	手工+易错	helm upgrade	自动滚动+回滚
扩缩容	手工	helm upgrade	改CRD字段自动
故障恢复	人工介入	无	自动主从切换
日常运维	全人工	部分自动	全自动
复杂度	低	中	高（需开发Controller）

OLM（Operator Lifecycle Manager）：

• 管理Operator的安装、升级、依赖
• OperatorHub：社区Operator市场（如 Prometheus Operator、Cert Manager）

架构影响：

• Operator将"Day-2运维"（升级/备份/恢复）自动化
• 复杂中间件（数据库/MQ/缓存）上K8s必备Operator
• 开发Operator用 Kubebuilder / Operator SDK

8.7 策略即代码（Policy as Code）

定义：用代码定义合规策略，在准入控制阶段自动执行，违规请求被拒绝。

核心方案：

方案	策略语言	集成点	特点
OPA（Open Policy Agent）	Rego	准入Webhook	通用策略引擎，CNCF Graduated
Gatekeeper	Rego	K8s准入	OPA的K8s封装，约束模板+约束
Kyverno	YAML	K8s准入	原生K8s风格，无需学Rego

Gatekeeper工作流：

kubectl apply → API Server → 准入Webhook → OPA评估Rego → 允许/拒绝

典型策略示例：

• 必须有资源限额：禁止无 resources.limits 的Pod
• 镜像必须来自可信仓库：禁止 :latest 标签
• 必须有标签：禁止无 app 标签
• 禁止特权容器：privileged: true 被拒绝
• 命名空间配额：限制每namespace资源总量

架构影响：

• 策略即代码使合规检查左移到部署时，而非运行时审计
• 策略版本化存Git，可审计、可回滚
• 多租户隔离、安全基线、合规要求统一落地

8.8 混沌工程（Chaos Engineering）

定义：主动注入故障，验证系统韧性，发现隐藏问题。Netflix Chaos Monkey开创。

核心方法论：

1. 定义稳态假设（如：API可用性≥99.9%）
2. 假设正常/故障环境下稳态都成立
3. 引入真实故障（杀Pod/网络延迟/CPU打满）
4. 观察是否仍满足稳态
5. 不满足则修复并迭代

爆炸半径（Blast Radius）控制：

• 先在非生产环境实验
• 限制故障影响范围（如只杀10%Pod）
• 逐步扩大范围
• 设自动中止条件（如可用性跌破阈值立即停止）

核心工具：

工具	故障类型	特点
Chaos Mesh	Pod/网络/IO/DNS/时间	CNCF Sandbox，K8s原生
Litmus	丰富实验库	CNCF Incubating
Chaos Monkey	随机杀实例	Netflix元祖
Gremlin	商业，GUI友好	企业级

Chaos Mesh故障类型：

• PodChaos：杀Pod/OOM
• NetworkChaos：延迟/丢包/分区
• IOChaos：读写延迟/错误
• DNSChaos：DNS解析失败
• TimeChaos：时间漂移（测超时逻辑）

vs 传统测试：

维度	传统测试	混沌工程
目标	验证功能正确	验证韧性假设
故障	预定义输入	真实故障注入
时机	开发期	运行期（生产/预发）
发现	已知问题	未知隐患

8.9 镜像供应链安全

威胁： 镜像投毒（后门）、依赖漏洞、镜像篡改、来源伪造。

纵深防御链：

环节	措施	工具
源码	SAST静态扫描	SonarQube/CodeQL
依赖	SCA依赖扫描	Trivy/Dependency-Check
构建	镜像扫描	Trivy/Grype/Clair
签名	镜像签名验证	Cosign/Sigstore/Notation
清单	SBOM物料清单	Syft/CycloneDX
准入	签名+扫描校验	Connaisseur/Policy Controller
运行	运行时检测	Falco/Tracee

Sigstore（CNCF项目）：

• Cosign：镜像签名/验证
• Rekor：透明日志（不可篡改的签名记录）
• Fulcio：短生命周期证书（OIDC绑定身份）
• 工作流：构建时用OIDC身份签名 → 部署时验证签名 → Rekor可审计

SBOM（Software Bill of Materials）：

• 列出镜像所有依赖及版本
• 格式：SPDX / CycloneDX
• 用途：漏洞爆发时快速定位受影响镜像

架构影响：

• 镜像供应链安全是云原生安全基石（运行时检测是兜底）
• 策略：只允许签名镜像部署 + 禁止 :latest + 强制SBOM
• 与OPA/Gatekeeper集成：准入时验证签名

---

8.10 进阶计算题型（5题，含变式）

【题1】Serverless冷启动延迟与计费

某函数 Java 实现，冷启动 2.5s，热启动 30ms，按请求计费：每100ms 0.0002元，最低100ms计。QPS=10，函数平均执行 50ms。实例空闲 5 分钟回收。
（1）若 QPS 持续 10，冷启动占比多少？
（2）若改用按实例计费：每实例每分钟 0.01 元，需 1 实例支撑 100QPS。比较两种计费每小时成本。

解：

（1）每实例可处理 5分钟×60s×10QPS = 3000 请求后才回收。冷启动1次/3000请求。
冷启动占比 = 1/3000 = 0.033%
冷启动总耗时 = 2.5s × 1次 = 2.5s
热启动总耗时 = 30ms × 2999 = 89.97s
平均延迟 = (2.5 + 89.97) / 3000 = 30.82ms

（2）FaaS计费：

• 每小时请求 = 10 × 3600 = 36000
• 每次计费时长 = max(50ms, 100ms) = 100ms（最低100ms）
• 每次费用 = 100/100 × 0.0002 = 0.0002元
• 每小时成本 = 36000 × 0.0002 = 7.2元

实例计费：

• 需支撑10QPS，1实例可支撑100QPS，故1实例足够
• 每小时成本 = 1 × 60 × 0.01 = 0.6元

结论：稳定10QPS下实例计费便宜12倍。FaaS仅适合突发稀疏流量。

变式：若 QPS=0.1（稀疏），每小时仅360请求：

• FaaS：360 × 0.0002 = 0.072元
• 实例：0.6元（实例需常驻）
• 此时FaaS便宜8倍。

【题2】边缘节点部署延迟与带宽

某工业视觉检测：每摄像头 4Mbps 视频流，1000 路摄像头。中心云 RTT=80ms，边缘 RTT=2ms。检测耗时 20ms。
（1）全传中心云，带宽需求与端到端延迟？
（2）边缘部署，仅异常时回传中心（异常率 1%），带宽需求与延迟？

解：

（1）全传中心：

• 带宽 = 1000 × 4Mbps = 4000Mbps = 4Gbps
• 延迟 = 上传RTT + 检测 = 80 + 20 = 100ms

（2）边缘部署：

• 边缘处理延迟 = 2 + 20 = 22ms
• 回传带宽 = 1000 × 1% × 4Mbps = 40Mbps（降99%）
• 边缘到中心带宽仅用于异常帧回传+结果汇总

结论：边缘部署延迟从100ms降到22ms（降78%），带宽从4Gbps降到40Mbps（降99%）。

变式：若边缘节点算力仅为中心1/4，检测耗时80ms：

• 边缘延迟 = 2 + 80 = 82ms（仍优于中心100ms）
• 临界点：边缘检测耗时 < 78ms 时延迟优势明显

【题3】GitOps漂移检测与回滚

ArgoCD 配置 syncInterval=3min。某开发误用 kubectl 改了 prod 集群的 Deployment 副本数（Git 中是 5，改成 50）。
（1）最长多久后漂移被检测？
（2）若启用 auto-sync，多久后纠正？
（3）若用 Git revert 回滚一次错误提交，涉及3个文件，回滚耗时？

解：

（1）最长检测时间 = syncInterval = 3分钟（最坏情况，刚同步完就漂移）

（2）auto-sync 启用后，检测到漂移立即纠正，最长 3 分钟 + 同步耗时（通常 < 10s）≈ 3分10秒

（3）Git revert 一次提交（无论几个文件）= 1次commit，耗时约 5s（git revert + push）
ArgoCD 检测到新提交并同步 ≈ 3分钟
总回滚 ≈ 3分5秒

变式：若禁用 auto-sync（仅告警）：

• 漂移检测后仅告警，需人工 argocd app sync 手动同步
• 回滚时间 = 人工响应时间 + 同步时间（不可控）

【题4】eBPF vs Sidecar 性能对比

某网格 100 跳服务调用链。Sidecar 模式每跳 +5ms 延迟、+0.1% 可用性损耗。Cilium eBPF Sidecarless 每跳 +0.3ms、+0.01% 损耗。
（1）两种模式端到端延迟？
（2）两种模式端到端可用性？
（3）吞吐量提升（假设延迟与吞吐反比）？

解：

（1）延迟：

• Sidecar：100 × 5 = 500ms 额外延迟
• eBPF：100 × 0.3 = 30ms 额外延迟
• 降低 = 500 - 30 = 470ms（降94%）

（2）可用性：

• Sidecar：0.999^100 ≈ 0.9048 (90.48%)
• eBPF：0.9999^100 ≈ 0.9900 (99.00%)
• 提升 = 99.00% - 90.48% = 8.52个百分点

（3）吞吐提升（延迟反比）：

• 吞吐比 = 500/30 = 16.7倍

结论：eBPF Sidecarless 在长调用链场景优势巨大，是网格演进方向。

变式：若仅 10 跳：

• Sidecar：50ms / 0.999^10≈0.9900
• eBPF：3ms / 0.9999^10≈0.9999
• 短链场景延迟差异不大，eBPF优势不显著

【题5】多集群跨可用性计算

某系统两地三中心部署：A地2机房（每机房可用性 0.999），B地1机房（可用性 0.9999）。应用多活部署，任一机房可用即可服务。
（1）系统整体可用性？
（2）相比单机房提升多少个9？
（3）若 A地两机房同时故障（同城光纤中断），系统可用性？

解：

（1）多活：所有机房同时不可用才宕机

• A机房1不可用 = 1 - 0.999 = 0.001
• A机房2不可用 = 0.001
• B机房不可用 = 1 - 0.9999 = 0.0001
• 全部不可用 = 0.001 × 0.001 × 0.0001 = 1×10⁻¹⁰
• 整体可用性 = 1 - 1×10⁻¹⁰ ≈ 0.9999999999（10个9）

（2）单机房 0.999 = 3个9；多活 10个9；提升 7个9

（3）A地两机房同时故障，仅B地可用：

• 可用性 = 0.9999 = 4个9（仍优于单机房的3个9）

结论：两地三中心多活可达10个9，同城双机房故障仍降级为4个9。

变式：若三机房可用性均为 0.999：

• 全部不可用 = 0.001³ = 1×10⁻⁹
• 可用性 = 1 - 1×10⁻⁹ ≈ 9个9

---

8.11 进阶易混点辨析（8项）

#	易混点	辨析	记忆要点
1	Serverless vs 微服务	Serverless缩到零、按请求计费、无运维；微服务常驻、按实例计费、需运维	Serverless=零缩放，微服务=常驻
2	FaaS vs BaaS	FaaS=函数执行（Lambda）；BaaS=后端托管（Auth0/存储）	FaaS你写函数，BaaS用现成
3	冷启动 vs 热启动	冷启动=实例从0创建（秒级）；热启动=实例已存在（毫秒级）	冷=新建慢，热=复用快
4	GitOps vs CI/CD	GitOps=Pull（集群拉Git）；CI/CD=Push（CI推集群）	GitOps集群主动拉，CI/CD被动接
5	eBPF vs Sidecar	eBPF内核态无Sidecar；Sidecar用户态每Pod注入	eBPF=内核零侵入，Sidecar=用户态旁车
6	Cilium vs Calico	Cilium纯eBPF数据面；Calico默认iptables可选eBPF	Cilium=原生eBPF，Calico=iptables为主
7	Operator vs Helm	Operator持续运维（扩缩/备份/恢复）；Helm一次性部署	Operator=Day-2运维，Helm=Day-0部署
8	多集群 vs 多租户	多集群=物理隔离多套K8s；多租户=单集群内namespace隔离	多集群=多套，多租户=一套内分

---

8.12 进阶双轨口诀

顺口溜：

Serverless：

函数即服务缩到零，事件触发毫秒计，
冷启 Java 慢三秒，Go Rust 秒内启，
突发稀疏最划算，长连有态不适宜。

边缘计算：

计算下沉到边缘，延迟带宽双节省，
KubeEdge 边自治，k3s 轻量百兆内，
断网本地仍运行，恢复同步 reconcile。

GitOps：

Git 仓库真来源，声明版本自动签，
ArgoCD 集群拉，漂移纠正三分钟，
回滚就是 git revert，审计就是 git log。

eBPF：

内核可编程 eBPF，验证安全 JIT 编，
Cilium 绕过协议栈，Sidecarless 延迟降，
吞吐提升十几倍，网格演进新方向。

多集群：

多云多活 Karmada，跨集群调度分发下，
两地三中心十个九，同城光纤也不怕，
跨集群事务用 Saga，强一致选 TiDB。

Operator：

CRD 加控制器，运维知识编码里，
扩缩升级备份恢复，Day-2 全自动起，
Helm 部署一次性，Operator 持续理。

策略即代码：

OPA Rego 准入拦，违规请求被拒还，
Gatekeeper K8s 封装，Kyverno YAML 写，
策略左移部署时，合规基线统一管。

混沌工程：

稳态假设先定义，故障注入验韧性，
爆炸半径要控制，非生产先实验，
Chaos Mesh 杀 Pod 慢，网络分区丢包练。

镜像供应链：

源码依赖镜像扫，Trivy Syft 找漏洞，
Cosign 签名 Rekor 记，SBOM 物料清单留，
准入验证签名过，Falco 运行时兜底守。

谐音联想记忆：

知识点	谐音口诀	联想
Serverless三特征	“零计事”	零(缩到零)计(按计费)事(事件驱动)→“灵机事”
边缘三模型	“管自统”	管控+自治+统一→“管子统”
GitOps四原则	“声版自协”	声明+版本+自动+协调→“生版自协”
eBPF三步	“编验编”	编写+验证+编译→“边验边”
多集群方案	“卡克阿”	Karmada+ClusterAPI+ArgoCD→“卡客阿”
Operator职责	“部扩升备恢配”	部署扩缩升级备份恢复配置→“不扩升辈回配”
供应链环节	“源依构签清准运”	源码依赖构建签名清单准入运行→“元一够签清准运”
混沌五步	“定假引观修”	定义假设引入观察修复→“定假引观修”

---

8.13 进阶速记总表

主题	核心公式/结论	一句话
Serverless计费	Cost=Σ(次数×时长×单价)	按请求计费
冷启动	T_cold=T_image+T_runtime+T_code	Java秒级Go毫秒级
FaaS临界点	QPS×单次时长≥实例单价时实例划算	稳定流量用实例
边缘延迟降	ΔT≈2×RTT_云	边缘省往返RTT
边缘带宽降	仅回传异常率×原带宽	1%异常降99%带宽
GitOps检测	最长=syncInterval	默认3分钟
eBPF延迟降	每跳从5ms降到0.3ms	降94%
Sidecarless可用性	0.9999^n vs 0.999^n	eBPF损耗低一个数量级
多活可用性	1-∏(1-A_i)	两地三中心10个9
同城故障降级	仅剩异地机房	4个9兜底
Operator	CRD+Controller=自动化运维	Day-2全自动
OPA准入	Rego评估→允许/拒绝	策略左移
混沌稳态	故障下稳态仍成立	验证韧性
镜像签名	Cosign签名+Rekor透明日志	不可篡改

---

九、关联知识点

关联主题	关系	延伸
架构风格	云原生/微服务是现代架构风格	见架构风格总文档
质量属性	弹性/可观测/可移植是云原生目标质量	可用性/性能/可修改性
分布式事务	微服务跨服务事务：Saga/TCC/事件驱动	2PC不适合微服务
DDD	限界上下文指导微服务拆分	战略/战术设计
康威定律	组织结构决定系统架构	微服务团队对齐
DevOps	云原生依赖CI/CD自动化	GitOps是其演进
容器/Docker	云原生打包基础	OCI镜像标准
Kubernetes	云原生编排事实标准	reconcile/声明式
API设计	微服务接口契约：REST/gRPC/GraphQL	版本管理
事件驱动	事件溯源+CQRS解耦微服务	Kafka/RocketMQ
Serverless	云原生执行模型极致	缩到零、按请求计费
边缘计算	云原生向边缘延伸	KubeEdge/k3s/OpenYurt
GitOps	云原生部署运维范式	ArgoCD/Flux，声明式+Git
eBPF	云原生数据面下一代	Cilium Sidecarless
多集群	云原生多活容灾	Karmada/Cluster API
Operator	云原生Day-2自动化	CRD+Controller
策略即代码	云原生安全合规	OPA/Gatekeeper/Kyverno
混沌工程	云原生韧性验证	Chaos Mesh
供应链安全	云原生安全基石	Sigstore/SBOM/Trivy
高可用与业务连续性	多集群多活是容灾落地	RTO/RPO/两地三中心
前沿AI技术	AI驱动云原生演进	AIOps/智能调度/异常检测

---

文档说明：本文档遵循软考架构师深挖专题四段结构（理论深挖→计算题型→易混点→双轨口诀）+ 速记总表 + 背诵路线，覆盖云原生微服务架构及服务治理全部考点。计算题型含10题及变式，覆盖拆分粒度/熔断/限流/HPA/可用性/重试放大/一致性哈希/网格开销等高频计算方向。第八章为进阶专题补充扩展，覆盖 Serverless/边缘计算/GitOps/eBPF/多集群/Operator/策略即代码/混沌工程/镜像供应链安全 九大进阶主题，含5道进阶计算题（冷启动计费/边缘延迟/eBPF性能/多集群可用性/GitOps漂移）、8项进阶易混点、8段进阶顺口溜+8组谐音口诀、进阶速记总表。全文 1335 行。