简介：极客时间《Serverless 入门课》作者秦悦最新文章：再谈当时的Serverless。文章分为三个部分，对于云开发者来说比较复杂；为开发人员简化，以及团队使用Serverless的最佳场景。作者表示，在开始这篇文章之前，我想与所有开发者达成几点共识。第一个共识是软件工程没有银弹，serverless也不是银弹。它不是解决所有问题的灵丹妙药。第二个共识是Serverless能解决的是运维域的问题。是解决特定领域问题的技术。它不是无限可扩展的，与低代码无关。第三个共识是复杂性守恒定律——特斯勒定律。一个典型的例子是苹果，它的产品很容易使用。但本质上，它的整体复杂性是守恒的。它实际上把复杂的事情交给了系统开发工程师和软件开发工程师，让用户有流畅的体验。Serverless也是如此，将部署或维护应用程序和网站的麻烦转移给了云服务商，但整体的复杂度没有改变。第四个共识是邓宁-克鲁格效应（TheDunning-KrugerEffect）。在认知学习的过程中，每个人都会有这样的发展曲线：从一开始的一无所知，到幻想新知识，再到失望的低谷，慢慢攀登。当我们学习任何新事物时，都会经历这样一个曲线过程。Gartner使用Dunning-Kruger曲线来解释新技术的开发周期。PersonalCognitiveCurveGarternTechnologyDevelopmentCurve作为开发工程师，经常有这样的感受。新技术层出不穷，学起来很累。Serverless刚上线的时候也是这样。大家对这项技术充满了无限的想象。当想象力达到顶峰时，他们会逐渐意识到想象与现实之间的差距，并亲身体验到在产品中使用时，会陷入技术鸿沟。低谷，然后慢慢爬升。届时，本文将通过三个部分向大家介绍Serverless：第一部分是“云开发者的复杂性”，第二部分是“开发者的简单化”，第三部分将介绍我自己和其他人。我们团队使用Serverless时的最佳场景。一、云开发者的复杂性（一）Serverless架构Serverless是高手，它的整个发展史都站在巨人的肩膀上。现在很多云服务商跑一个功能，底层架构是这样的。首先，Serverless运行底层会有一个CaaS层。它是一个无服务器容器服务。大多数应用服务将运行在这一层。容器调度比较好的开源方案是K8s。K8s是用来调度容器的。IaaS底层是虚拟机，最底层是物理机。CaaS的实现方式有很多种，Serverless应用的底层必须有CaaS服务的支持。除了Docker，vm也可以是CaaS；比如Node.jsvm也可以是CaaS，webassembly也可以是CaaS等等。另外在设计整体架构的时候，需要一个组件层来解决网络东西向流量和南北向流量的问题，比如ServiceMesh和Ingress的解决方案。总的来说，serverless背后的架构设计基本是一样的。(2)云开发者：不可变的基础设施CNCF将给云开发者带来供应商解锁危机。当所有的云服务都被用作不可变的基础设施时，复杂性下沉到K8s层，架构变得通用。因为CNCF架构的整个框架都是根据配置文件进行迁移的，所以可以部署在阿里云、腾讯云、亚马逊云，甚至是自己搭建的私有云上??。此外，对于云服务商来说，之前积累的传统优势（虚拟机IaaS层的运维优势和Caas层的平台级优势）将逐渐丧失。所以，如果是vendor-unlock云服务商，就会出现激烈的价格战，看谁能提供更好、更便宜的服务。广义上的Serverless是指整个云服务商运维体系的Serverless化。比如传统上提供一个MySQL或者Redis，开发者必须意识到这是在服务器上运行的，需要提供一个ip，但是在Serverless（Baas）之后，开发者不再需要关心服务是否运行在Where上，只要声明我需要一个DB，应用程序就可以自动链接和消费这个DB。从狭义上讲，Serverless不仅是SeverlessComputing，还是一种FaaS应用，由触发器（也可以合并为BaaS）+FaaS+BaaS架构组成。现在ServerlessFaaS这一层云开发者的核心竞争力是不断引入新的BaaS能力，而BaaS主要是和FaaS结合使用。上文提到的云服务商的不可变基础设施，如下图所示，开发者在顶层部署应用，无需关心底层基础设施。现在云服务商提供的BaasSDK实际上已经包含在你的FaaSruntime中了。开发者只需将其作为函数接口直接调用即可，无需关心数据库部署在哪里，是否维护长链接等。2.为开发者简化这张图是Gartner在2017年推出的新兴技术的发展现状，当时Gartner觉得Serverless还是一个比较新的概念，大家对它的认知还处于爬坡阶段；但实际上，到2021年的今天，Serverless已经进入了一个平缓攀升的时期。Serverless在运维领域能解决的问题，有哪些边界限制，大家都很清楚。为什么近年来没有推出任何特别新的东西？原因是serverless层没有特别新的概念，大家做的更多的是FaaS应用基础设施建设。现有的各种web应用场景能否做到serverless，比如数据库BaaS，websocket支持FaaS，还有很多其他的web应用场景都是通过你的努力逐步实现的，使得它可以接近理想中的Serverless。GartnerTechnologyAdoptionSuggestionsin2021图中画框的位置是Serverless。绿色代表成熟。可见目前的Serverless已经是一个比较成熟的技术，支持大部分的web应用场景，所以开发者可以放心大胆的尝试Serverless。（1）运维领域的Serverless。国内很多人把Serverless翻译成serverless或者serverless。这是不准确的。Severless的反义词是Serverful。Severful意味着您需要特别注意服务器。Serverless的本质是减轻精神压力负担，你不需要太关心服务器，只需要专注于部署功能即可。至于它怎么跑，底层有多少个容器，底层有多少台服务器来支撑，开发者不用关心。传统的前后端开发模式是：后端提供数据服务。以前叫SOA，就是面向服务的编程。现在比较流行使用领域驱动的微服务，前端消费组装数据。传统的后端数据接口方式是提供HTTPAPI，现在流行的BFF（BackendForFrontend）胶层功能编排。配合微服务提供全量数据是目前业界比较流行的做法。那么未来的趋势就是全BaaS。理想状态是前后端集成模型驱动，不需要写接口。结合Serverless进行技术变革Serverless+=...Serverless现阶段的优势在于结合了其他领域的技术。Serverless与其他领域结合，引爆了很多技术变革。比如传统的微服务+Serverless可以组合成基于BaaS的微服务。以前提供一个微服务需要开发者关心微服务部署在哪里，但是有了Serverless之后，部署在哪里已经不重要了，只关心如何调用。LowCode加上Serverless可以让构建好的页面快速部署上线；之前的接口功能安排像传统的BFF，以后可以是serverless，变成SFF（Serverlessforfrontend），非常适合做前后端一体化的方案。（2）开发角色的转变：Serverless出现后，前后端一体化，未来会出现前后端一体化的局面。现在有逻辑排列和可视化的工具，比如狼叔的iMove，已经可以做后台界面的视觉排列了。前端工程师做一个后端的接口整理是非常简单的。可以预见，未来前端工程师的职责可以延伸到后端。原有的后端工程师会逐渐从传统的应用部署向基于BaaS的服务级开发转变，未来的运维工程师也将更倾向于向云端迁移。这是Serverless给研发和生产环节带来的一系列变化。3、Serverless最佳场景实践判断Serverless最新使用场景最便捷的方法就是看云开发者支持哪些Trigger事件。所以在这个阶段，各个云开发者都在不断的添加新的Triggers。如图所示，开发者在编写FaaS时，将HTTP请求包装成一个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部署BFFNode.js应用后，基本无需考虑后续扩容缩容、节省成本等问题。(2)GitOps模型GitOps对于小型企业来说是一个非常适用的场景。相当于搭建了一套自动发布和上线的流水线。不再需要像以前那样测试修改后的版本。目前，整个解决方案已经完成。很成熟。Git本身支持大量的钩子函数，所以创建这样一个进程是非常容易的。需要注意的是结合云开发者的能力。比如阿里云的发布过程非常自动化，在云下平台发布后可以支持在线流量记录和回放。（3）小而美的技术团队最后一点就是打造小而美的团队。在我看来，技术架构有一个很强的约束条件：组织架构将决定我们的技术架构。就像前后端分离，多半是因为定义了组织结构：前端有前端领导，后端有后端领导，所以前端是前端开发，后端开发，需要基于API通信的中间联调。那么如果我们想要打造一个小而美的团队，我们该如何打破这个壁垒呢？Serverless更适合的场景是前端服务编排SFF，解决中间的API通信问??题，后端可以提供全服务。这种变化会倒逼后端做微服务，甚至后端研发用Serverless做BaaS，这是一个逆向推导的过程。如果我们的前端团队掌握Serverless，有三个好处：前端数据整理不再需要找后端工程师；GitOps解决部署运维，可以减轻前端的精神负担；前端同学可以专心抽象业务模型。作者简介：蒲松阳，字秦越。极客时间《Serverless 入门课》作者。Serverless和Node.js布道者，目前负责阿里巴巴前端委员会标准化组，低代码组——中后台建设，Node.js应用微服务架构。在微服务、无服务器和中期项目方面拥有丰富的经验。原文链接本文为阿里云原创内容，未经许可不得转载。
