为什么是这两个方向
每年都有人说"前端已死"，每年前端都在进化。2024年我看下来，真正有落地价值的不是那些花里胡哨的新框架，而是Serverless和边缘计算这两个基础设施层面的变化。原因很简单：它们直接解决了成本和性能两个核心问题。
我们团队今年在郑州做了两个项目的实践：一个是金水区一个教育机构的官网改版用了Serverless方案，另一个是郑东新区CBD一个商场的小程序用了边缘计算方案。下面分享一下实际数据和踩坑经验。
Serverless：运维成本降40%
金水区这家教育机构叫启智教育，主要做K12课外辅导。官网功能不复杂：课程展示、师资介绍、在线报名、新闻资讯。之前部署在阿里云ECS上，2核4G配置，每月服务器费用280元，加上域名、SSL、CDN等杂费月均350元左右。每次遇到流量突增（比如招生季），还得手动扩容，运维负担不小。
改用Serverless方案后，架构变成：前端静态资源部署在阿里云OSS加CDN上，后端函数计算（FC）处理API请求，数据库用阿里云的Serverless RDS（按使用量计费）。改造花了2周时间，主要工作是把原来ThinkPHP的后端逻辑拆分成26个云函数。
改造后的月度费用：OSS存储3元、CDN流量45元、函数计算调用费18元、Serverless RDS约80元。总计146元，比之前的350元降了58%。但函数计算有冷启动问题，第一次请求会慢200-500ms。我们用了"预留实例"功能解决了这个坑，费用增加20元，总费用166元，还是比之前省了52%。
运维成本下降更明显。之前ECS需要定期更新系统补丁、监控磁盘和内存、处理安全告警，每月大概花8个人时。Serverless之后这些全不用管了，运维时间几乎为零。按我们团队的时薪80元算，每月省了640元运维人力成本。加起来一年省6300多元，对小机构来说不是小钱。
边缘计算：首屏快了300ms
郑东新区CBD的商场小程序，核心问题是首屏加载慢。用户在商场里连WiFi打开小程序，首屏渲染要1.8秒。排查后发现瓶颈在API请求上——服务器在郑州高新区，到CBD的物理距离虽然只有15公里，但网络链路要经过3个跳转，API响应延迟约400ms。
解决方案是把API请求放到边缘节点处理。用了阿里云的边缘函数（ER），在郑州本地的边缘节点上部署了API处理逻辑。用户请求不再回源到高新区服务器，直接在边缘节点完成处理和返回。改造后API延迟从400ms降到了80ms，首屏渲染从1.8秒降到了1.5秒，快了300ms。
300ms看起来不多，但对用户体验影响很大。Google的研究表明，页面加载时间每增加100ms，转化率下降7%。300ms就是21%的转化率差异。这家商场的线上商城，改造后首周下单转化率从3.2%提升到了3.8%，涨了18.7%。说白了，性能优化最终要跟业务指标挂钩才有意义。
边缘计算的实现细节
边缘函数的写法跟普通云函数类似，但有几个限制。第一，执行时间不能超过50ms，复杂的业务逻辑处理不了。我们的方案是：边缘函数只做数据聚合和简单处理，复杂计算还是回源到中心服务器。比如商品列表接口，边缘函数从缓存中取数据直接返回（80ms），缓存未命中时才回源到中心服务器（400ms）。
第二，边缘节点的存储能力有限，不能直接连数据库。我们用了边缘Redis缓存，缓存商品列表、分类树等读多写少的数据。写操作（下单、评价）直接回源到中心服务器处理。
第三，调试不方便。边缘函数部署后不好断点调试，出了问题只能看日志。建议在本地充分测试后再部署。我们踩过一个坑：边缘函数里用了Date.now()获取时间，但边缘节点的时区跟中心服务器不一致，导致缓存过期判断出错。后来统一用UTC时间解决了。
什么场景该用
Serverless适合流量波动大、运维资源有限的小团队。如果你的项目日均访问量不到1万、功能以CRUD为主、团队没有专职运维，Serverless能省不少事。但如果项目有大量长连接（比如即时通讯）、执行时间超过30秒的耗时任务（比如视频转码），Serverless反而不合适。
边缘计算适合对延迟敏感的场景：面向C端的高频接口、地域分布广的用户群体、首屏加载要求高的页面。如果是后台管理系统，用户就那么几个人，延迟差几百毫秒无所谓，上边缘计算就是杀鸡用牛刀。
郑州本地的技术团队对这两个方向的关注度还不高，今年参加了几次郑州的技术meetup，聊Serverless的人不多，聊边缘计算的几乎没有。但其实这两个方向的技术门槛不高，投入产出比很明显，建议同行们关注一下。别被忽悠了，技术选型不是追新，是找到适合自己业务场景的工具。