前言

大多数公司在开发应用程序并将其部署在服务器上的时候，无论是选择公有云还是私有的数据中心，都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。如果我们不想在这些细节上花费精力，是否有一种简单的架构模型能够满足我们这种想法？这个答案已经存在它就是 — Serverless（无服务器）架构。

看似与前端关系不大的 Serverless，其实早已和前端有了颇深渊源，并且将掀起新的前端技术变革。此次分享根据个人理解和总结，从前端开发模式在serverless的演进、Serverless 常见服务商提供的解决方案以及 基于Serverless 的前端开发模式等方面，与大家探讨 Serverless 中的前端开发模式。

前端发展史

前端开发模式的演进

1、基于模板渲染的动态页面

在早起的互联网时代，我们的网页很简单，就是一些静态或动态的页面，主要目的是用来做信息的展示和传播。这个时候开发一个网页也很easy，主要就是通过 JSP、PHP 等技术写一些动态模板，然后通过 Web Server（nginx，apache） 将模板解析成一个个 HTML 文件，浏览器只负责渲染这些 HTML 文件。这个阶段还没有前后端的分工，通常是后端工程师顺便写了前端页面。

JSP: Java Server Page: Java服务端页面，在html页面中编写Java代码的页面
WebServer：网站服务器或web服务器

2、基于 AJAX 的前后端分离

2005 年 AJAX 技术的正式提出，翻开了 Web 开发的新篇章。基于 AJAX，我们可以把 Web 分为前端和后端，前端负责界面和交互，后端负责业务逻辑的处理。前后端通过接口进行数据交互。我们也不再需要在各个后端语言里面写着难以维护的 HTML。网页的复杂度也由后端的 Web Server 转向了浏览器端的 JavaScript。也正因如此，开始有了前端这个职位。

3、基于 Node.js 的前端工程化

2009年 Node.js 的出现，对于前端来说，也是一个历史性的时刻。随着 Node.js 一同出现的还有 CommonJS 规范和 npm 包管理机制。随后也出现了 Grunt、Gulp、Webpack 等一系列基于 Node.js 的前端开发构建工具。

在 2013 年前后，前端三大框架 React.js/Angular/Vue.js 相继发布第一个版本。我们可以从以往基于一个个页面的开发，变为基于一个个组件进行开发。开发完成后使用 webpack 等工具进行打包构建，并通过基于 Node.js 实现的命令行工具将构建结果发布上线。前端开发开始变得规范化、标准化、工程化。

4、基于 Node.js 的全栈开发

Node.js 对前端的重要意义还有，以往只能运行在浏览器中的 js 也可以运行在服务器上，前端可以用自己最熟悉的语言来写服务端的代码。于是前端开始使用 Node.js 做全栈开发，开始由前端向全栈的方向转变。这是前端主动突破自己的边界。
另一方面，前端在发展，后端也在发展。也差不多在 Node.js 诞生那个时代，后端普遍开始由巨石应用模式向微服务架构转变。这也就导致以往的前后端分工出现了分歧。随着微服务架构的兴起，后端的接口渐渐变得原子性，微服务的接口也不再直接面向页面，前端的调用变得复杂了。于是 BFF（Backend For Frontend）架构出现了，在微服务和前端中间，加了一个 BFF 层，由 BFF 对接口进行聚合、裁剪后，再输出给前端。而 BFF 这层不是后端本质工作，且和前端的关系最大，所以前端自然而然选择了 Node.js 来实现。这也是当前 Node.js 在服务端较为广泛的应用的原因。

巨石应用：大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。

微服务架构：微服务架构是一种架构理念，是指将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。把一个大型的单体应用程序和服务拆分为数个或数十个的微小型服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

下一代前端开发模式

说完了这几个阶段，可以看到，每一次前端开发模式的变化，都因某个变革性的技术而起。先是 AJAX，而后是 Node.js。那么下一个变革性的技术是什么？不言而喻，个人觉得就是 Serverless。

Serverless无服务器架构

Serverless： 无服务器架构，即在无需管理服务器等底层资源的情况下完成应用的开发和运行，是云原生架构的核心组成部分。

通俗来说，如果将购买一台物理服务器比作买车，购买云服务器就类似于租车（租赁期间需要驾驶和维护，且即使闲置也需付费），那么Serverless则类似于出租车（只需乘坐，按里程计费）。

从技术层面来说，我们可以简单理解为：Serverless = FaaS + BaaS。一个完整的Serverless应用一般由FaaS层的云函数负责无状态的计算，由BaaS层组件负责状态的维护：

FaaS（函数即服务，Function as a Service）：将函数代码托管给云产商，以服务形式运行，支持事件触发。代表产品有腾讯云SCF、AWS Lambda等。

BaaS（后端即服务，Backend as a Service）：指云平台提供的后端组件整合，开发者无需开发和维护后端服务，通过API/SDK的调用便可获得例如数据存储（对象存储、云数据库、云中间件等）、消息推送、账号管理、地图定位、AI、IoT等能力。

Serverless 的主要特点有：

1、事件驱动—-函数在 FaaS 平台中，需要通过一系列的事件来驱动函数执行。
2、无状态—-因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。
3、无运维—-使用serverless我们不需要关心服务器，也不需要关心运维，这也是serverles思想的核心；
4、低成本—-使用 Serverless 成本很低，因为我们只需要为每次函数的运行付费。函数不运行，则不花钱，也不会浪费服务器资源过度。

基于 Serverless 的前端开发模式

1、在开始具体的案例之前，先看一下传统开发流程。
在传统开发流程中，我们需要前端写页面，后端工程师写接口。后端写完接口之后，把接口部署了，再进行前后端联调。联调完毕后再测试、上线。上线之后，还需要运维工程师对系统进行维护。整个过程涉及多个不同角色，链路较长，沟通协调也是一个问题。

2、而基于 Serverless，后端变得非常简单了，以往的后端应用被拆分为一个个函数，只需要写完函数并部署到 Serverless 服务即可，后续也不用关心任何服务器的运维操作。后端开发的门槛大幅度降低了。因此，只需要一个前端就可以完成所有的开发工作。当然，前端基于 Serverless 去写后端，最好也需要具备一定的后端知识。涉及复杂的后端系统或者 Serverless 不适用的场景，还是需要后端开发。

完整的Serverless体系不仅仅包括CDN，还可以把数据库和服务端也实现Serverless。在这套体系支撑下的工程模型中，一个完整的迭代周期仅仅需要两种职能角色：前端和测试。前端负责所有与业务相关的工作，包括交互层、业务层和数据层；测试负责质量保证；而部署、发布、服务器管理、线上监控等等繁琐的工作则交由云开发平台去完成。

开发生态：

在以上云开发模式基础上，具体到现实上手开发，开发者们需要了解三种角色：端、云和控制台。

• 端的表现形式是对应各平台的SDK，是与前端开发者关系最紧密的一个角色；
• 云指的是支撑Serverless体系的后台系统，这部分对于开发者来说是无感知的，与其对接的工作由端SDK承担。细化到子角色可以分为接入层和基础服务，接入层负责代理转发和用户鉴权等工作；基础服务提供基本的能力支撑，包括云函数、云数据库和云存储；
• 控制台的功能分为两大类：一是管理功能，比如云函数的部署、数据和文件的管理等等；二是运营，控制台提供产品线上监控以及数据的统计和可视化，以辅助运营。

应用场景

基于 Serverless 的 BFF (Backend For Frontend)

传统 BFF (Backend For Frontend) 架构

1、一方面，对不同的设备需要使用不同的 API，另一方面，由于微服务导致前端接口调用的复杂，所以前端开始使用 BFF 的方式，对接口进行聚合裁剪，以得到适用于前端的接口。
2、最底层的就是各种后端微服务，最上层就是各种前端应用。在微服务和应用之前，就是通常由前端开发的 BFF。
-手机端-web端-嵌入式-
这样的架构解决了接口协调的问题，但也带来了一些新的问题。

传统 BFF (Backend For Frontend) 的痛点

比如针对每个设备开发一个 BFF 应用，也会面临一些重复开发的问题。而且以往前端只需要开发页面，关注于浏览器端的渲染即可，现在却需要维护各种 BFF 应用。以往前端也不需要关心并发，现在并发压力却集中到了 BFF 上。总的来说运维成本非常高，通常前端并不擅长运维。

Serverless 则可以帮我们很好的解决这些问题。用Serverless，我们可以用一个个函数来实各个接口的聚合裁剪。前端向 BFF 发起的请求，就相当于是 FaaS 的一个 HTTP 触发器，触发一个函数的执行，这个函数中来实现针对该请求的业务逻辑，比如调用多个微服务获取数据，然后再将处理结果返回给前端。这样运维的压力，就由以往的 BFF Server 转向了 FaaS 服务，前端再也不用关心服务器了。

基于 Serverless 的 BFF 架构

上图则是基于 Serverless 的 BFF 架构。为了更好的管理各种 API，我们还可以添加网关层，通过网关来管理所有 API（比如阿里云的网关），比如对 API 进行分组、分环境。基于 API 网关，前端就不直接通过 HTTP 触发器来执行函数，而是将请求发送至网关，再由网关去触发具体的函数来执行。
API Gateway
在没有API网关作为统一出口的情况下，需要调用方自己组合各种服务，而且容易让调用方感知后端各种服务的存在，各个需要各个做很多相同的工作。
加入API Gateway之后的作用
一般也会把路由，安全，限流，缓存，日志，监控，重试，熔断等都放到 API 网关来做，然后服务层就完全脱离这些东西，纯粹的做业务，也能够很好的保证业务代码的干净，不用关心安全，压力等方面的问题。

基于 Serverless 的服务端渲染

传统服务端渲染

基于当下最流行的三大前端框架（React.js/Anguler/Vue.js），现在的渲染方式大部分都是客户端渲染。页面初始化的时候，只加载一个简单 HTML 以及对应的 JS 文件，再由 JS 来渲染出一个个页面。这种方式最主要的问题就是白屏时间和 SEO 搜索引擎优化

为了解决这个问题，前端又开始尝试服务端渲染。本质思想其实和最早的模板渲染是一样的。都是前端发起一个请求，后端 Server 解析出一个 HTML 文档，然后再返回给浏览器。只不过以往是 JSP、PHP 等服务端语言的模板，现在是基于 React、Vue 等实现的同构应用，这也是如今的服务端渲染方案的优势。

但服务端渲染又为前端带来了一些额外的问题：运维成本，前端需要维护用于渲染的服务器。

基于serverless的服务端渲染

Serverless 最大的优点就是可以帮我们减少运维，那 Serverless 能不能用于服务端渲染呢？当然也是可以的。

传统的服务端渲染，每个请求的 path 都对应着服务端的每个路由，由该路由实现对应 path 的 HTML 文档渲染。用于渲染的服务端程序，就是这些集成了这些路由的应用。
使用 Serverless 来做服务端渲染，就是将以往的每个路由，都拆分为一个个函数，再在 FaaS 上部署对应的函数。这样用户请求的 path，对应的就是每个单独的函数。通过这种方式，就将运维操作转移到了 FaaS 平台，前端做服务端渲染，就不用再关心服务端程序的运维部署了。

基于 Serverless 的小程序开发

1、目前国内使用 Serverless 较多的场景可能就是小程开发了。具体的实现就是小程序云开发，支付宝小程序和微信小程序都提供了云开发功能。
2、在传统的小程序开发中，我们需要前端进行小程序端的开发；后端进行服务端的开发。小程序的后端开发和其他的后端应用开发，本质是是一样的，需要关心应用的负载均衡、备份冗灾、监控报警等一些列部署运维操作。如果开发团队人很少，可能还需要前端去实现服务端。
但基于云开发，就只需要让开发者关注于业务的实现，由一个前端就能够完成整个应用的前后端开发。因为云开发将后端封装为了 BaaS 服务，并提供了对应的 SDK 给开发者，开发者可以像调用函数一样使用各种后端服务。应用的运维也转移到了提供云开发的服务商。
下面分别是使用支付宝云开发的一些例子，函数就是定义在 FaaS 服务中的函数。

负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务
备份冗灾：就是为了防止出现自然或者社会灭害带来的对存储设备的损害而造成对数据丢失,而采取的备份.

通用 Serverless 架构

基于上述几个 Serverless 开发的例子，就可以总结出一个通用的 Serverless 架构。

其中最底层就是实现复杂业务的后端微服务（Backend）。然后 FaaS 层通过一系列函数实现业务逻辑，并为前端直接提供服务。对于前端开发者来说，前端可以通过编写函数的方式来实现服务端的逻辑。

同时不管是在后端、FaaS 还是前端，我们都可以去调用云计算平台提供的 BaaS 服务，大大降低开发难度、减少开发成本。小程序云开发，就是直接在前端调用 BaaS 服务的例子。

总结

Serverless以云计算相关技术为支撑，搭配容器技术和微服务架构，将基础实施的管理从开发者日常工作中解耦。虽然目前无论是理论解读还是实践模式都尚未形成绝对统一，但可以预见前端开发者将成为Serverless的最大受益群体之一，我们有充足的理由相信它将引发前端的第三次变革。

使用 Serverless，我们不需要再过多关注服务端的运维，不需要关心我们不熟悉的领域，我们只需要专注于业务的开发、专注于产品的实现。我们需要关心的事情变少了，但我们能做的事情更多了。

参考文章：
Serverless——前端的3.0时代
理解serverless无服务架构原理
serverless
无服务器Serverless详解