从运维域看 Serverless 真的就是万能银弹吗？

Posted 2022-01-28 阿里云云栖号

简介：极客时间《Serverless 入门课》作者秦粤最新文章: 再次讨论正当时的 Serverless。文章分为三个部分，分别是 复杂化for 云开发商; 简化 for 开发者，以及团队使用 Serverless 的最佳场景。

作者说

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

第一个共识，软件工程没有银弹， 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 以及中台项目中有着丰富经验。

原文链接

本文为阿里云原创内容，未经允许不得转载。