先判断：ECS 迁到 Serverless，解决的是什么问题
把 HTTP 服务部署在 ECS 上，优点是运行环境直观、长连接和本地进程都容易管理。但如果业务流量有明显峰谷，常驻实例也意味着低峰期仍要为预留的 CPU、内存和磁盘付费。扩容通常还需要提前估算容量，缩容则要考虑发布、连接和数据迁移风险。
Serverless 迁移并不是简单地把一台 ECS 换成函数。它改变的是资源使用方式：应用代码以函数形式运行，HTTP 请求由 API Gateway 或其他事件源触发，计算实例按需创建和回收。数据库、对象存储、缓存等有状态能力则继续放在函数之外。这样，业务可以把“持续占用一台机器”改成“请求到来时使用计算资源”。
因此，Serverless 更适合解决三类问题：流量不稳定、业务需要快速弹性、团队不希望维护大量主机。对于全天候高负载、强依赖本地状态或必须长期保持进程的服务，迁移收益可能并不明显。
成本不能只看单价，要比较完整账单
ECS 与函数计算的成本模型不同。ECS 通常按实例规格和购买时长计费，函数计算则会受到调用次数、执行时长、内存或 vCPU 配置、实例并发、网络流量以及网关请求量等因素影响。数据库、日志、镜像仓库和公网带宽也不能从迁移账单中省略。
可以用下面的方式做第一轮估算：
- 统计一个月的请求量、峰值并发、平均执行时长和资源配置。
- 把 API Gateway、函数计算、日志、公网流量及依赖服务的费用分别列出。
- 用同一业务量与可用性目标，计算 ECS 的实例、带宽、磁盘和运维成本。
- 分别模拟低峰、正常和突发流量，观察弹性策略是否会带来额外实例费用。
按量模式的优势是低峰期可以释放计算资源，但“请求少”不等于“总成本为零”。如果配置了最小实例数，或函数需要持续占用资源，就会产生相应费用；API Gateway、日志和流量也可能成为独立的成本项。阿里云函数计算的计费项目和价格会随地域、实例类型及计费模式变化，正式迁移前应以当前地域的官方计费页面和账单测算为准，不要直接套用文章中的固定金额或节省比例。
对极低频服务，还要关注实例释放和最低计费规则；对高并发服务，则要关注并发上限、扩容速度以及下游数据库是否能够承受流量。正确的比较对象不是“函数单价”和“ECS 月租”的简单相减，而是达到同一性能和可靠性目标时的总拥有成本。
冷启动怎么评估：先测用户请求，再决定是否预留实例
函数实例从没有运行环境到能够处理请求，可能经历镜像或代码下载、运行时初始化、依赖加载和业务初始化，这段额外时间就是冷启动延迟。它不是一个固定值，语言、依赖包大小、镜像体积、初始化逻辑、实例类型和所在地域都会影响结果。
迁移前至少应测量以下指标：
- 首次请求的 P50、P95 和 P99 延迟；
- 热实例与冷实例的差值；
- 并发突增时的扩容时间和错误率；
- 业务初始化是否包含连接数据库、加载模型或读取大文件；
- 实例回收后再次访问的恢复时间。
如果接口允许短暂延迟，可以先使用最小实例数为 0 的配置，观察真实流量下的冷启动比例。若登录、支付回调或在线交互等链路对延迟更敏感，可以配置预留或最小实例，换取更稳定的响应时间，但这会把一部分“按需”资源变成持续成本。定时伸缩也适合有明确工作时段的系统，例如在业务开始前预热，在夜间降低预留规模。
优化冷启动通常比盲目提高规格更有效：减少依赖包和镜像体积，把大文件放到 OSS 或 NAS；把数据库连接、配置加载等初始化逻辑设计成可复用；避免在函数启动阶段执行不必要的网络调用；为不同接口拆分合理的函数，而不是让所有功能共享一个庞大的运行时。
GPU 或大模型推理场景还要单独评估资源准备时间、模型加载时间和显存占用。它们的冷启动特征与普通 CPU Web API 不同，是否采用常驻实例，应由延迟目标、调用密度和模型加载成本共同决定。
哪些业务适合迁移，哪些业务要谨慎
更适合 Serverless 的场景
- 有明显峰谷的管理后台、活动接口和轻量 Web API；
- Webhook、定时任务、文件转码、图片处理等事件驱动任务；
- 新项目或流量尚未稳定、需要快速试错的应用；
- 希望把网关、弹性和基础运行环境交给平台管理的小型团队；
- 计算过程相对独立，可以通过数据库、缓存或对象存储保存状态的服务。
需要谨慎评估的场景
- 长连接、长时间运行进程或依赖本地文件持续存在的应用；
- 长期高并发且利用率稳定的服务，函数按量计费未必比包年 ECS 更便宜；
- 对尾延迟非常敏感，且无法接受预留实例成本的核心链路；
- 强依赖特定操作系统、内核模块或主机级网络配置的程序；
- 需要大量 GPU 资源并且模型加载时间很长的推理服务。
这些场景并非绝对不能迁移，也可以采用混合架构：把突发、异步和低频接口放到函数计算，把稳定高负载、长连接或特殊运行时保留在 ECS 或容器平台。
从 ECS 迁移的落地顺序
1. 先拆分入口与状态
用 API Gateway 承接域名、路由、鉴权、限流和跨域等入口能力，函数只处理相对独立的业务逻辑。不要把会话、上传文件或任务队列放在函数本地目录；临时目录只适合短生命周期的中间文件。
2. 改造配置和依赖
把密钥、数据库连接信息和环境配置放入受控的配置或密钥管理服务。检查依赖包在目标运行时中的兼容性，设置合理的超时、内存、并发和重试策略。重试必须配合幂等设计，否则网关或事件源重试可能造成重复写入。
3. 用小流量验证可用性
先部署一套与生产隔离的函数版本，使用回放请求或灰度流量测试。重点检查返回码、超时、日志完整性、数据库连接数、重复消费和权限边界，再逐步提高流量比例。
4. 建立成本和性能观测
为网关、函数、数据库、缓存和流量设置统一的监控维度。至少保留调用量、执行时长、并发实例、冷启动、错误率、下游连接数和费用数据。迁移后的第一周不要只看平均延迟，P95/P99 和峰值时段更能反映用户体验。
结论：Serverless 迁移是一种容量策略
ECS 迁移到“函数计算 + API Gateway”最有价值的地方，不是承诺一个固定的节省百分比，而是让计算容量更贴近实际请求。对于峰谷明显、事件驱动和需要快速弹性的服务，按需扩缩容可以减少闲置资源和容量规划工作；对于稳定高负载、长连接或强主机依赖业务，保留 ECS、采用容器，或使用混合架构可能更合理。
做决定时，建议先用真实流量完成成本、冷启动和下游承载能力测试，再确定是否设置最小实例、是否保留部分 ECS，以及哪些接口适合分批迁移。迁移的目标应是更合适的资源模型，而不是为了使用 Serverless 而迁移。