微服务和 Serverless 架构（二）

上一节看了应用托管、注册配置和微服务治理。这一节继续看运维分工：如果连底层服务器和集群都交给平台，应用能省掉哪些工作，又有哪些事仍然要自己管。

Serverless 接走哪些工作

Serverless 不是“没有服务器”，服务器依然存在，只是底层基础设施的运维由云厂商承担。用户不用逐台购买、维护机器，但仍要配置应用需要的资源、权限和弹性策略，也要处理代码与依赖里的问题。

理解这个概念时，经常会遇到两个词：

• FaaS（函数即服务）：围绕函数执行代码，由请求或事件触发，平台负责调度执行实例——函数计算 FC 是典型产品
• BaaS（后端即服务）：通过托管服务使用数据库、消息队列、对象存储等后端能力，减少自行搭建和运维的工作

Serverless 也可以托管完整应用，SAE 是应用粒度的 Serverless，不需要先把应用拆成函数。两者的常见使用方式和责任边界放在一起看：

图按常见用法帮助理解，不能当作两款产品严格的能力边界。Serverless 也不统一等于按调用收费或空闲时自动缩到零：运行形态、最小实例数和计费项都需要单独确认。

函数计算 FC：围绕事件运行

FC（Function Compute，函数计算） 是事件驱动的计算服务，可以交付代码，也可以使用镜像。平台调度执行实例，用户配置资源规格、并发、超时等参数。具体支持的运行方式见FC 产品说明。

它靠触发器关联事件源：一次 HTTP 请求、一个定时任务到点、OSS 新上传一个文件、消息队列来了一条消息，都可能触发函数。不同事件源的同步、异步调用方式和失败处理规则不同；涉及重试时，业务尤其要注意重复执行。

常见场景有图片压缩裁剪、音视频转码、数据 ETL 清洗、定时任务、API 后端和 AI 推理。共同点是工作可以围绕请求或事件组织，不必一律是“短时、轻量”；任务时长、资源需求和启动延迟是否合适，仍要核对。

计费不能简单写成“调用次数 × 执行时长”。FC 将调用次数、CPU 与内存等资源的规格和占用时长分别计量，再折算成 CU；配置最小实例数后，空闲实例也可能产生费用。涉及成本时要按FC 计费说明和实际配置计算，还要计入公网流量等费用，不能从“没有调用”直接推导出“没有费用”。

SAE：托管完整应用

企业里大量存量应用是完整的 Spring Boot、Dubbo 微服务。SAE（Serverless 应用引擎） 面向应用托管，可以从源代码、代码包或镜像部署，底层服务器和集群由平台管理。

它省掉的是自行维护基础设施的工作，不是让应用实例从视野里消失：

• 部署已有应用：通常能沿用现有交付物，但运行环境、启动方式、依赖服务和网络访问仍要满足平台要求
• 配置资源和弹性：用户仍选择实例规格、设置数量或弹性规则，再由平台执行扩缩容
• 按使用量核算成本：能否缩到零、什么条件下唤醒，要看应用形态和弹性功能的支持范围；保留实例就不能假定空闲免费

SAE 产品说明介绍了应用托管和弹性能力，实例规格说明则保留了 CPU、内存等具体选择。把“免去集群运维”和“无需容量决策”分开，比较容易理解这层分工。

按业务形态选

EDAS、SAE、FC 有能力交集，也各有适合的交付方式。可以先按手上的工作来缩小范围：

手上的工作	可以先看	仍需确认
已有 ECS 或 Kubernetes 资源，希望统一管理应用发布和微服务治理	EDAS	集群与框架接入、资源规划、治理能力
希望直接托管完整应用，减少底层集群维护	SAE	运行环境与依赖、实例规格、伸缩规则和成本
工作围绕请求或事件触发，适合以函数组织	FC	触发语义、超时与并发、冷启动、失败重试和计费

这不是一条必须从 EDAS 升级到 SAE、再升级到 FC 的路线。同一个系统里，也可以让长期运行的服务和事件处理函数各做合适的工作。托管程度变了，业务正确性、数据安全和故障处理的责任仍然在。

下一章继续看稳定性：服务已经能跑起来，怎样用消息队列减少同步等待，用限流降级控制故障影响，再通过监控和演练检查这些安排有没有生效。