去年深秋在南京软件谷的共享会议室，对面坐的生鲜配送团队技术负责人攥着半杯凉掉的美式，说他们现在的订单峰值一到下午四点半就炸，平时的服务器又闲得长草，每个月光云服务器成本就占了技术预算的40%，问我能不能上Serverless。
我当时没直接给肯定答案。
毕竟见过太多团队被厂商的宣传忽悠上去，最后踩坑踩得脚都肿了。
先别听厂商吹的那些无服务器神话
很多人对Serverless的第一印象，就是“完全不用管服务器，写好函数扔上去就行”。真不是。
那个团队之前自己摸过某云的函数计算，把下单接口搬上去的第一天就踩了坑：冷启动延迟干到了800ms，用户点提交订单转半天圈，当天直接掉了12%的单。
当时我看着监控曲线直拍大腿——早知道他们的函数包塞了三个第三方依赖，体积快80M，冷启动慢是必然的，我之前就不会拍胸脯说这个方案快。
更离谱的是，有个做在线教育的朋友跟我吐槽，他们之前把学生答题的接口搬到Serverless上，为了图省事给函数绑了个全权限的云账号角色，结果不小心把代码传到了公开的代码仓库，不到半小时，整个云账号下的所有存储桶都被人删光了，还留了个勒索信息。
你总不能说，我用了Serverless，代码写错了、权限配错了，也怪云厂商吧？
那些吹“零运维”的宣传，本质上是把运维的工作从“管服务器硬件、扩缩容”，转移到了“管函数权限、管依赖大小、管超时配置”。工作量是减了，但不是完全没了。
真算过账的团队才知道它到底省在哪
后来给那个生鲜团队做方案的时候，我没让他们把全量接口都搬上去。
他们的业务波动太规律了：下午四点半到六点是订单峰值，CPU能冲到90%，凌晨两点到早上八点，CPU常年在5%以下晃悠，之前为了扛峰值买的8台4核8G服务器，一半时间在空转，每个月光固定成本就3200块。
我们最后定的方案很简单：核心的用户服务、库存基础服务继续跑在固定服务器上，只把波动最大的几块业务切到Serverless上——高峰期的下单接口、凌晨的对账计算、用户验证码发送、订单完成后的短信通知。
跑了三个月，算下来这部分业务每个月的Serverless成本才300多块，加上留的2台固定服务器的400块成本，整个技术团队的基础设施月成本直接从3200降到了1100。
别高兴太早。不是所有业务都适合搬上来。
他们试过把7*24小时稳定运行的用户画像服务搬到Serverless上，结果算了下成本，比之前固定跑的价格贵了整整1.2倍——毕竟这类业务的调用量是平的，没有波动，按调用次数和执行时长计费的模式，根本比不过预留实例的固定成本。还有长连接的WebSocket聊天功能，函数的执行时长上限就那么点，总不能让函数一直挂着等用户发消息，纯纯浪费钱。
给想试的团队留几个实打实的建议
说实话，我见过太多团队上来就全量迁Serverless，最后出问题了就说这技术是垃圾，其实是自己的打开方式不对。
第一，别上来就全量切。先从波动最大、最边缘的业务试，比如定时任务、文件上传后的图片压缩、短信通知这类，就算出问题了，对核心业务的影响也不大，跑个两周摸清楚真实的冷启动情况、成本情况，再逐步扩大范围。
第二，把依赖包压到最小。之前那个生鲜团队的函数包从80M压到12M之后，冷启动时间直接从800ms降到了120ms，用户完全感知不到。能删掉的冗余依赖全删掉，能共用的库别每个函数都塞一份，冷启动的速度上去了，用户体验的问题就解决了大半。
第三，一定要遵循最小权限原则。别给函数绑个全权限的云账号角色，就给当前业务需要的那点权限，数据库密码、API密钥这些全存在密钥管理服务里，别硬编码到代码里。上次那个被勒索的教育团队，就是图省事把密钥写在了代码注释里，才被人扫到的。
第四，给依赖的服务做好连接池限制。之前他们把库存扣减的逻辑搬到函数上的时候，遇到大促并发直接飙到2000个函数实例，把数据库的连接池直接打满了，后来给这个逻辑加了个消息队列削峰，才彻底解决问题。
上周那个生鲜团队的负责人给我发消息，说现在他们的技术团队从5个人减到了3个人，每个月省下来的预算全给运营团队做满减活动，这个月的订单量涨了27%。
Serverless从来不是什么能颠覆行业的黑科技。
它就是个工具而已。
就像你开奶茶店，高峰期临时雇几个兼职帮你做单，闲的时候只留固定的两个员工，没必要为了高峰期那两个小时，常年雇10个人站在店里擦杯子。
对吧。