无服务器架构选型别只看功能清单

无服务器架构选型别只看功能清单Serverless 适合把间歇性、无状态的工作交给平台运行但它不会自动消除容量、成本和排障问题。选型时最该问的不是“能不能自动扩缩”而是请求持续多久、依赖什么、失败怎样重试、流量突然增加时谁会先达到上限。用工作负载决定边界短 HTTP 请求、异步图片处理和定时任务通常适合函数模型。长期 WebSocket、大量持续计算、稳定的高吞吐消费者可能更适合常驻服务或专门的任务系统。不要因为一个架构名流行就把全部组件搬进去混合部署往往更符合实际。数据库是常见瓶颈。函数实例扩张会同时建立连接直接让每个实例连数据库可能耗尽连接数。应结合数据库代理、连接复用或平台提供的连接机制并设置函数并发上限。上限不是性能优化的小参数它是在保护数据库和预算。export function retryDelay(attempt: number): number { const capped Math.min(attempt, 5); return 200 * 2 ** capped; }重试策略也不能只写一个指数退避。要区分可重试的超时与不可重试的参数错误给队列设置最大尝试次数和死信去向并保证消费者幂等。否则下游故障时平台会持续放大相同工作账单和数据错误一起增长。发布与观测要围绕版本每个发布应有不可变版本、配置来源和回退动作。灰度时观察成功率、延迟、冷启动、下游错误和业务完成率不应只靠一次预热请求判断冷启动已经解决。预留并发可以降低部分延迟但会改变成本是否使用要经过真实流量验证。函数日志应带请求 ID 和版本号追踪要覆盖网关、函数、消息队列和数据库调用。敏感字段不能直接写进日志。事故时需要能回答哪一版开始出问题、影响了哪些请求、待处理消息在哪里、回退后怎样防止重复执行。最后评估迁移成本。把业务逻辑包在平台适配层外面、避免到处直接依赖厂商事件对象会让以后切换运行环境更容易。但不必为了“完全可移植”牺牲当前可维护性。选择团队能运维、能定位、能控制成本的组合才是合适的 Serverless 架构。可以先选一个低风险接口完成从开发、部署、告警到回退的闭环再扩展到核心链路。实践过程中记录真实的执行时间、并发和下游连接数下一轮容量与成本决策才有依据。架构不是一次采购而是一组会随负载调整的运行约束。若平台计费按调用、执行时间和出网分别计算预算告警也要覆盖这几项。成本异常越早发现越容易把问题限制在一个小发布范围内。定期清理不再使用的版本、日志和测试资源也应有审批与保留期限。否则一次次试验留下的对象会让成本与权限面悄悄扩大。