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

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

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

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

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

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

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

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

挑战二：性能问题

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

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

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

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

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

有一张很经典的 Serverless 定位描述图：

网络、存储、服务、虚拟家、操作系统、中间件、运行时、数据都不需要关心了，甚至连应用层都只需要关心其中函数部分，而不需要关心其他比如启动、销毁部分。

前面总拿这点当优势，但也可以反过来认为是个劣势。 当你的代码完全依赖某个公有云环境后，你就失去了整体环境的掌控力，甚至代码都只能在特定的云平台才能运行。

不同云平台提供的 BaaS 服务规范可能不同，FaaS 的入口、执行方式也可能不同，想要采用多云部署就必须克服这个问题。

现在许多 Serverless 平台都在考虑做标准化，但同时也有一些自下而上的工具库抹平一些差异，比如 Serverless Framework 等。

而我们写 FaaS 函数时，也尽量将与平台绑定的入口函数写得轻一些，将真正的入口放在通用的比如 main 函数中。

总结

Serverless 的价值远大于挑战，其理念可以切实解决许多研发效能问题。

但目前 Serverless 发展阶段仍处于早期，国内的 Serverless 也处于尝试阶段，而且执行环境存在诸多限制，也就是并没有完全实现 Serverless 的美好理念，因此如果什么都往上套一定会踩坑。

可能在 3-5 年后，这些坑会被填平，那么你是选择加入填坑大军，还是选一个合适的场景使用 Serverless 呢?

（编辑：ASP站长网）