云原生概要介绍

这是 ACA 云原生工程师认证备考笔记的第一篇。目的不是背下官方课程的 9 个课时标题，而是想清楚一件事：云原生这一整套技术栈，到底是为了解决什么问题才长成现在这个样子的。想清楚了因果关系，后面每一章遇到的产品名字（ACK、EDAS、RocketMQ、云效……）才不会是孤立的名词，而是这条链条上的某一环。

考试怎么考

先摸清楚规则：

项目	内容
满分 / 及格分	100 分 / 80 分
考试时长	60 分钟，线上闭卷
单选题	35 题，每题 2 分，共 70 分
多选题	15 题，每题 2 分，共 30 分

四大知识板块的分值权重：

知识点	权重	对应本合集章节
云原生基础	20%	第 1 章
阿里云容器服务	25%	第 2、3 章
阿里云微服务	40%	第 4、5 章
DevOps	15%	第 6 章

"阿里云微服务"这一块占了 40%，是绝对的大头，第 4、5 章会拆成 6 篇笔记来写。而"云原生基础"虽然只占 20%，但概念密度最高——这一章不能因为它"只是铺垫"就写得潦草。

一个根问题：环境不一致

在容器出现之前，软件交付有一个长期存在的痛点："在我电脑上能跑"。开发环境、测试环境、生产环境的操作系统版本、依赖库版本、配置项都可能不一样，代码从一个环境搬到另一个环境，经常出问题。

传统的解决办法是虚拟机（Hypervisor 把一台物理机切成多台虚拟机），但虚拟机本身很重——每一台虚拟机都要装一份完整的操作系统，启动要分钟级，资源开销也大。

容器（以 Docker 为代表）解决的正是这个问题：把应用连同它的依赖、配置一起打包成一个镜像，不管在哪台机器上运行，行为都一致；容器共享宿主机内核，不需要装完整操作系统，所以启动是秒级的，开销也小得多。

这是云原生这条技术链条的起点。三种隔离方式对比一下：

	物理机	虚拟机	容器
隔离粒度	整机	操作系统级（Hypervisor）	进程级（共享宿主机内核）
启动速度	分钟到小时级	分钟级	秒级
资源开销	最高（独占整机）	高（每台 VM 一份完整系统）	低（不需要重复的系统开销）

从容器到一整套技术栈：一条因果链

容器解决了"环境不一致"，但马上带来新问题。云原生技术栈，就是一环接一环解决这些新问题长出来的。

1. 容器多了，谁来调度？

一个应用可能拆成几十上百个容器实例，分布在成百上千台机器上。哪个容器该起在哪台机器上、挂了要不要自动重启、要扩容该加几个实例，人工管不过来。于是有了容器编排，事实标准是 Kubernetes（源自 Google 内部的 Borg 系统，2014 年开源），负责调度、服务发现、健康检查、自动伸缩。

2. 单体应用改不动了怎么办？

底层调度问题解决了，应用本身还是一个大单体的话，改一行代码也要整体重新构建、重新发布，团队规模大了互相拖累。服务化（微服务）架构模式的做法是按业务模块拆成独立开发、独立部署、独立伸缩的小服务，服务之间通过标准协议（HTTP、gRPC）和接口契约通信。

3. 服务拆多了，中间件逻辑往哪放？

微服务之间要互相调用，就需要 RPC 框架、注册发现、限流熔断这些中间件能力。如果以 SDK 形式打进每个服务的代码里，业务代码和中间件版本就耦合死了，升级一次 SDK 要重新发布所有服务。Mesh 化架构模式（服务网格） 的思路是把这些中间件能力从业务进程里剥出来，下沉到独立的 Sidecar 进程，业务代码不再感知中间件逻辑，中间件升级和业务发布彻底解耦。

4. 有些场景，连"管几个容器"都嫌多余

一个月只跑一次的定时任务、流量完全随机的接口，为它们长期占着容器资源不划算。Serverless 架构模式把"要不要管服务器"也变成一个可以放弃的选项：用户只写业务逻辑，按调用次数付费，平台负责弹性伸缩，包括缩到零和从零启动。

5. 有状态和无状态混在一起，弹性做不彻底

计算逻辑和数据存储绑在同一个实例里，这个实例就没法说加就加、说减就减，因为数据还在上面。存储计算分离模式把有状态的部分（数据库、存储）和无状态的部分（计算逻辑）拆开，计算层随时扩缩容，存储层留在稳定可靠的地方专心保数据。

6. 微服务各自有自己的数据库，事务怎么保证？

单体应用时代，一个事务用一个数据库的本地事务就能保证一致性。微服务提倡"一个服务一个私有数据源"，一次业务操作可能跨好几个服务的数据库，传统的单库事务不再适用。这就需要分布式事务模式，通过 XA、BASE、TCC、SAGA、AT 等方案，在跨服务、跨数据库的场景下保证数据最终正确。

以上服务化、Mesh 化、Serverless 化、存储计算分离、分布式事务，是阿里《云原生架构白皮书》明确给出的五种云原生架构模式。不是每个系统都要五种全用上，而是按业务规模和成熟度选择组合。选择题里容易考一个认知点：云原生不是全有或全无的选择，是一条可以分阶段走的路。

7. 分布式系统里，故障是常态

服务拆得越细，调用链越长，一个下游服务变慢就可能拖垮整条调用链，形成雪崩。这不是"会不会发生"的问题，是"多久发生一次"的问题。应对思路有两层：限流降级提前设计好"允许哪些部分先坏"，混沌工程则主动注入故障来验证系统的抗压能力。（具体产品见第 5 章）

8. 出了问题，怎么知道是哪一跳出的？

一次请求可能跨十几个服务，"登录一台机器看日志"在分布式系统里已经不够用了。压测提前摸清系统极限在哪，监控和链路追踪让故障发生时能定位到具体哪个服务出了问题。这一整块能力叫可观测性。（具体产品见第 5 章）

9. 技术栈都到位了，发布流程还是手工？

服务数量上去之后，"改代码 → 测试 → 上线"这条链路还靠人工串行操作的话，团队规模再大也快不起来。DevOps 把交付流程本身也自动化、工程化，用流水线保证每一次发布都可重复、可回滚。（具体见第 6 章）

云原生的核心技术，官方是怎么定义的

上面这条因果链落到具体名词上，正好对应 CNCF（云原生计算基金会）对"云原生"的官方定义，而这个定义本身也是逐年扩充的：

年份	CNCF 定义包含的技术
2015 年成立时	容器化封装、自动化管理、微服务化
2018 年更新后	在原有基础上，新增服务网格（Service Mesh）、声明式 API

"声明式 API"指的是只描述"我要什么最终状态"（比如"我要 3 个副本"），由系统自己想办法达成，而不是一步步命令"先做这个、再做那个"。Kubernetes 的资源定义（YAML）就是声明式 API 的典型体现，也是容器编排能够自动化、自愈的基础：系统持续对比"期望状态"和"实际状态"，有差异就自动纠正。

再加上不可变基础设施（容器一旦构建就不在原地修改，要变更就整体替换成新版本，而不是登进去改配置）。容器、编排、微服务、服务网格、声明式 API、不可变基础设施，这六个技术要素加上 DevOps 的工程文化，就是目前公认的云原生核心技术清单。

"云原生"和"云计算"是什么关系

云计算的发展可以粗分成两个阶段：

上半场：解决"有没有云"的问题——计算、存储、网络这些基础设施完成云化（IaaS），企业不用自己买机器、建机房。
下半场：解决"云要怎么用好"的问题——光把应用原封不动搬上云，享受不到云的弹性、自愈、按需这些能力。云原生要回答的正是下半场的核心命题：应用该怎么设计，才能天生就适配云、把云的能力发挥到极致，而不是"云化的传统应用"。

阿里巴巴自己的云原生历程

阿里巴巴自己的云原生化，大致走过三个阶段：

阶段	时间	特征
第一阶段	2006 年—2015 年	应用架构互联网化——从集中式走向分布式，三大中间件体系上线，自研飞天操作系统启动
第二阶段	2016 年—2019 年	核心系统全面云原生化——容器技术开始对外开放，2017 年阿里巴巴开始实现规模化容器云化
第三阶段	2020 年至今	全面升级下一代云原生技术——2020 年成立云原生技术委员会，云原生升级为阿里技术新战略，Serverless 时代开启

在这条路上，阿里云把自己的云原生能力总结成"五个最"：

"最"	具体指什么
最丰富	云原生产品家族
最全面	云原生开源贡献
最广泛	云原生客户群体
最大规模	云原生应用实践
最高等级	全球云原生评级

这五个词是选择题里会直接考的固定搭配，记的时候记"是什么最 + 最在哪个维度"这对组合，而不是死记五个形容词。

补充几个常考的具体年份：2009 年阿里云成立、启动飞天系统研发；2018 年宣布全面上云战略；2019 年核心交易系统完成全面上云（当年双 11 验证通过）。

阿里云云原生产品体系：一张地图

最后预告一下后面几章要展开的产品，先建立一个整体印象：

容器产品家族（第 3 章）：ACK（Kubernetes 版）、ASK（Serverless Kubernetes）、ACR（容器镜像服务）、ASM（服务网格）
微服务与 Serverless 产品家族（第 4 章）：MSE（微服务引擎，涵盖注册配置中心和云原生网关）、EDAS（企业级分布式应用服务）、函数计算 FC、SAE（Serverless 应用引擎）
消息队列与稳定性中间件（第 5 章）：消息队列 RocketMQ 版 / Kafka 版、AHAS（应用高可用服务，涵盖限流降级和混沌工程）、PTS（性能测试服务）、ARMS（应用实时监控服务）
DevOps 平台（第 6 章）：云效

这张地图上的每一个名字，都是前面那条因果链里某一环的具体产品化落地——下一章从容器技术基础开始，正式往下走。