Serverless——前端的3.0时代

《信息简史》中说“进化本身是生物体与环境之间持续不断的信息交换的具体表现”，前端技术的进化也是如此。浩瀚的前端宇宙中，又出现过哪些耀眼的星辰呢？指引前端未来的“北极星“又在何方？腾讯云高级工程师与你畅谈前端的变革史与新时代的希冀。

在正文之前我想简单介绍一下自己的从业背景。
初次接触前端是读书期间的第一份实习工作，在 SAP 上海研究院 TIP BI 部门开发基于 SVG 的Charts 库，99%的代码逻辑是将数据用 SVG 转化为可视化的 UI。值得一提的是当时用的构建工具是 YUI Compressor 搭配 Ant 调度。

毕业后成为了一名传统的 web 前端开发者，期间还折腾过富本文编辑器。后来有近一年的时间研究效率工程，也就是大众口中的前端工程化。然后在加入腾讯之前的工作是地图，技术核心是 WebGL。

可以说除了音视频以外，5 年多的经历基本涵盖了前端领域绝大部分的技术方向。不论是大众的 web 还是小众的 SVG，不论是宏观到 web 整体的工程化还是微观到像素的图形学。表面看上去似乎每一份新工作跟之前的工作都关联甚微，比如在使用 WebGL 期间积累的矩阵、向量、三角剖分等数学和图形学知识基本上在现阶段工作中得不到体现。但其实从毕业到加入腾讯之前始终处于一种迷惘的状态中，一直试图在不同的工作类型中寻找真正能够体现前端工程师核心价值的方向，以及辅助这个方向的关键技术。

我想现在我找到了，以全栈为进化方向的前端，以及辅助其落地的 Serverless。

如果要探讨一项技术或者一种理念是否具有革命性，必然需要一些参照物，历史是最佳的参考。所以在讨论 Serverless 对前端的革新之前，有必要先“飞快“地回忆一下前端的变革史。

前端变革史

前端0.0：WWW

如果以世界上第一个 web 浏览器 WorldWideWeb 的诞生作为起点，那么 90 年代初便是前端的 0.0 时代。彼时没有前端工程师的称谓，前端的工作也很简单，主要是静态 UI 和表单验证，要么后端工程师兼顾为之，要么由独立的 UI Developer 全权负责。

其实时至今日很多外企仍然沿袭着 UI Developer 岗位，与目前大众认知的前端工程师不同的是，UI Developer 的能力栈除了 HTML/JS/CSS 以外，还要具备一定的 UI 和交互设计能力。

前端 1.0：AJAX

起源于 Microsoft Outlook 的 AJAX 是引起前端第一次革命的关键技术，这是一个重要的转折点，以此为契机网站具备了动态性，前端工程师的能力模型逐渐从 UI 偏向逻辑和数据。

前端 2.0：Node.js

然后是广为人知的 Node.js 成就了前端 2.0。Node.js 破除了前后端编程语言的壁垒，令前端开发者能够以相对较小的成本跨界服务端，但是编程语言仅仅是服务端开发最表层也是最易突破的，背后更困难的部分是单纯靠 Node.js 无法解决的，细节稍后再表。除了服务端以外，Node.js 对前端最大的贡献是提供了工程化的土壤。

在此各位不妨思考一个问题：一个构建工具最基本最底层的能力是什么？答案是文件 IO。

在 Node.js 之前，HTML/JS/CSS 的构建只有两个途径。第一是借助其他编程语言的工具，比如 YUI Compressor；第二是用 IE 浏览器。这不是笑话，IE 浏览器能够在早期占据霸主地位可不完全是因为 windows 系统的背书，它自身的功能性也非常强大。众所周知早期的 IE 浏览器是 windows 系统的一个组件，以它为入口可以调用一些系统级的底层功能，文件 IO 便在此列，实现的方式是借助 ActiveX 控件的 FileSystemObject 对象。细节就不讲了，感兴趣的同学可以自行参阅相关资料。

前端 2.5：React

有一些声音认为 React 能够配得上"革命性"一词，因为它一定程度上改变了前端的编程模型，React 之前的前端是围绕 DOM，React 之后是面向数据。诚然如此，但跟 AJAX 和Node.js 相比，React 引起的变革仍显轻微。而 React 对前端组件化生态的影响也是在原有基础上的增强也并不能称为革命性。所以称 React 为前端 3.0 缺乏足够的说服力，不过前端 2.5 还是充分的。说到底，React 只是改变了前端领域自身，而 AJAX 和 Node.js 无一不是对前后端都有显著影响的技术。

Serverless-从前端到全栈

在讨论哪项技术或理念会成就前端 3.0 之前，必须要确认前端下一步的发展方向。

目前有两种声音：一是前后端包揽的“大前端”，也就是全栈，关键性技术是 Node.js；二是以 React-Native 和 Flutter 为突破点的“泛前端”，即全端。

以目前的时间节点来看，React-Native 也好，Flutter 也罢，都还未能够称得上成熟，泛前端之路任重道远。相对来说，前端下一步发展为全栈的可能性更高一些。基于这个前提，Serverless 便是成就此道的革命性技术理念。

“全栈”这个词其实一直存在歧义，狭义上的全栈来源于前端技术圈，指的是一个人包揽前端和 web 服务端；而广义上的全栈应该是在前后端以外还包括数据库并且能够精通围绕三者展开的架构和技术细节，这是几乎不可能的任务，如果真的有人能够达到这种境界，估计就是接近艾伦·图灵一般的计算机之神了吧。在狭义与广义之间，Serverless 面向的是广义的全栈。Serverless 的理念是将服务器管理、数据库优化等“粗活”交给云平台，从而前端开发者能够将交互逻辑、业务逻辑、数据全部掌控在自己手中，这才是真正意义上的全栈。

为了能够更清晰地理解 Serverless，有一种架构模式可以作为对比，即 BFF（Backends for Frontend，为前端服务的后端）。

BFF-从平台无关性到平台差异化

BFF 简单来说就是在原有的一体化服务端基础上，针对不同的业务平台分别开发一层独有的、很薄的服务，见下图。
在这里插入图片描述
BFF承担了一部分的业务逻辑，这部分逻辑通常是平台独有的。举一个现实中的例子：在线视频提供商有多种平台，比如网站、app。由于版权限制有些影片只能在特定的平台播放。具化到技术层面，实现此类逻辑包含分平台鉴权、数据查询策略等等，这些便是典型的平台差异化业务逻辑。独立于核心业务逻辑之外的BFF层能够实现差异化逻辑的松耦合，进而令迭代和维护更高效和安全。

BFF未解决的问题

目前业内对BFF普遍实践模式是将BFF分发到负责各平台技术开发的团队，比如App团队负责Mobile BFF、前端团队负责PC web和H5 BFF等等。那么对于前端工程师来说，这种模式是否意味着前端兼顾BFF层？理想的场景是这样的，但现实工作中并非如此。
在这里插入图片描述
BFF 本质上仍然是服务层，除了编程语言之外，一名合格的服务端开发者还需要具备一些独有的领域知识以及服务管理、数据管理理念。所以目前大多数BFF仍然由传统前端之外的专人负责，即便是 Node.js BFF。

也就是说，BFF 并未解决前端成为全栈的关键性问题，而这些问题便是 Serverless 的针对点。

腾讯云云开发对Serverless的落地实践

目前业内对于 Serverless 的普遍认知是 FaaS（Function as a service，函数即服务）和BaaS（Backend as a service，后端及服务）的综合体。以此为前提，腾讯云的相关团队将 Serverless 的具体实现为下图所示的模型。
在这里插入图片描述
以此为支撑，落地到具体应用场景中的云开发模式如下图：

各平台应用的前端集成对应的 SDK，涵盖云函数、云数据库和云存储的功能调用 API。前端的请求直接送达云平台的接入层，目前是以 Node.js 作为接入层技术栈；然后经过必要的处理（比如用户鉴权）转至云函数、云数据库以及云存储平台。

以云开发体系提供的功能和服务为基础支撑，前端开发者的关注点除了 UI 和交互逻辑以外，能够以很小的成本介入以云函数为承载的业务逻辑层和以云数据库、云存储为支撑的数据存储层。简而言之，前端的关注点为：交互逻辑+业务逻辑（云函数）+数据（云数据库/云存储）。
在这里插入图片描述
从上文的描述中可能有部分同学意识到一个问题：云存储跟CDN有什么区别？

云存储提供文件托管服务，本质上与 CDN 相同。其优势体现在开发者无需申请域名、无需管理服务器，文件被自动托管，并且可以通过鉴权机制保证文件的私密性和安全性。其实针对 CDN的话题可以延伸到 Serverless，大多数前端开发者在工作中都无需关系CDN服务器的状态，只需要部署文件即可（甚至这一步也可以由CI系统完成），那么CDN对于前端开发者来说就可以被认为是 Serverless 的。

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

开发生态

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

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

场景多样化支撑

任何一种新技术或者架构落地到具体的业务场景中都难免会遇到由于业务特殊性造成的迁移困难问题，所以在基础的开发生态之外，云开发为支撑多样化的业务场景建立了必要的策略以及对应的工具。
在这里插入图片描述
比如对于数据私密性存在高要求的产品，可以通过控制台选择严格的 CURD 权限管理策略；并且可以使用 wx-service-sdk 在云函数中进行私密数据的 CURD 以保障安全性；再比如对实时性要求较高的场景，比如在线客服、多人游戏等，云数据库的实时推送功能可以保障此类功能的高效表现。