共计 4545 个字符，预计需要花费 12 分钟才能阅读完成。
作者 | 蒲松洋（秦粤）
作者说
在开始本篇内容前我想与各位开发者达成几个共识。
第一个共识，软件工程没有银弹，Serverless 也不是银弹，它并不是解决所有问题的万能公式。
第二个共识，Serverless 可能解决的是运维域的问题，它是解决特定畛域问题的一个技术，并不是有限延长的，与低代码没有关系。
第三个共识是复杂度守恒定律 - 泰斯勒定律（Tesler’s law）。典型例子就是苹果，苹果的产品很容易上手操作。但实质上它整体复杂度是守恒的，它其实是把简单的事件留给了零碎开发工程师和软件开发的工程师，让用户能够顺滑体验。同理 Serverless 也是如此，把部署 or 运维利用、网站的烦复转交给了云服务商，但整体的复杂度是不变的。
第四个共识是邓宁 - 克鲁格效应（The Dunning-Kruger Effect），大家在认知学习过程中，都会呈现这样的倒退曲线：从刚开始无所不知，到对新常识的空想，再到悲观的低谷，迟缓爬坡。咱们学习任何一个新事物都会经验这样一个曲线过程。Gartner 采纳邓宁 - 克鲁格曲线，来解释新技术的倒退周期。
集体认知曲线
Gartern 技术倒退曲线
作为开发工程师常常会有这种体感，新的技术层出不穷学的很累。Serverless 刚推出来时也一样，大家对这个技术充斥了有限的设想，当设想到了一个巅峰当前，会缓缓意识到设想与事实的差距，切身去领会在产品中应用时就会掉到技术的低谷，而后再迟缓的爬坡。
Serverless 正过后
本文将会通过三个局部，为各位介绍 Serverless：
第一个局部是“复杂化 for 云开发商”
第二个局部是“简化 for 开发者”
第三个局部，会介绍一些我本人和咱们团队应用 Serverless 的最佳场景。
复杂化 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 的架构整套框架是依据配置文件去迁徙的，能够部署在阿里云、也能够腾讯云、亚马逊的云上，甚至本人搭建的公有云。当所有云服务作为不可变根底建设，复杂度下沉到 K8s 层，架构会变得通用。
另外对云服务商来说，他们以前积攒的传统的劣势 (虚拟机 laas 层的运维劣势和 PaaS 层的平台级的劣势）就会慢慢失去。所以如果是 vendor-unlock 云服务商之间就会白热化地打价格战，看谁能提供更优质便宜的服务。
狭义的 Serverless 是整个云服务商运维体系的 Serverless 化。如传统提供一个 MySQL 或 Redis，必须让开发者意识到这是跑在服务器上的，须要提供进去个 ip，但 Serverless 化（BaaS 化）后，开发者不须要再去关怀这个服务到底是运行在哪里，只须要申明须要一个 DB，利用就能够主动去链接并生产 DB。
广义的 Serverless 不仅仅是 Severless Computing，还指一个 FaaS 的利用，是由 trigger（也能够归并为 BaaS）+ FaaS + BaaS 的架构组成的。当初云开发商在 Serverless FaaS 的这一层的外围竞争力是一直推出新的 BaaS（Backend as a Service）能力，而 BaaS 次要是跟 FaaS 配套去应用的。
下面讲到的云服务商的不可变根底建设，如下图所示，开发者在最下面这层去部署利用，基本不必关怀底层的这些根底建设。当初云服务商提供的 BaaS SDK 实际上曾经蕴含在你的这个 FaaS 的 runtime 外面，开发者只须要把它当成一个函数接口去间接调用，不必关怀数据库部署在什么中央、要不要放弃长链接等等。
简化 for 开发者
此图是 Gartner 在 2017 年推出的新兴技术倒退状态，过后 Gartner 感觉 Serverless 还是一个比拟新的概念，大家对它的认知还处于爬坡阶段；但实际上到明天，Serverless 曾经进入了平缓俯冲期了，大家对 Serverless 能够解决运维域的问题，有哪些边界的限度等等这些问题曾经有了清晰的认知。
为什么最近这几年没有什么特地新的货色推出了？起因在于 Serverless 这层没有特地新的概念诞生，大家更多是在做 FaaS 利用根底建设。现有的各种 Web 利用场景场景是否能够 Serverless 化，比方近期曾经反对了的，数据库 BaaS 化，websocket 反对 FaaS，另外还有很多 Web 利用场景都是通过诸位的致力缓缓爬坡实现，使其可能靠近现实中的 Serverless。
2021 年 Gartner 技术驳回倡议图
图中画框的地位就是 Serverless，绿色代表曾经成熟，能够看出，当初的 Serverless 曾经是一个比拟成熟的技术了，反对大部分 Web 利用的场景了，所以各位开发者大家能够放心大胆地去尝试 Serverless。
1) 运维畛域的 Serverless
国内很多人把 Serverless 翻译成无服务器或者叫无服务，这都不太精确，Severless 的反义词是 Serverful，Serverful 的意思是须要特地关注服务器，Serverless 的实质是为了升高心智累赘，不须要十分关心服务器，只专一部署函数就行，至于它怎么运行、底层有多少容器、底层有多少服务器来撑持它，开发者都不须要关怀。
传统的模式的前后端开发模式是由：后端提供数据服务，以前叫 SOA 是面向服务的编程，当初比拟风行的是畛域驱动微服务，前端生产组装数据。后端数据接口传统的形式是提供 HTTP API，到当初的风行的 BFF (Backend For Frontend) 胶水层函数编排。配合微服务提供全量数据，是目前业界比拟风行的做法。那么将来的趋势将会全副 BaaS 化，现实的状态是前后端一体化模型驱动，不再须要再写接口。
2）联合 Serverless 做技术改革
Serverless + = …
当下 Serverless 所处的阶段的劣势是跟其余畛域的技术联合，Serverless 联合其余畛域来引爆许多技术改革。例如，传统的微服务 + Serverless 联合起来后，能够做成 BaaS 化微服务。以前提供一个微服务，是须要开发者去关怀这个微服务部署在哪里，然而加上 Serverless 后，便不必管部署在哪里，只须要关怀怎么去调用即可。LowCode 加上 Serverless 能够让搭建进去的页面疾速部署并上线；之前的接口函数编排如传统的 BFF，在将来都能够 Serverless 化，变成 SFF（Serverless for frontend），很适宜做前后端一体化计划。
3）开发角色的转变：前后端一体化
Serverless 呈现后，将来还会呈现前后端一体化的场面。当初曾经呈现逻辑编排可视化的工具，例如狼叔的 iMove，目前曾经能够做到后端接口的可视化编排，前端工程师去做一个后端的接口编排变得非常简单。由此能够预感，前端工程师将来的职责能够往后端去延长。
而原来的后端工程师会从传统的利用部署逐步转化去做 BaaS 化服务级别的开发，而将来运维工程师也会更偏差于向云端迁徙。这个就是 Serverless 对研发生产链路带来的一系列改革。
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 以及中台我的项目中有着丰盛教训。
戳此处，可观看 Serverless Meetup 深圳站回放！
