微服务和 Serverless 架构（二）

上一节讲的 EDAS、MSE 这些产品，前提都是"用服务器或容器跑微服务"。但还有一类场景，用户连服务器都不想管。

---

Serverless 理念的出现

Serverless 不是"没有服务器"，服务器依然存在，只是运维它的责任从用户转移给了云厂商。用户只需要写业务逻辑，不用关心底层有多少台机器、怎么扩缩容、怎么打补丁。

Serverless 通常包含两层含义：

• FaaS（函数即服务）：把代码拆成一个个函数，由事件触发执行，按调用次数和执行时长计费，没有请求的时候几乎不产生费用——对应的产品是函数计算 FC
• BaaS（后端即服务）：数据库、消息队列、对象存储这些后端能力，直接调用云厂商提供的托管服务就行，不用自己搭建和运维

这一节重点看 FaaS 这条线上的两个产品：函数计算 FC 和应用引擎 SAE。

---

函数计算 FC：函数粒度的 Serverless

FC（函数计算，Function Compute）是事件驱动的计算服务：用户只写函数代码，上传或直接在线编写，不用考虑服务器、容器、扩缩容这些底层细节。

它靠触发器和事件源关联——一个事件源（比如一次 HTTP 请求、一个定时任务的到点、OSS 里新上传了一个文件、消息队列来了一条新消息）发生的时候，会同步或异步地触发对应的函数执行。

计费上是按量付费：根据函数实际消耗的计算资源（调用次数 × 执行时长）计费，没有调用就几乎不产生费用；如果业务量稳定可预期，也可以购买资源包或锁定常驻资源池来降低成本。

典型应用场景都有一个共同点——短时、轻量、事件触发：图片上传后自动压缩裁剪、音视频转码、数据 ETL 清洗、定时任务、轻量级 API 后端、AI 推理服务。

---

Serverless 与微服务的结合：SAE

FC 的粒度是"一个函数"，但企业里大量存量应用是完整的 Spring Boot、Dubbo 微服务，没法拆成一个个函数重写。SAE（Serverless 应用引擎）就是面向这类场景的：应用粒度的 Serverless。

SAE 的定位是零代码改造、全托管的应用平台：

• 支持直接用源代码、代码包（WAR/JAR/ZIP）或 Docker 镜像部署，原有的 Spring Cloud、Dubbo 应用基本不用改造就能跑起来
• 用户不用感知底层是多少台 ECS 或者多少个容器实例，SAE 自动伸缩
• 按实际使用量付费，流量低谷时甚至可以缩容到接近 0

三者放在一起对比，能看清楚各自的定位：

	治理粒度	用户要不要感知底层实例	典型场景
EDAS	应用	需要（要规划实例规格和数量）	长期稳定运行、需要精细化治理的核心微服务
SAE	应用	不需要（自动伸缩）	已有微服务应用想直接上云、免运维
FC	函数	完全不需要	短时、事件触发的轻量任务

---

云原生架构核心技术总结

到这里，第 4 章把第 1 章因果链里"微服务、Mesh、Serverless"这几环落到了具体的阿里云产品上：容器和编排（第 2、3 章）让应用跑起来，EDAS 和 MSE 管微服务的治理和注册配置，FC 和 SAE 让用户连服务器都不用管。

这几类产品是同一条谱系上的不同刻度，从"用户管一切"到"平台管一切"，托管程度逐步加深。选哪一个不是看哪个更先进，是看业务形态：稳定的核心系统适合精细化治理，短时事件驱动的任务适合交给 Serverless。

下一章往因果链的下一环走：服务拆得越细，一个环节出问题就越容易连锁反应。消息队列、限流降级、混沌工程、监控，都是为了解决这个问题。