收益 or 挑战？Serverless 究竟给前端带来了什么

笔者之前在百度广告数据处理团队使用过这种平台计算离线日志，每个 MapReduce 计算节点经过可视化后，就可以轻松看出故障时哪个节点在阻塞，还可以看到最长执行链路，并为每个节点重新分配执行权重。即便逻辑编排不能解决开发的所有痛点，但在某个具体业务场景下一定可以大有作为。

挑战一：Serverless 可以完全取消前端转后端的门槛?

前端同学写 Node 代码最容易犯的毛病就是内存溢出。

浏览器 + Tab 天然是一个用完即关的场景，UI 组件与逻辑创建与销毁也非常频繁，因此前端同学很少，也不太需要关心 GC 问题。而 GC 在后端开发场景中是一个早已养成的习惯，因此 Nodejs 程序缓存溢出是大家最关注的问题。

Serverless 应用是动态加载，长时间不用就会释放的，因此一般来说不需要太担心 GC 的问题，就算内存溢出，在内存被占满前可能已经进程被释放，或者被监测到异常强制 Kill 掉。

但毕竟 FaaS 函数的加载与释放完全是由云端控制的，一个常用的函数长时间不卸载也是有可能的，因此 FaaS 函数还是要注意控制副作用。

所以 Serverless 虽然抹平了运维环境，但服务端基本知识还需要了解，必须意识到代码跑在前端还是后端。

挑战二：性能问题

Serverless 的冷启动会导致性能问题，而让业务方主动关心程序的执行频率或者性能要求，再开启预热服务又重新将研发拖入了运维的深渊中。

即便是业界最成熟的亚马逊 Serverless 云服务，也无法做到业务完全不关心调用频率，就可以轻松应付秒杀场景。

因此目前 Serverless 可能更适合结合合适的场景使用，而不是任何应用都强行套用 Serverless。

虽然可以通过定期运行 FaaS 服务来保证程序一直 Online，但笔者认为这还是违背了 Serverless 的理念。

挑战三：如何保证代码可迁移性

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!