原子标签索引：[概念×14 | 机制×6 | 流程×3 | 决策×1 | 分类体系×6 | 判据×3 | 案例×5 | 数据×7] 上游：第2章（架构概念）、第5章（软件架构风格，微服务） 下游：论文热点章（云原生定义/原则/模式为论文高频素材）
标准表述
- 云原生 = Cloud + Native：应用在云端运行，且从一开始就基于云环境设计，利用弹性+分布式优势。
- 云原生架构定义：基于云原生技术的一组架构原则和设计模式的集合，目标是把应用中非业务代码部分最大化剥离，由云设施接管非功能特性（弹性、韧性、安全、可观测性、灰度等）。
- 云原生应用代码分三部分：业务代码（唯一核心）、三方软件、处理非功能特性的代码；后两部分是附属物。
- 云原生技术依赖传统云计算三层概念：IaaS、PaaS、SaaS。
- 云原生架构七大原则：服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进。
- 主要架构模式七个：服务化、Mesh化、Serverless、存储计算分离、分布式事务、可观测架构、事件驱动。
- 三个典型反模式：庞大的单体应用、单体应用"硬拆"为微服务、缺乏自动化能力的微服务。
- 可观测架构 = Logging（多级别详细跟踪）+ Tracing（完整调用链路）+ Metrics（量化多维度量）。
- 韧性核心目标是提升平均无故障时间 MTBF。
- 零信任核心思想：默认不信任网络内外的任何人/设备/系统，IP、主机、地理位置等不能作为可信凭证；从"网络中心化"走向"身份中心化"。
- Serverless 四特征：全托管、通用性、自动弹性伸缩、按量计费。
- FaaS（函数计算）是 Serverless 最具代表性的产品形态。
- Kubernetes 控制平面四组件：APIServer、Controller、Scheduler、etcd。
- Istio 三大组件：Pilot（服务发现、流量管理）、Mixer（访问控制、可观测性）、Citadel（终端用户认证、流量加密）。
- 服务化架构标准做法：以接口契约（IDL）定义关系，以标准协议（HTTP、gRPC）互联互通，结合 DDD、TDD、容器化部署。
- 服务网格中数据平面与控制平面间的协议标准化是必然趋势（xDS、SMI、UDPA）。
蒸馏笔记
概念
- 云原生架构：剥离非业务代码→云设施接管非功能特性→业务轻量、敏捷、高度自动化。
- 三方软件：业务代码依赖的所有三方库（业务库+基础库）。
- 非功能性特性：不直接带来业务价值但必不可少，如高可用、容灾、安全、可运维性、易用性、可测试性、灰度发布（易用性不能被剥离）。
- 服务化架构：云时代构建云原生应用的标准架构模式；典型为微服务与小服务模式。
- 小服务（MiniService）：一组关系密切、共享数据的服务组合；适用于超大型系统，避免粒度过细带来调用损耗与治理复杂度。
- Mesh化架构：把中间件框架（RPC、缓存、异步消息）从业务进程分离，业务进程只留"薄" Client，流量控制/安全由 Mesh 进程完成。
- Serverless：把应用的整个运行都委托给云；流量到来时云启动/调度进程，处理完自动关闭。
- FaaS：把应用逻辑拆分为多个函数，事件驱动触发执行。
- BaaS：面向特定领域的后端云服务，是 K8s 这个"新一代操作系统"上的服务 API。
- 存储计算分离：暂态数据（session）、结构化/非结构化持久数据都用云服务保存。
- 事件驱动架构（EDA）：本质是应用/组件间的集成架构模式；事件具有 schema 可校验，具备 QoS 保障机制。
- CQRS：命令查询职责分离——影响状态的命令用事件发起，不影响状态的查询用同步 API。
- IaC / GitOps / OAM：实现"所有过程自动化"原则的代表性技术手段。
- 服务网格（ServiceMesh）：将微服务间连接、安全、流量控制、可观测等通用功能下沉为平台基础设施，以无侵入方式实现应用轻量化。
机制
- 云产品解决高可用的三层路径：虚拟机检测硬件异常 →(热迁移) 应用无感知；容器监控检查发现进程异常 →(自动下线/上线+流量切换) 无需运维干预；应用把有状态部分交给云服务 →(变成无状态应用) 业务中断降至分钟级。
- CAP 与弹性：无状态应用不存在一致性（C）维度 →(获得) 更好的可用性（A）与分区容错性（P）→ 弹性更好。
- Docker 镜像：解耦应用与运行环境 → 应用在不同计算环境一致、可靠运行 → 成为应用分发工业标准。
- K8s：屏蔽 IaaS 层差异 + 可移植性 → 应用一致运行于数据中心、云、边缘 → 支持多云/混合云、免厂商锁定。
- EDA 增强服务韧性：服务间异步集成 → 下游处理失败甚至宕机不被上游感知 → 不影响上游。
- 服务拆分的代价：模块数增多 →(缺乏自动化与治理能力时) 人均负责模块数上升 → 开发运维效率反而降低。
流程
- K8s 五大核心能力：资源调度（按 CPU/Memory/GPU 选节点）→ 应用部署与管理（发布/回滚/配置/存储卷）→ 自动修复（节点故障迁移、应用自愈）→ 服务发现与负载均衡（Service+DNS）→ 弹性伸缩（按负载自动扩容）。
- K8s 关键设计：声明式 API（Deployment/StatefulSet/Job；level-triggered 比 edge-triggered 更健壮）→ 可扩展性架构（CRD/Operator 扩展）→ 可移植性（Load Balance Service、CNI、CSI 屏蔽底层差异）。
- 服务网格工作方式：服务 A 调用 B 的请求被服务代理截获 → 代理完成服务发现、熔断、限流 → 策略总控在控制平面配置；无需改造应用即获治理能力。
决策
| 分布式事务模式 | 适用条件/特点 | 代价 |
|---|---|---|
| XA | 需要强一致性 | 性能差 |
| BASE（基于消息的最终一致性） | 追求高性能 | 通用性有限 |
| TCC | 应用层控制事务，隔离性可控、高效 | 业务侵入性非常强，设计开发维护成本高 |
| SAGA | 类似 TCC 但无 try 阶段，每个正向事务配一个补偿事务 | 开发维护成本高 |
| SEATA AT | 要求高性能且零代码改造 | 有使用场景限制 |
分类体系
- 云原生架构七原则：①服务化（代码规模超出小团队协作范围即拆分；限流降级/熔断隔仓/灰度/反压/零信任本质是基于服务流量的控制策略）②弹性（部署规模随业务量自动伸缩）③可观测（日志/链路跟踪/度量，主动关联分析）④韧性（抵御硬件故障、资源瓶颈、流量超限、机房灾难、bug、黑客攻击；手段含异步化、重试/限流/降级/熔断/反压、主从、集群、单元化、跨 region 容灾、异地多活）⑤所有过程自动化（IaC、GitOps、OAM、K8s Operator、CI/CD）⑥零信任（身份为中心）⑦架构持续演进（存量迁移要考虑迁出/迁入成本与风险）。
- 七类主要架构模式：服务化 / Mesh化 / Serverless / 存储计算分离 / 分布式事务 / 可观测 / 事件驱动。
- EDA 六类应用场景：增强服务韧性、CQRS（+Event Sourcing 重放事件重建状态）、数据变化通知、构建开放式接口（提供者不关心订阅者）、事件流处理（Kafka 日志处理）、IoT 事件触发响应。
- 微服务设计约束四类：①个体约束（业务域独立、单一职责 SRP；"两块披萨团队""至少两周一次迭代"为划分隐喻）②服务间横向关系（可发现性→服务注册中心；可交互性→语言无关协议 REST/IDL 二进制；面向失败设计，限流熔断隔仓负载均衡为标配）③与数据层纵向约束（DSS 数据存储隔离原则：数据是私有资产，只能经本服务 API 访问；CQRS 读写分离；无状态设计，计算存储分离）④全局分布式约束（全自动 CI/CD、蓝绿/金丝雀发布、全链路可观测、中心化监控）。
- 主要微服务技术：Apache Dubbo（阿里，高性能 RPC，v3 融合 ServiceMesh）；Spring Cloud（配置管理/服务发现/断路器等）；Eclipse MicroProfile（Java 微服务规范）；Tars（腾讯 TAF 开源）；SOFAStack（蚂蚁金服金融级，组件 MOSN 为 Go 语言数据平面代理）；DAPR（微软，可移植、无服务器、事件驱动运行时）。
- 服务网格方案：Istio（数据平面 Envoy，控制平面自研；xDS 协议）；Linkerd（Rust 数据平面，时延/资源消耗优于 Istio）；Consul（数据面可选 Envoy，功能不如 Istio 完整）；Conduit（K8s 超轻量级，Rust 数据面+Go 控制面）。
判据
- Serverless 适用性判据：有状态应用 → 调度不做状态同步，上下文丢失，不适合；长时间后台运行的密集型计算 → 无法发挥优势；频繁外部 I/O（网络/存储/服务间调用）→ 时延大，不适合。适合：事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
- 服务化拆分时机判据：代码规模超出小团队合作范围 → 有必要拆分为微服务/小服务。
- "硬拆微服务"识别判据：小规模软件强行拆分（发布拆成多模块）→ 反模式；服务拆分但数据紧密耦合共享数据库 → 数据依赖扇出，反模式；强耦合模块拆分后本地调用变分布式调用 → 响应时间放大上千倍，链路性能急剧下降。
案例
- 某旅行公司云原生改造（14.4.1）：三阶段改造私有云/混合云，用独享集群 40% 的机器支撑全线业务，单机资源利用率提升 20%，弹性扛住日常 300% 峰值流量。
- 某汽车公司数字化转型（14.4.2）：容器云平台+私有云公有云混合交付+微服务业务中台+DevOps，应用交付周期从两个月缩短到一个月。
- 某快递公司核心系统上云（14.4.3）：VMware+Oracle 架构转型为 K8s 云原生，方案为"阿里云 ACK+神龙+云数据库"，引入 OLTP/OLAP 拆分并做容器化微服务改造。
- 某电商业务云原生改造（14.4.4）：ACK+链路追踪+PTS 压测+AHAS 限流降级，大促保障常态化，服务器成本节约 50% 以上。
- 某体育用品公司业务中台（14.4.5）：打通 63 套烟囱系统，建七个共享服务中心，6 个月建设、4 个月实现全国 42 家分公司、6000+ 门店上线；售罄率提升 8%、缺货率降低 12%、周转率提升 20%，核心交易链路并发可支撑 10w tps。
数据
| 数据项 | 数值 | 条件/出处 |
|---|---|---|
| 容器交付效率提升 | 3~10 倍 | 使用容器技术（统计） |
| 容器降计算成本 | 约 50% | 部署密度提升+弹性 |
| 服务网格调用延迟增加 | 可控制在 2% 以内 | 针对百毫秒级业务调用 |
| 服务网格高可用 | 4 个 9（99.99%）以上 | 服务化应用未改造即获得 |
| 边缘计算落地规模 | 10万+ 异构设备、30多万边缘应用 | 国家的路网中心取消省界收费站项目 |
| 云上 SLA | 至少 5 个 9（99.999%） | 公有云产品（快递案例） |
| 阿里云云上组件 | 超过 300 余种 | 覆盖计算、AI、大数据、IoT |
易错点 / 边界情况
- 非功能特性剥离"不会是所有"——易用性仍不能剥离。
- 可观测性 ≠ 监控/APM：可观测是分布式系统中主动通过日志、链路跟踪、度量做关联分析的能力。
- Mesh化后熔断、限流、降级、重试、反压、隔仓均由 Mesh 进程完成，业务制品中无需这些三方软件包。
- 限流降级、熔断隔仓、灰度、反压、零信任安全等本质是基于服务流量（而非网络流量）的控制策略。
- 分布式事务辨析：BASE 高性能但非强一致；TCC 侵入性最强；SAGA 无 try 阶段；SEATA AT 无代码开发量但有场景限制——勿混淆各自优缺点。
- 微服务接口选择：REST 满足"语言无关+标准化"；高性能场景应选基于 IDL 的二进制协议。
- 存储计算分离的例外：交易会话数据太大时放远端缓存会明显拖慢交易，可用时间日志+快照（检查点）实现重启后快速增量恢复。
- Serverless 普及障碍：事件驱动改变开发习惯与交付流程、函数生态不成熟、冷启动延迟与按需建立数据库连接成本高。
- Serverless 新形态：容器融合（阿里云 ECI/SAE、Google CloudRun、开源 Knative），容器镜像无需修改即可部署。
- Istio 数据平面是 Envoy（源自 Lyft）；Dubbo 协议已被 Envoy 支持。