Serverless，将给前端发展带来大变革的技术？（上）-InfoQ

本文将从前端的角度来看Serverless究竟是什么，Serverless的出现会给前端带来什么样的机遇和挑战，并以一个具体的项目为例说明如何基于Serverless实现项目功能。

前端开发的横向演进

在刚开始的互联网时代，网页很简单，就是一些静态或简单动态的页面，主要是用来做信息的展示和传播。开发一个网页主要就是通过 JSP、PHP 等技术写一些动态模板。这个阶段还没有前后端的分工，通常是后端工程师顺便写了前端页面。

在 AJAX 技术出现之后，可以把 Web 分为前端和后端，前端负责界面和交互，后端负责业务逻辑的处理。前后端通过接口进行数据交互。随着页面越来越复杂，移动网络的应用的兴起，对加载性能有了更多的要求，通常异步渲染页面白屏时间比较长，另一方面对 SEO 也不够友好，所以落地页又回归到服务端渲染的这个方案。

前端在发展，后端也在发展，在分层和模块划分上更加的粒度化，微服务化。微服务的接口不再是面向页面，前端的接口调用变得复杂了，所以需要在微服务和前端中间，加了一个 BFF 层，全称（backend for frontend），由这一层对接口进行聚合、裁剪后，再输出给前端。而这层不是后端本质工作，距离前端比较近，关系更大一些，所以前端工程师很自然选择了 Node.js 来实现。这也是当前 Node.js 在服务端比较广泛的应用。

可以看到，每一次前端开发模式的变化，都因为某个变革性技术的出现。先是 AJAX，然后是 Node.js。

那么下一个变革性的技术是什么？

不言而喻，就是 Serverless。

前端工程师也能开发后端吗？

但是，如果完全让前端工程师来开发一个后端，需要考虑很多内容。

首先要考虑代码运行的环境和相关资源。
比如前端代码运行的环境是用户的浏览器。
后端环境需要服务器，网络，访问服务的域名、证书，服务器的操作系统，软件安装，WebServer，数据库等。
除此之外，前端要考虑的是用户的网络，浏览器的兼容性，交互的流畅程度，还有视觉效果。
后端还要考虑负载均衡，流量控制，弹性伸缩，高并发，备份容灾，安全防护，监控警告等。

前端并不擅长这些，但有了 Serverless 之后，这些我们基本上不用考虑，我们的主要精力可以用来实现业务逻辑。

那么，Serverless 为什么能帮助做这些事情？

如下图所示，FaaS+BaaS 可以称之为一个完整的 Serverless，FaaS（Function as a Service）是函数运行的平台。BaaS（Backend as a Service）则是一些后端云服务，比如云数据库、对象存储、消息队列等，通过使用 BaaS，可以极大简化应用开发难度。开发者将代码上传到云函数平台，并配置相关的触发器。平台根据触发器事件，完成运行环境的准备、调度、执行和扩容这些工作。

从架构上，可以看到 Serverless 的这些特点：

无运维，使用 Serverless 我们不需要关心服务器，不需要关心运维，这也是 Serverless 思想的核心。
无状态，因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。
如果要共享数据，则只能通过Redis 、COS等第三方服务。
事件驱动，函数在 FaaS 平台中，是需要通过事件来触发函数执行。
低成本，实现按需调用，按需伸缩、按使用收费。

基于 Serverless 的前端开发模式

01 BFF

基于 Serverless，前端的一些通用开发模式可以怎么来做呢？下图是比较通用的 BFF 架构。最底层是后端微服务，最上层是前端应用，在微服务和应用之间，是通常由前端工程师开发的 BFF 层，对接口进行聚合裁剪，在返回给前端使用。

这样的架构解决了接口协调的问题，但也带来了一些新的问题。以前前端只需要关注浏览器端的渲染，现在却需要维护各种 BFF 应用以及运维，但是通常前端并不擅长运维。Serverless 的出现可以很好的解决这些问题。基于 Serverless，可以使用云函数来实现 BFF 层，只需要关注业务逻辑，运维的工作交给了 Serverless 平台。

上图中的 APIGateway 代替了我们的 Nginx 代理服务器，以前可能是将转发规则写在代理服务器的配置文件中，现在在 API 网关中有了可视化的管理、可监控、可设置版本等等更多更易用的功能。

02 SSR

传统的服务端渲染，服务端根据路由返回渲染好的 HTML 页面。而在 Serverless 上实现也类似，可以将多个页面返回放到一个函数中，也可以将每个页面拆分成一个个云函数，这样用户请求的一个页面，对应的就是每个单独的函数。

03 小程序

目前国内使用 Serverless 较多的场景可能就是小程序开发了。在传统的小程序开发中，需要前端工程师进行小程序端的开发；后端工程师进行服务端的开发。小程序的后端开发和其他的后端应用开发，本质是是一样的，需要关心应用的负载均衡、弹性伸缩，备份冗灾、监控报警等等运维操作。

但基于云开发，开发者只需要关注于业务的实现，由一个前端工程师就能够完成整个应用的前后端开发。应用的运维转移到了云平台上。

04 后端思维

前端工程师去基于 Serverless 去写后端，最好也要具备一定的后端知识。涉及复杂的后端或者 Serverless 不适用的场景，还是需要后端去开发，只不过后端变得更加靠后。简单说说前后端开发异同之处。

（1）共性思维，就是前端后端都通用的。

第一个工程化，分层模式，前端的工程化现在也相当的成熟，视图和数据分离，组件和页面的组装，而后端最基本的一个分层模式就是DAO层，业务模块层，接口层。
可用性：
监控一切。
这个大家都比较好理解，服务端监控包括：
接口，各种服务，机器的性能等等
高性能：
和前端有各种缓存技术方案一样，在后端如果要提升性能，一样需要利用缓存，理论上每个层级都可以缓存，从数据库到Redis，内存，从元数据到渲染好的页面，但缓存越多，系统复杂度也越高，需要根据需求成本来平衡方案取舍。

（2）安全意识。

防别人对付用户：
设置 CSRF Token
防用户对付系统：
参数校验、权限检查、防SQL注入
防系统对付自己：
提交防重/频率控制

（3）并发意识。服务端和前端主要不同的点是，服务端同时服务所有用户，需要有并发的意识。

资源多级隔离：
防止一个有问题导致系统雪崩。
共享数据加锁：
比如有限数量的商品多人同时下单的场景。
任务队列缓存：
将高并发放到任务队列中，减缓并发高峰，让高并发变得更为可控一些。

如何基于 Serverless 进行项目开发

程序受众广易传播，开发成本低，效果好等特点，非常适合老产品拉新/创新，新产品快速尝试。这里以一个背单词小程序为例。

01 项目需求

这个项目的核心需求是学习单词，记录学习情况，学习单词又包含看单词，听单词发音，读单词，系统对用户发音进行评分，还有检验。

基于 Serverless 的技术方案如下，可以看到有登陆模块，通过云函数，调用微信的 API 进行登录校验。语音合成和口语评测这两个功能，腾讯云就有这两个服务，可以直接调用，需要做的仅仅是通过云函数进行鉴权中转。学习记录这部分，就结合函数逻辑和云数据库来完成。可以看到项目的完整层级架构，是非常清晰简单的。