作者说

​

在开始本篇内容前我想与各位开发者达成几个共识。
​

第一个共识，软件工程没有银弹，Serverless 也不是银弹，它并不是解决所有问题的万能公式。
第二个共识，Serverless 可能解决的是运维域的问题，它是解决特定畛域问题的一个技术，并不是有限延长的，与低代码没有关系。
第三个共识是复杂度守恒定律 - 泰斯勒定律（Tesler’s law）​。典型例子就是苹果，苹果的产品很容易上手操作。但实质上它整体的复杂度是守恒的，它其实是把简单的事件留给了零碎开发工程师和软件开发的工程师，让用户能够顺滑体验。同理 Serverless 也是如此，把部署 or 运维利用、网站的烦复转交给了云服务商，但整体的复杂度是不变的。
第四个共识是邓宁 - 克鲁格效应（The Dunning-Kruger Effect），大家在认知学习过程中，都会呈现这样的倒退曲线：从刚开始无所不知，到对新常识的空想，再到悲观的低谷，迟缓爬坡。咱们学习任何一个新事物都会经验这样一个曲线过程。Gartner 采纳邓宁 - 克鲁格曲线，来解释新技术的倒退周期。
​

集体认知曲线

Gartern 技术倒退曲线
​

作为开发工程师常常会有这种体感，新的技术层出不穷学的很累。Serverless 刚推出来时也一样，大家对这个技术充斥了有限的设想，当设想到了一个巅峰当前，会缓缓意识到设想与事实的差距，切身去领会在产品中应用时就会掉到技术的低谷，而后再迟缓的爬坡。

Serverless 正过后

​

本文将会通过三个局部，为各位介绍 Serverless：
​

第一个局部是“复杂化 for 云开发商”
第二个局部是“简化 for 开发者”
第三个局部，会介绍一些我本人和咱们团队应用 Serverless 时的最佳场景。
​

1、复杂化 for 云开发商

(1) Serverless 架构

Serverless 是一个集大成者，它的整倒退历史是站在伟人的肩膀上的。当初很多云服务商去跑一个函数，底层都是这样架构。首先 Serverless 的运行底层会有一个 CaaS 层。它是一个 Serverless 化的容器服务，大部分的应用服务都会跑在这一层下面，容器调度当初开源的比拟好的解决方案就是 K8s，用 K8s 来调度容器，底层 laaS 就是虚拟机，最底层则是物理机。
​

CaaS 的实现的形式有很多，Serverless 利用底层必须有 CaaS 服务的撑持。除了 Docker 以外，vm 也能够是 CaaS；例如 Node.js 的 vm 也能够做 CaaS，webassembly 也能够做 CaaS 等等。另外在做整体架构设计的时候，还须要一个 Component 层去解决网络货色流量和南北流量的问题，例如 service Mesh 和 ingress 的计划，总体来说 Serverless 背地的架构设计根本都是如此。
​

(2) 云开发商：不可变基础设施

CNCF 对云开发商来说会有 vendor-unlock 的危机，当所有云服务作为不可变根底建设，复杂度下沉到 K8s 层，架构变得通用。因为 CNCF 的架构整套框架是依据配置文件去迁徙的，能够部署在阿里云、也能够腾讯云、亚马逊的云上，甚至本人搭建的公有云。
​

另外对云服务商来说，他们以前积攒的传统的劣势(虚拟机 laas 层的运维劣势和 Caas 层的平台级的劣势）就会慢慢失去。所以如果是 vendor-unlock 云服务商之间就会白热化地打价格战，看谁能提供更好更便宜的服务。

狭义的 Serverless 是整个云服务商运维体系的 Serverless 化。如传统提供一个 MySQL 或 Redis，必须让开发者意识到这是跑在服务器上的，须要提供进去个 ip，但 Serverless 化（Baas 化）后，开发者不须要再去关怀这个服务到底是运行在哪里，只须要申明我须要一个 DB，利用就能够主动去链接并生产 DB。
​

广义的 Serverless 不仅仅是 Severless Computing，还指一个 FaaS 的利用，是由 trigger（也能够归并为 BaaS）+ FaaS+ BaaS 的架构组成的。当初云开发商在 Serverless FaaS 的这一层的外围竞争力是一直推出新的 BaaS 能力，而 BaaS 次要是跟 FaaS 配套去应用的。

下面讲到的云服务商的不可变根底建设，如下图所示，开发者在最下面这层去部署利用，基本不必关怀底层的这些根底建设。当初云服务商提供的 Baas SDK 实际上曾经蕴含在你的这个 FaaS 的 runtime 外面，开发者只须要把它当成一个函数接口去间接调用，不必关怀数据库部署在什么中央、要不要放弃长链接等等。
​

2、简化 for 开发者

​

此图是 Gartner 在 2017 年推出的新兴技术倒退状态，过后 Gartner 感觉 Serverless 还是一个比拟新的概念，大家对它的认知还处于爬坡阶段；但实际上到明天 2021 年，Serverless 曾经进入了平缓俯冲期了，大家对 Serverless 能够解决运维域的问题，有哪些边界的限度等等这些问题曾经有了清晰的认知。
​

为什么最近这几年没有什么特地新的货色推出了？起因在于 Serverless 这层没有特地新的概念诞生，大家更多是在做 FaaS 利用根底建设。现有的各种 Web 利用场景场景是否能够 Serverless 化，比方近期曾经反对了的，数据库 BaaS 化，websocket 反对 FaaS，另外还有很多 Web 利用场景都是通过诸位的致力缓缓爬坡实现，使其可能靠近现实中的 Serverless。

2021 年 Gartner 技术驳回倡议图
图中画框的地位就是 Serverless，绿色代表曾经成熟，能够看出，当初的 Serverless 曾经是一个比拟成熟的技术了，反对大部分 Web 利用的场景了，所以各位开发者大家能够放心大胆地去尝试 Serverless。
​

(1) 运维畛域的 Serverless

​

国内很多人把 Serverless 翻译成无服务器或者叫无服务，这都不太精确，Severless 的反义词是 Serverful，Severful 的意思是须要特地关注服务器，Serverless 的实质是为了升高心智累赘，不须要十分关心服务器，只专一部署函数就行，至于它怎么运行、底层有多少容器、底层有多少服务器来撑持它，开发者都不须要关怀。

传统的模式的前后端开发模式是由：后端提供数据服务，以前叫 SOA 是面向服务的编程，当初比拟风行的是畛域驱动微服务，前端生产组装数据。后端数据接口传统的形式是提供 HTTP API，到当初的风行的 BFF (Backend For Frontend) 胶水层函数编排。配合微服务提供全量数据，是目前业界比拟风行的做法。那么将来的趋势将会全副 BaaS 化，现实的状态是前后端一体化模型驱动，不再须要再写接口。
​

联合 Serverless 做技术改革

Serverless + = …
​

当下 Serverless 所处的阶段的劣势是跟其余畛域的技术联合，Serverless 联合其余畛域来引爆许多技术改革。例如，传统的微服务 + Serverless 联合起来后，能够做成 BaaS 化微服务。以前提供一个微服务，是须要开发者去关怀这个微服务部署在哪里，然而加上 Serverless 后，便不必管部署在哪里，只须要关怀怎么去调用即可。LowCode 加上 Serverless 能够让搭建进去的页面疾速部署并上线；之前的接口函数编排如传统的 BFF，在将来都能够 Serverless 化，变成 SFF（Serverless for frontend），很适宜做前后端一体化计划。
​

（2）开发角色的转变：前后端一体化

Serverless 呈现后，将来还会呈现前后端一体化的场面。当初曾经呈现逻辑编排可视化的工具，例如狼叔的 iMove，目前曾经能够做到后端接口的可视化编排，前端工程师去做一个后端的接口编排变得非常简单。由此能够预感，前端工程师将来的职责能够往后端去延长。

​

而原来的后端工程师会从传统的利用部署逐步转化去做 BaaS 化服务级别的开发，而将来运维工程师也会更偏差于向云端迁徙。这个就是 Serverless 对研发生产链路带来的一系列改革。

3、Serverless 的最佳场景实际

对于 Serverless 应用最近场景的断定，最便捷的形式就是去看云开发商反对哪些 Trigger 事件触发。

​

所以目前这个阶段，各个云开发商都在不停的减少新的 Trigger。如图所示，开发人员在写 FaaS 时，是将 HTTP request 包装成了 Trigger，能够把 FaaS 函数设想成在关闭的一个包裹外面，要如何唤醒这个包裹，怎么关上这个包裹呢？其实就是通过 Trigger 来唤醒。

另外 Serverless 的现阶段，开发语言的重要性没那么高了，语言只是去实现性能所须要的工具。CNCF 推出来当前 FaaS 就曾经是与语言无关的了，那么其实到底是 Node.js，PHP，Python 亦或是其余支流语言的代码 FaaS 都能够，你甚至能够自建一个镜像自定义语言和执行环境。因而在 Serverless 后，多语言的劣势咱们都能够借用，比方用 Python 去解决 AI 数据，Node.js 去解决高并发网络 I / O 等等。

（1）SFF 数据编排

最佳实际就是 BFF + Serverless，这在阿里团体外部是非常常见的。因为阿里外部的大多场景后端都是 Java 工程师，前端团队须要跟工程师去对接，而后端工程师提供的就是 HSF 微服务，能够把它了解为一堆 RPC 接口。以前就是部署一个 Node.js 利用去调接口，拿到数据后对这些数据进行是荡涤、解决，放到前端页面去渲染。然而采纳 Serverless 部署 BFF 的 Node.js 利用后，根本不须要思考跟进流量扩缩容、节省成本等问题。

（2）GitOps 模型

GitOps 对于小企业来说，是十分实用的场景，相当于能够自建一套主动公布上线的管道，不再须要像以前一样，批改一个版本便要测试一遍，目前整个计划曾经非常成熟了。Git 自身反对大量的 hook 函数，所以打造这样一个流程也是非常容易的。须要关注的是要联合云开发商的能力，比方阿里云公布流程便非常自动化，在云下平台公布上线后能够反对线上的流量录制、回放。
​

（3）小而美的技术团队

最初一点是打造小而美的团队。在我的认知中，技术架构有个弱小制约就是：组织架构会决定咱们的技术架构。
​

就像前后端拆散，大多是因为组织架构定义了：前端有前端的领导，后端有后端的领导，所以就会产生前端由前端的开发，后端由后端的开发，须要两头去联调基于 API 沟通。那咱们如果要想打造一个小而美的团队怎么突破这个隔膜呢？
​

Serverless 一个比拟适宜的场景就是，通过前端的服务编排 SFF 将解决掉两头 API 沟通的问题，后端去提供全量的服务即可。这种改革会迫使后端去做微服务化，甚至后端研发采纳 Serverless 去做 BaaS 化，这是反向的导推过程。如果咱们的前端团队把握了 Serverless，有三个劣势：前端的数据编排便不再须要再找后端工程师了；GitOps 解决部署运维，能够升高前端心智累赘；前端同学可能分心形象业务模型。
​

作者简介：
蒲松洋，花名秦粤。极客工夫《Serverless 入门课》作者。Serverless 和 Node.js 布道者，目前负责阿里巴巴前端委员会标准化小组，低代码小组 – 中后盾搭建，Node.js 利用微服务架构。在微服务、Serverless 以及中台我的项目中有着丰盛教训。
​