前端工程化：Docker、k8s、Serverless

Docker、k8s、Serverless，工程师们没少听，只不过不同工程师们的对他们的关注程度各不相同，出发点都是希望技术方案能在项目中更好的解决一些实际问题。这些技术即能抹平一些工程师之间的边界，也能加深一些工程师之间的鸿沟。

有过一些面试其他前端同学的经历，可能他们很熟悉 JS 基础、React、Vue等框架，但是谈到他们开发的前端应用的背后的东西，对他们就感觉是一个黑盒。很多公司大多是通过运维人员或 Leader 来去操作，很多人并不知道他们自己开发的前端应用背后是什么 Web 服务器、CDN，是使用了 nginx、Apache，或使用了容器、k8s等。

这些技术的出现，我们可能完全不需要去关注背后是怎么部署和运维的，交给专业人员和云服务商去做，就像我们使用水电一样，我们完全不需要知道背后是怎么发电的。可以更加专注于自己的业务逻辑，这也是一种发展。

我们正处在这个过渡的时代。

从资源利用率角度来看 Docker 、k8s 、Serverless

一般的物理服务器都会有很强的 CPU 核心、内存、网卡等。为了充分利用这些硬件资源，就有了虚拟化技术，物理服务器上可以虚拟出很多的虚拟机（VM），每个虚拟机都拥有独立的操作系统（windows、linux等）。根据需求来分配具体的硬件资源（CPU、内存等），就可以尽量大的利用物理服务器资源。

Docker

Docker 的出现，原因肯定有对虚拟机的资源利用率还是不满意，继续提高服务器的资源利用率。Docker 就是对机器的利用率到了进程级别，更细的控制 CPU、内存等。

Docker 可以在一台机器上快速的启动、关闭容器，但是缺乏对大量容器自动编排、管理和调度。k8s 就是一套管理系统，对容器进行更高级更灵活的管理。你只需要提供服务器，k8s 通过对容器的编排可以帮你最大化的利用这些服务器的资源。

Serverless

云服务可以让我们选择合适配置的虚拟的云主机，然后按时、按月、按年的收费，但不管你使用与否，费用都在那里，不增不减。Serverless 则可以让你只在使用时，根据使用时间、内存占用等一些你具体使用的东西来收费，不管你使用的频率高低都可以承受，就像水和电，用了多少就是多少费用。

前端工程中的使用

不同与服务端很多程序，前端代码运行在客户机器上。Docker 在前端工程上的使用，出发点和服务端程序，会有所不同。

Docker 的使用场景

构建部署发布

通常的前端应用构建部署流程：

1. 安装依赖
2. 执行构建命令，生成静态资源
3. 上传静态资源到对应服务器

加入 Docker 理念后，前二个步骤几乎相同，理想的流程大致为：

1. 安装依赖
2. 执行构建命令，生成静态资源
3. 构建容器镜像
4. 上传容器镜像
5. 拉取镜像，启动容器

步骤 3 中，构建出的镜像里面包括：

1. Web 服务器（一般都是从一个 nginx 基础镜像开始）
2. Web 服务器的相关配置
3. 构建完的静态资源

一部分静态资源在构建完成之后也可以上传到 CDN 上，但是因为静态资源的大小几乎不会很大，所以放到镜像中没有多大问题。

步骤 5 中，对容器的编排，最流行的应该就是 k8s ，上传完镜像后，就交由 k8s 来做一系列的发布编排等。

构建完的静态资源，不像后端的程序，其实它对环境的感知是很低的，因为只是简单的存储在机器上，没有运行。所以就算是很多前端应用，Web 服务器就是它的 Docker，通过管理好不同的目录，每个应用就可以很好的做到相应的隔离来等待客户端去请求它。

前端开发环境的统一

现代前端应用的项目开发，已经不是只用浏览器就能跑起来了。项目中的依赖少不了 node、npm，如果复杂项目就会带入更多的东西。多个项目中开发依赖大多都会不同，node 版本，npm 包的版本，或其他依赖的版本都可能是不同的。

这时候，引入 Docker ，给每个项目都生成一个容器镜像包括该项目的所有的依赖，并配置好基于容器来开发的命令，规范和统一了开发的环境。开发人员只需要安装好 Docker ，下载好代码，下载这个镜像，可以省去很多的开发环境搭建的麻烦，而且受益者众多。

但是随着 Web IDE 的发展，之后，应该是 Web IDE 在云端就会帮你解决项目中所有的环境依赖，你只需要打开浏览器，专注于代码的业务逻辑即可。

Serverless 理念

首先它是一个理念，不同云计算厂商针对这个理念出了不同的产品。

前端和服务器的前端（对整个请求链路来说，前端是相对的，只要离客户请求更近的角色都可以称自己为前端）

前端在使用 CDN、调用 API，相对于前端来说这些就是 Serverless 的理念，我们不会去关心这些 API 部署了多少机器、架构是怎么样的，这些方面后端和运维工程师都帮我们处理好了。同样，Serverless 可以帮后端工程师们处理掉很多与业务逻辑不相关的工作，更专注于业务逻辑的代码编写。

在前端技术领域 BFF 层和 SSR 渲染，非常适合 Serverless 技术的落地。

BFF 层，负责适配前端（PC端、移动端等）和后端服务的一个适配层。一般在 BFF 层前面，还会有 API Gateway 层负责统一的入口、鉴权、服务分发等功能。因为 BFF 层通常不会涉及到持久化的逻辑，使用 Serverless 非常合适，不用在关心负载均衡、扩缩容、高并低延等一系列问题，更专注于本身的业务逻辑处理。BFF 层因为更靠近客户请求，除去这些问题，前端工程师便可以更好的胜任这一层的开发。

SSR 渲染可以在服务端更快的渲染出页面，提供给客户端展示。不止是页面，所有的组件也可以在服务端渲染，直接提供给客户端展示。和 BFF 层类似，Serverless 可以让 SSR 服务专注于渲染组件和页面的处理，而不用关心这个服务背后的一些运维、服务健壮性等服务端的知识，Serverless 可能让 SSR 重回主流位置。

想象一下 5G 的出现，低延时、高速度，利用 Serverless 和其他云服务的结合，客户端的计算处理能力可以极低，硬件的大头只有显示设备或者投屏显示，可能激发出更多的创新，科幻电影里的一些场景也是不远了。

云服务的出现，就是让我们可以更专注于业务逻辑；中台的出现，是在我们的业务逻辑中抽象出通用的部分，变成业务的“基础设施”，目标都是为了快速的可以把我们的业务想法变为实际的应用落地。所以，在公司中，特别是在发展的不同阶段，对“基础设施”的提供和业务研发的资源分配，是一个很大的挑战。

扫码关注公众号