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

本文主要是介绍从运维域看 Serverless 真的就是万能银弹吗？，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

作者 | 蒲松洋（秦粤）

作者说

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

第一个共识，软件工程没有银弹， 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 深圳站回放！

这篇关于从运维域看 Serverless 真的就是万能银弹吗？的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！