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

为了减少写后端业务逻辑时，环境、部署问题的干扰，许多团队会将业务逻辑抽象成一个个区块(Block)，对应到代码片段或 Blockly，这些区块可以独立维护、发布，最后将这些代码片段注入到主程序中，或动态加载。如果习惯了这种开发方式，那也更容易接受 Serverless。

更厚的后台服务

站在后台角度，事情就变得比较复杂了。相对于提供简单的服务器和容器，现在要对用户屏蔽执行环境，将服务做得更厚。

笔者通过一些文章了解到，Serverless 的推行还面临着如下一些挑战：

Serverless 各厂商实现种类很多，想让业务做到多云部署，需要抹平差异;

成熟的 PaaS 服务其实是伪 Serverless，后续该如何标准化;

FaaS 冷启动需要重新加载代码、动态分配资源，导致冷启动速度很慢，除了预热，还需要经济的优化方式;

对于高并发(比如双 11 秒杀)场景的应用，无需容量评估是很危险的事情，但如果真能做到完全弹性化，就省去了烦恼的容量评估;

存量应用如何迁移。业界的 Serverless 服务厂商大部分都没有解决存量应用迁移的问题;

Serverless 的特性导致了无状态，而复杂的互联网应用都是有状态的，因此挑战在不改变开发习惯的情况下支持状态。

所幸的是，这些问题都已经在积极处理中，而且不少有了已经落地的解决方案。

Serverless 给后台带来的好处远比面临的挑战多：

推进前后端一体化。进一步降低 Node 写服务端代码的门槛，免除应用运营的学习成本。笔者曾经遇到过自己申请的数据库服务被迁移到其他机房而导致的应用服务中断，以后再也不需要担心了，因为数据库作为 BaaS 服务，是不需要关心在哪部署，是否跨机房，以及如何做迁移的;

提高资源利用效率。杜绝应用独占资源，换成按需加载必然能减少不必要的资源消耗，而且将服务均摊到集群的每一台机器，拉平集群的 CPU 水位;

降低云平台使用门槛。无需运维，灵活拓展，按价值服务，高可用，这些能力在吸引更多客户的同时，完全按需计费的特性也减少了用户开销，达到双赢。

利用 Serverless 尝试服务开放

笔者在公司负责一个大型 BI 分析平台建设，BI 分析平台的底层能力之一就是可视化搭建。

那么可视化搭建能力该如何开放呢?现在比较容易做到的是组件开放，毕竟前端可以与后端设计相对解耦，利用 AMD 加载体系也比较成熟。

现在遇到的一个挑战就是后端能力开放，因为当对取数能力有定制要求时，可能需要定制后端数据处理的逻辑。目前能做到的是利用 maven3、jdk7 搭建本地开发环境测试，如果想上线，还需要后端同学的协助。

（编辑：ASP站长网）