Serverless、事件和触发器Serverless 系统本质上就是事件驱动的系统，采用了事件驱动的架构。这种架构改变了 Serverless 系统的开发和管理方式。微服务架构的主要目标是提供高度响应的 API，这也是服务间主要的交互机制。Serverless 架构的主要目标是对发生的事件做出响应，API 是生成事件的唯一机制。在 AWS 生态系统（最为成熟的 Serverless 生态系统）中，API 并不是主要的接口，事件变得更为重要。这也就是为什么会有将近 50 个事件来触发一个 Lambda 函数。如果可以不通过 API 网关来触发 Lambda 函数，就会更快、更高效，特别是在从其他 AWS 接口触发事件的时候。其中最重要的是函数的单向性。大多数微服务采用的是请求 / 响应式的架构，这也是大多数 Web 应用程序的运行模式。Serverless 应用程序里的函数通常是单向的，并使用队列充当回路断路器，所以请求 / 响应式的架构就变得不那么常见了。数据层的管理方式也不太一样。最好是可以使用多个函数，而不是使用一个带有切换开关的代理函数。相比微服务架构，多函数还有另外一个好处。例如，如果一个函数出错，因为它是无状态的（或至少应该是），所以只会影响该函数本身，不会影响到应用程序的其余部分。如果只是简单地从微服务转向 Serverless 架构，虽然确实会给你带来一些好处，但也会错失很大一部分 Serverless 应用程序的真正价值。从很多方面来看，微服务与 Serverless 应用程序是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。从微服务到 Serverless那么，从微服务到 Serverless 需要经过怎样的路径？微服务已经相当普及了，那么是否存在一条简单的路径，可以直接从一方过渡到另一方？我想，这也正是 Serverless 世界正在解决的问题。最近，Twitter 上有很多与这个话题相关的推文。这里引用其中的一条，看看社区都是怎么讨论这个话题的。现在有很多工具声称它们会让 Serverless 应用程序的构建变得更容易，但实际上最终都是要去到它们的平台上。我不认为它们会带来额外的价值或者会让人们更好地理解什么是 Serverless 架构。我们非常清楚地意识到，我们正在讨论的是 Serverless 架构的未来，但并没有说这会让从旧架构风格过渡到 Serverless 会变得更容易，或者断定 Serverless 是不是一个正确的选择（在某些情况下可能不是）。这是有原因的。人的思维是不容易改变的。构建一个 Lambda 函数很容易，但构建一个真正的 Serverless 应用程序并不容易，它需要在思维上做出一系列改变，而这样做相对没有那么容易。

2015 年，第一个使用 AWS Lambda 和 API 网关的教程出现了，它主要关注的是如何复制微服务。但是，随着时间推移，那些大规模使用 AWS Lambda 的人越来越清晰地意识到，使用 AWS Lambda 的微服务存在严重的局限性。首先说说为什么会有微服务？微服务之所以会出现，主要是因为单体应用程序存在不足。简单地说，单体就是把所有逻辑都塞进同一个逻辑代码库的应用程序。在单服务器环境时代，多服务器价格十分昂贵。默认情况下，应用程序是按照单服务器的方式进行构建的。部署一个单体就是把应用程序的一部分或者整体部署到一台服务器上。在部署单体时，必须确保不出任何问题。通常，一个很小的改动都会导致整个应用程序和服务器宕机。在云服务出现之后，通过简单的操作就可以在几分钟而不是几天或者几周之内分配好服务器实例，这就为关注点分离提供了条件。于是，拆分单体就成了一件势在必行的事情，微服务也就孕育而生。你不再需要把所有逻辑都部署在同一个实例或服务器上，你可以把不同的部分放在不同的实例上，然后使用轻量级的通信协议（比如 HTTP API）把它们连接起来。于是，应用程序架构就从单体转向了微服务。微服务的价值在于，在做出修改时，你修改的不是整个代码库，而是其中的一个微服务，它只是整个应用程序的一部分。也就是说，改动不会造成整个应用程序宕机。但这毕竟也只是一个美好的理论，一个比单体更好的理论，在现实中，它并不完美。服务接口（通常是 HTTP 接口）是微服务的关键所在。这本没有什么问题，但是，当存在大量的服务时，要协调好它们就成了一个大问题。向 Serverless 架构转变AWS 上的第一个 Serverless 应用就是一个微服务：一个 API 网关接口，网关背后是 Lambda 函数和路由器。每一个 API 网关都是一个服务接口，看起来似乎是合乎逻辑的。你可以构建一系列的服务，每个服务都可以独立伸缩，某种程度上说，这样做非常合理。但问题是，AWS Lambda 和 FaaS 不应该被当作实例或服务器看待。因为底层使用了服务器（互联网上的很多东西都运行在服务器之上，但就是没有人指出“S3 也是有服务器的”、“BigTable 也是有服务器的”或者“Azure Active Directory 也是有服务器的”），所以我们假设你应该简单地把 FaaS 函数看成是服务，也就是有些人所谓的“minilith”。但问题是，Serverless 的关键点是事件，而这一点往往被忽略掉。

1.1.12 与传统模式架构的区别传统的架构模式是使用C/S架构的，在典型的web应用程序中，服务器接收前端的HTTP请求处理，在保存或查询数据库之前，数据可能会经过多个应用层，最终后端会返回一个响应。比如它可以是JSON形式或其他格式等。然后他会将响应返回给客户端，比如如下图所示：在传统开发模式中，开发流程：设计师设计页面 -> 服务端开发 和 前端分别开发，服务器开发完成后，-> 服务部署 ->服务部署完成后，就是前后端联调 -> 前后端联调 -> 前后端联调完成后就是测试了，-> 测试， 测试完成需要上线，因此 -> 上线，上线完成后，需要运维维护，因此 -> 运维。在传统开发模式中，开发一个应用程序，从开始到上线需要不同的角色来做不同的事情，沟通成本非常大，并且运维过程中需要考虑到 服务器的负载均衡、事务、集群、缓存、消息传递和数据冗余等等这些事情，在目前传统模式中存在如上问题。可以使用如下示意图来看下如上流程。如下图所示：在Serverless架构中，应用业务逻辑是基于FaaS架构形成多个相互独立的功能组件的。并且以API服务的形式向外提供服务，在FaaS中，后端的应用被拆分成为一个个函数，我们只需要编写完成函数后部署到serverless服务即可。后续我们也不用关心任何服务器的操作。那么整个流程就只需要我们一个前端工程师的角色来完成所有的开发工作，那么沟通成本降低了。因此我们可以使用如下示意图来表示项目流程，如下所示：前端工程师是居于serverless去写后端服务的，典型的就是居于 AWS Lambda 中编写代码，AWS中支持不同的语言。Lambda计算服务它能够以大规模并行的方式执行代码来响应事件。通过使用Lambda以及使用各种功能强大的API和Web服务，开发者可以快速的构建松耦合，可扩展性及高效的架构体系。

1.1.11 现状与局限Serverless现状与局限当前国内的很多公司也在尝试Faas或者Serverless架构，不过可以猜测出大家或多或少都心存疑虑或者有不放心之感，不敢真正的放上自己的线上服务。目前看来，虽然Serverless市面上都吹的很火，但实际落地的寥寥可数，星星点点的一些火花，还是难以形成燎原之势。Serverless这片土地十分辽阔，但是各大云厂商却都是在自己和自己过家家，至于其他人怎么玩的，就不怎么关心了。所以，目前一个很大的问题就是我们在一家函数计算平台跑了自己的服务之后，基本上就和这个平台绑定了，特别是如果你还用到Eventing，由于都是基于平台内部特定的事件触发机制，迁移成本还是比较高的。终极原因，目前还没有一个强势而大一统的框架和平台，可以让大家甘愿臣服。想当年，容器编排领域兴起，Kubernetes和Mesos大战，两边各自有人站队，云厂商也各自押宝，如今Kubernetes一统江湖，大家都默默的建立起了基于Kubernetes的容器云平台，于是围绕着Kubernetes的云原生生态蓬勃发展。由于没有统一的平台，针对Serverless目前还存在的一些局限，大家做的优化和改进也是各自为战，难以落地生根。实现：KnativeKnative是某厂商开源的Serverless架构方案，旨在提供一套简单易用的Serverless平台，把Serverless 标准化。Knative不局限于Faas，而是期望能够运行所有的无状态工作负载。像其他绝大部分的Faas或者Serverless平台一样，Knative也是基于Kubernetes，不过，Knative还基于Istio或者Gloo网关等实现流量的分发和管理。还在不久之前，Knative分为三个组件：BuildServingEventingBuild负责将代码转换成我们需要的容器镜像，Serving则是提供Serverless的运行方式，Eventing则致力于提供标准化的事件触发机制。不过，现在Build模块已经被弃用，被由Build的设计思路而发起的Tekton项目替换（参考：《Kubernetes原生CI/CD工具：Tekton探秘与上手实践》）。当然你也可以使用其他合适的CI/CD工具替代。Serving模块主要做的工作本质上就两个：流量入口的自动创建和管理以基于istio为例，Knative自动创建istio的ingressgateway，服务的service等，将流量导入新部署的服务，而不需要手动的创建各种service，ingress暴露服务和流量入口。同时，将不同版本对应不同的deployment，可以方便的实现蓝绿、灰度等发布部署方式。如下图所示：冷启动和自动扩缩容Knative有自身基于流量请求算法的metric自动扩缩容（KPA）的方式，也支持Kubernetes原生的HPA实现自动扩缩容。同时，在服务缩容为0之后，Serving会将服务流量路由到冷启动的组件，缓存请求，然后扩容服务，再将流量导入启动后的服务副本。Knative Eventing则联合 CNCF Serverless WG制定一套事件格式规范并推广：Knative Eventing与CNCF Serverless WG制定的事件格式规范只需要各个云厂商都按照这个规范，我们的Serverless服务就可以进行跨平台的事件触发，也不会被特定的云厂商绑定。

1.1.10 服务特性除了服务的粒度不一样之外，无状态工作负载和Faas一般都具有以下Serverless的特性：1-step deploy既然是Serverless，开发者真正关心和面对的是代码层面，所以不管是函数还是一个代码工程，一键构建和部署是我们的终极期望。Kubernetes生态下有各种CI/CD解决方案，但是缺乏更加一键式的工具可以帮我们将代码（函数）迅速转变成部署的服务。所以，一个足够好用的本地client工具、一个完善而高效的CI/CD平台很重要。对于Faas，可以让用户便捷的将函数部署到Serverless平台，对于无状态负载，则可以根据用户需求暴露一些构建的自定义配置和流程。Automatically在Kubernetes上一般服务实际的运行都或多或少的需要我们创建很多的Kubernetes资源，例如service、ingress等，而Serverless会做更多的自动化操作，以便更方便的提供服务。例如，Serverless平台会自动提供流量入口和路由，部署完成后可以迅速对外提供服务，同时提供类似蓝绿发布、灰度等流量管理等功能。Auto-scale毫无疑问，Kubernetes也有HPA可以提供自动扩缩容。不过，HPA敢让服务副本数缩为0吗？当然不敢，试想一下，如果服务的副本数为0，相当于不再运行了，用户的流量如何导入呢，用户连服务的接口都调不通了，HPA更没有metric数据来感知去扩容服务了。HPA无法缩容为0，对于某些短运行的计算类服务来说，是无法接受的，因为这样就不能真正的做到无服务，不实际运行时不占资源不计费。当然Serverless可以做到，让服务在没有请求时自动缩为0，在有流量的时候从0启动，或者流量增大时快速的扩容，迅速应对流量的变化。不过，还有一个Serverless业界都很关注的点，就是服务从0扩容为多副本时启动的延时时间，一般称为冷启动的问题。如果冷启动时间太长，对于用户的第一次请求肯定有很大影响，业内也有很多大厂在做一些优化。但是如果不是直接面向用户流量的服务，例如我只想跑个数据处理算法，其实也不在乎这几百毫秒的启动延迟，如果是类似前端的web服务，恐怕大部分人还是宁愿空跑一个单副本的服务，也不愿意冒这个风险吧。EventingServerless的另外一个特征是基于eventing事件进行触发，事件实际上是一个比较抽象的说法，很多东西都可以理解为事件。例如，用户的请求可以认为是一个事件，git的webhook可以认为是事件，kafka上有了消息可以理解为一个事件，包括Kubernetes的各种资源操作等等都是。所以，其实事件触发我们并不陌生，我们的平时开发和设计架构里经常都会有意无意的使用到事件触发的机制，只是太过平常，反而没有人去注意和抽象出这么一个理念。现在大家都在倡导云原生，很多服务都是往云上迁移和部署，事件触发机制在云上可以有更多的扩展性和想象力。例如，我们的Serverless应用可以监听云上的中间件或者基础组件的事件，通过这些事件，触发特定的Serverless应用，从而打通云上的Paas服务，实现云上服务的一体化。总结下来，虽然目前Serverless很火但我们更应该静下心来思考，为什么会有Serverless的诞生，Serverless最原始的需求和驱动力在哪？是Kubernetes不够好用还是Servicemesh不够友好？Kubernetes被认为是下一代的分布式操作系统，操作系统上必然会运行各种各样千奇百怪的程序，有的需要直面系统内核，有的只是提供用户更好的UI，不过，有一类程序可以以更便捷的方式去编译、运行，而提供这一切的工具与平台就是Serverless。所以，Serverless其实只是一种云原生应用更为特殊的实现和表现方式，也有很多的应用并不适合以Serverless的方式去运行。无服务器固然是愿景，大量的封装和抽象让开发者无需感知很多东西，但这个宇宙运行的规律可能并非直白的线性系统，混沌和复杂性才是常态。如果有人告诉你，Serverless是所有应用的终极目标。

1.1.9 核心诉求为什么需要Serverless前端为什么想要上Serverless，其实也很好理解，随着node.js的普及、前端工程化以及BFF的兴起，越来越多的前端需要关心服务的构建、部署、运维，服务的日志、监控报警等等，严重拖累了前端的开发效率，让前端花很多时间在服务器上排查问题，无疑是痛苦而低效的。对于前端来说，最原始的诉求是，我不愿意管服务器等底层资源，哪台节点宕机了，麻烦不用通知我；流量太大了，服务需要扩容了，我也不想关心；我只需要写好代码，就可以自动部署到服务器上，代码有bug，能让我看日志和监控排查问题就行。其实这也不单单是前端的梦想，很多后端或者数据类的研发，也有同样的需求。不过咋看很美好，但是仔细想想，有一些后端的业务很复杂，服务间调用关系以及各种特异化需求其实很难适用于Serverless，想完全不关心底层的服务器，有点困难。所以，Serverless并非银弹，关键是看业务场景和需求，就算只有50%的业务适合，能解决这50%业务的问题，那也是了不起的成就。Faas和Baas又是什么？了解Serverless的同学，或多或少都听过Faas，Faas即Function as a service，一般称作函数即服务。作为开发人员，只需要写一个函数，就可以在例如AWS Lambda等各种函数计算平台上运行起来，真正实现了对服务器的无感知，同时可以对外快速暴露API接口，可以基于函数级别的自动扩缩容，可以监听各种事件进行触发。而且Faas结合云平台的webIDE，如果webIDE设计的足够好，可以给我们带来云平台上更方便的开发体验，结合云上的各种工具和生态，未来会有更大的想象空间。不过，显而易见，以函数为最小粒度，有一些局限性。微服务是以功能职责为划分，拆分成一个一个专注于特定功能和需求的服务，为了解决微服务之间的网络调用和流量管理，引入了很多服务治理等相关的功能和组件，可以想象一下，如果把服务模块再拆分为函数的粒度，函数之间的调用关系无疑会爆炸，再思考一下，如何把老的服务改造成Faas形态，如何复用函数之间的逻辑，如何管理大量函数代码，这无疑对开发者带来了很多困扰。所以，Faas不太适合一般后台长期运行的web服务型应用，真正适合的是那些数据计算、批处理等业务，这些业务逻辑比较单一，运行完可以停止，而且更适合Serverless中基于事件触发的特性，冷启动的延时也无所谓。Faas的一个基本特征是无状态，那实际上的数据或者状态该如何存储呢，所以说到Faas一般都会提及Baas，即Backend as a service，不过类似的Xaas的名词太多了，Baas这个名词看着就像是有人为了强行补充Faas没有干的活儿而起的。因此有些人粗暴的总结Serverless = Faas + Baas，当然如果你要强行认为Serverless就是函数计算，那这个也没有问题。不过，我们的观点是：Faas只是Serverless的一种特例。在这个世界上，除了Faas，还有更多的无状态工作负载适合以Serverless的形态去运行。

1.1.8 业务场景常见的业务处理场景「Web 应用/移动应用后端」Serverless 架构和云厂商所提供的其他云产品进行结合，开发者能够构建可弹性扩展的移动或 Web 应用程序 – 轻松创建丰富的无服务器后端，而且这些程序可在多个数据中心高可用运行，无须在可扩展性、备份冗余方面执行任何管理工作。例如 Web 应用处理示例：「实时文件/数据处理」视频应用、社交应用等场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如：对于用户上传的图片，可以使用多个函数对其分别处理，包括图片的压缩、格式转换、鉴黄鉴恐等，以满足不同场景下的需求。例如：通过 Serverless 架构所支持的丰富的事件源，通过事件触发机制，可以通过几行代码和简单的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行清洗、对 MNS 消息进行自定义消费等：「离线数据处理」通常要对大数据进行处理，需要搭建 Hadoop 或者 Spark 等相关大数据的框架，同时要有一个处理数据的集群。通过 Serverless 技术，只需要将获得到的数据不断的存储到对象存储，并且通过对象存储相关触发器触发数据拆分函数进行相关数据或者任务的拆分，然后再调用相关处理函数，处理完成之后，存储到云数据库中。例如：某证券公司每 12 小时统计一次该时段的交易情况并整理出该时段交易量 Top 5；每天处理一遍秒杀网站的交易流日志获取因售罄而导致的错误从而分析商品热度和趋势等。函数计算近乎无限扩容的能力可以使用户轻松地进行大容量数据的计算。利用 Serverless 架构可以对源数据并发执行多个 mapper 和 reducer 函数，在短时间内完成工作；相比传统的工作方式，使用 Serverless 架构更能避免资源的闲置浪费从而节省成本，整个流程可以简化为：「人工智能领域」在 AI 模型完成训练后，对外提供推理服务时，可以使用 Serverless 架构，通过将数据模型包装在调用函数中，在实际用户请求到达时再运行代码。相对于传统的推理预测，这样做的好处是无论是函数模块还是后端的 GPU 服务器，以及对接的其他相关的机器学习服务，都是可以进行按量付费以及自动伸缩，从而保证性能的同时也确保了服务的稳定：「IoT 等物联网领域」目前很多厂商都在推出自己的智能音箱产品，用户可以对智能音箱说出一句话，智能音箱可以通过互联网将这句话传递给后端服务，然后获得到反馈结果，再返回给用户。通过 Serverless 架构，可以将 API 网关、云函数以及数据库产品进行结合来替代传统的服务器或者是虚拟机等。通过这样的一个架构，一方面，可以确保资源的按量付费，只有在使用的时候，函数部分才会计费，另一方面当用户量增加之后，通过 Serverless 实现的智能音箱系统的后端，也会进行弹性伸缩，可以保证用户侧的服务稳定，当要对其中某个功能进行维护，相当于对单个函数进行维护，并不会对主流程产生额外风险。相对来说会更加安全、稳定等：「监控与自动化运维」在实际生产中，经常需要做一些监控脚本来监控网站服务或者 API 服务是否健康，包括是否可用、响应速度等。传统的方法是通过一些网站监控平台 （如阿里云监控等）来进行监控和告警服务，这些监控平台的原理是通过用户自己设置要监控的网址和预期的时间阈值，由监控平台部署在各地区的服务器定期发起请求对网站或服务的可用性进行判断。当然，这些服务很多都是大众化的，虽然说通用性很强，但是实际上并不一定适合。例如，现在需要监控某网站状态码，不同区域的延时，并且设置一个延时阈值，当网站状态异常或者延时过大时，通过邮件等进行通知告警，针对这样一个定制化需求，目前来说大部分的监控平台很难直接实现，所以定制开发一个网站状态监控工具就显得尤为重要。除此之外，在实际的生产运维中，还非常有必要对所使用的云服务进行监控和告警，例如在使用 Hadoop、Spark 的时候要对节点的健康进行监控；在使用 K8S 的时候要对 API Server、ETCD 等多维度的指标进行监控；在使用 Kafka 的时候，也要对数据积压量，以及Topic、Consumer等指标进行监控；这些服务的监控，往往不能通过简单的 URL 以及某些状态来进行判断，在传统的运维中，通常会在额外的机器上设置一个定时任务，对相关的服务进行旁路监控。Serverless 架构的一个很重要应用场景就是运维、监控与告警，通过与定时触发器进行结合使用，可以非常简单地实现某些资源健康状态监控与感知，并进行一些告警功能建设、自动化运维能力建设：总结从虚拟空间到云主机，从自建数据库等业务，到云数据库等服务，云计算的发展是迅速地，未来的方向和形态却是模糊的，没人知道云计算的终态是什么。诚然，现在有人说 Serverless 实现了当初了云计算目标，Serverless才是真正的云计算，但是没人可以肯定地说，Serverless 就是云计算的终态表现，客观地说，或许，Serverless 也仅仅是一个过渡的产物，但是这就要交给时间去验证了。

1.1.7 应用场景Serverless 架构作为云原生技术未来的演进方向，无服务器架构技术也从观望逐渐落地，据 Gartner 的过往预测数据显示：到 2020 年全球将有 20% 的企业部署无服务器架构。Serverless 将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。聚焦业务核心价值随着云服务的发展，计算资源被高度抽象化，从物理机到云服务器，再到容器服务，计算资源逐渐变得更加细腻化。Serverless 架构将会成为未来云计算领域中重要的技术架构，被更多的业务所采纳，成为其技术选型，那么再进一步的深究，Serverless 在什么场景下可以有非常优秀的表现，在什么类型的场景下可能表现得并不是很理想呢？或者说，有哪些场景更适合 Serverless 架构呢？Serverless架构的应用场景，通常是由其特性决定方向，所支持的触发器决定具体场景。CNCF Serverless Whitepaper v1.0 所描述的用户场景如图上图所示，在 CNCFServerless Whitepaper v1.0 关于 Serverless 架构所适合的用户场景包括：异步的并发，组件可独立部署和扩展的场景应对突发或服务使用量不可预测的场景短暂、无状态的应用，对冷启动时间不敏感的场景需要快速开发迭代的业务，因为无需提前申请资源，因此可以加快业务上线速度CNCF 基于 Serverless 架构的特性给出了四个用户场景之外，还结合常见的触发器提供了详细的例子：响应数据库更改 （插入、更新、触发、删除） 的执行逻辑对物联网传感器输入消息 （如 MQTT 消息） 进行分析处理流处理 （分析或修改动态数据）管理单次提取、转换和存储需要在短时间内进行大量处理 （ETL）通过聊天机器人界面提供认知计算 （异步）调度短时间内执行的任务，例如 CRON 或批处理的调用机器学习和人工智能模型持续集成管道，按需为构建作业提供资源，而不是保持一个构建从主机池等待作业分派的任务以上是从理论上描述了 Serverless 架构适合的场景或业务，云厂商将会站在自身的业务角度，整体来描述 Serverless 架构的典型场景。通常情况下，对象存储为触发器在 Serverless 架构的典型应用场景包括视频处理、数据 ETL 处理等；API 网关更多会为用户赋能对外的访问链接以及相关联的功能等，当以 API 网关作为 Serverless 相关产品的触发器时，常见的应用场景就是后端服务，包括 App 的后端服务，网站的后端服务甚至是微信小程序等相关产品的后端服务，同时像一些智能音箱也会开放相关的接口，这个接口也是可以通过 API 网关出发云函数，获得相应的服务等；除了对象存储触发以及 API 网关触发，常见的触发器还有消息队列触发器，Kafka 触发器，日志触发器等。

1.1.6 架构优势在 2017 年，CNCF Serverless WG 成立了，并且开始以社区的力量推动 Serverless 快速前行，包括 CNCF Serverless Whitepaper、CloudEvents 等相关的立项研究与探索，2017 年末，eWEEK 的 ChrisJ. Preimesberger 发表文章Predictions 2018: Why ServerlessProcessing May Be Wave of the Future 来表达在 “全新的阶段下” 大家对 Serverless 的看法和期盼，在这篇文章中诸多来自知名团队以及公司的相关负责人对 Serverless 表达了自己的想法：Serverless 可能是继容器之后的未来，可以预见 Serverless 将不断扩大影响力；重塑软件的构建方式。而到了 2018 年，Serverless 的发展速度要比想象中的更加快速，国内外云厂商不断发力推出新技术，同年 CNCF 也正式发布了 Serverless 领域的白皮书：CNCF Serverless Whitepaper V1.0，阐明 Serverless 技术概况、生态系统状态，为 CNCF 的下一步动作做指导。同时 CloudEvnent 规范，进入 CNCF Sandbox。在这一年，UC Berkeley 发文 Serverless Computing: One Step Forward, Two Steps Back，表达了对 Serverless 的担忧和挑战，作者认为 Serverless 会对开源服务创新有所阻塞。其实，任何一个新的技术、概念出现都会遇到一定的挑战和担忧，就如同当年云计算出现时，也被一些人认为只是又一个商业炒作的概念，当然事实也证明，任何一个新的事物，只有在经历各种挑战和质疑之后，才能更茁壮地成长。从 2019 年开始，Serverless 进入到了一个真正意义上的生产应用，最佳实践快速发展阶段，这一年对 Serverless 而言是具有里程碑式意义的，被很多人定义为 “Serverless 正式发展的元年”。在这一年不仅有 KubeCon 在中国上海的 CloudNativeCon 中关于 Serverless 的 “海量主题演讲”，更有 UC Berkeley 最新的文章，Cloud Programming Simplified: A Berkeley View on Serverless Computing。在这篇文章中，经历了一年的发展，UC Berkeley 的学者们也从一年前的质疑，悲观转变成了自信与期待，并这篇文章中犀利断言 Serverless 将会在接下来的十年被采用并得到飞速的发展，认为 Serverless 将引领云计算的下一个十年，并且重点阐述了以下新观点：1、新的 BaaS 存储服务会被发明，以扩展在 Serverless 计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择。2、比现有的 x86 微处理器更多的异构计算机。3、更加安全、易用的编程，不仅具有高级语言的抽象能力，还有很好的细粒度的隔离性。4、基于 Serverless 计算的价格将低于 Serverful 计算，至少不会高于 Serverful 计算。5、Serverless 将会接入更多的后台支撑服务，如 OLTP 数据库、消息队列服务等。6、Serverless 计算一旦取得技术上的突破，将会导致 Serverful 服务的下滑。7、Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，因此也意味着服务器 - 客户端模式的终结。可以看到，从 IaaS 到 FaaS 再到 SaaS，再到如今的 Serverless，云计算的发展在近十余年中发生了翻天覆地的变化，相信随着 5G 时代的到来，Serverless 将会在更多领域发挥至关重要的作用。

1.1.5 生态工具除Serverless Framework之外，Serverless Devs同样是无厂商锁定的多云开发者工具。目前按照Serverless Devs的官方仓库显示，其已经支持AWS Lambda，阿里云函数计算，腾讯云云函数，华为云Serverless工作流以及百度智能云函数计算等产品。与Serverless Framework不同的是，Serverless Devs主打的是Serverless应用全生命周期管理工具。如下图所示，以阿里云函数计算为例，Serverless Devs可以支持包括脚手架、调试、发布、运维等多个流程多种功能：另外值得一提的是，Serverless Devs不仅支持拥有完善的工具链产品，其在2021年还对外正式发布Serverless Devs Model（Serverless开发者工具模型：SDM）：通过Serverless Devs，开发者同样可以非常简单快速的使用各个厂商/平台的Serverless产品，以阿里云函数计算为例：# 安装 npm install -g @serverless-devs/s # 配置密钥 s config add --AccessKeyID AccessKeyID --AccessKeySecret AccessKeySecret # 创建一个项目 s init node.js12-http -d fc-hello-world-demo # 进入项目 cd fc-hello-world-demo # 部署项目 s deploy开发框架在传统架构下，开发者想要进行业务开发有着诸多的开发者个框架可供选择，以Web框架为例，Node.js语言类的有Expree.js，Nuxt.js，Egg.js等，Python语言类的有Django，Flask等，Java类的也有SpringBoot等，但是随着Serverless架构的不断发展，传统框架迁移到Serverless是一种解决Serverless应用开发者框架匮乏的方案之一，但是实际上这些框架并不是针对Serverles是架构设计的，很有可能有诸多的优秀特性丧失，例如某些框架的异步处理能力，尽管Serverless平台都已经提供了异步触发能力，但是框架本身的异步处理能力在Serverless架构下就很难被利用起来，所以针对Serverless架构所设计的Serverless First框架，就显得尤为重要。目前在社区生态中，有诸多优秀的Serverless应用层面的开发者框架，例如基于原有 Midway 的 IoC 体系设计，复用原有装饰器和解耦能力的同时，将代码分解到不同的函数中，并发布到各个云平台的Midway Serverless；基于 TypeScript 的 Serverless First、组件化、平台无关的渐进式应用框架Malagu等。以Midway Serverless为例，Midway Serverless 是用于构建 Node.js 云函数的 Serverless 框架，帮助开发者在云原生时代大幅降低维护成本，更专注于产品研发。Midway Serverless拥有诸多优点，例如：跨云厂商：一份代码可在多个云平台间快速部署，不用担心产品会被云厂商所绑定。云端一体化：提供了多套和社区前端 React、Vue 等融合一体化开发的方案。代码复用：通过框架的依赖注入能力，让每一部分逻辑单元都天然可复用，可以快速方便地组合以生成复杂的应用。传统迁移：通过框架的运行时扩展能力，让 Egg.js 、Koa、Express.js 等传统应用无缝迁移至各云厂商的云函数通过该框架，开发者可以快速构建的全栈应用，也可以发布的函数服务，Restful 接口等，也可以加上前端（react，vue）代码构建中后台项目，也可以使用 Midway 提供的方案迁移传统的 Egg/Koa/Express 应用上弹性容器等。以全栈应用为例：# 安装 npm i @midwayjs/faas-cli -g # 创建一个项目 f create --template-package=@midwayjs-examples/midway-hooks-react # 部署项目 f deploy除Midway Serverless之外，Malagu也是一款社区驱动的Serverless First框架。Malagu 是基于 TypeScript 的 Serverless First、组件化、平台无关的渐进式应用框架，又叫 M 框架。使用同一套编程语言和 IoC 设计，用于开发前端、后端和前后端一体化应用。并且结合了 OOP（面向对象编程）、AOP（面向切面编程）等元素，借鉴了很多 Spring Boot 设计思想。在后端，Malagu 抽象一套接口，方便适配任意的平台和基础框架，是一个平台或基础框架无关的上层框架。平台如阿里云函数计算、腾讯云云函数、AWS Lambda、Vercel 等，基础框架如 Express、Koa、Fastify 等。与大部分传统开发框架不同的是，Malagu 是一个全栈应用开发框架，如果只看后端部分，Malagu 与 Spring Boot 是同一层次的东西，如果只看前端部分，Malagu 是 React、Vue 等前端框架之上的更上层的抽象，所以 Malagu 是前端框架无关的。Malagu 与传统框架比较，Malagu 提供了前后端渐进式一体化方案，在前后端之上做了一层抽象，让前后端在开发、测试、部署拥有一致的体验。传统框架一般不考虑应用部署环节，Malagu 借助 Serverless 技术优势，让部署环节变得流畅且低成本。另外，Malagu 也是一个 Serverless 优先的框架，屏蔽了 Serverless 底层的细节，开箱即用。针对 Serverless 场景做了很多优化，如冷启动、数据库操作等等；同时，也提供了很多开箱即用的能力，比如安全、认证与授权、OAuth2.0、OIDC、数据库操作、缓存、前端框架集成、依赖注入、AOP、微服务等。

1.1.4 生态发展Serverless架构的发展，离不开云厂商的驱动，离不开开源社区的支持，在过去的几年时间，无论是高校、实验室、云厂商等对Serverless架构的研究，还是CNCF等基金会对Serverless架构的持续关注和赋能，还是其他的Serverless社区、开源项目对Serverless架构的建设，Serverless架构都在逐渐的成为更通用，更好用的技术架构，都在成为更简单、更具价值的技术选型。学术建设Serverless架构从诞生到今天，正在逐渐的被更多人所关注，包括学术界也逐渐有越来越多的人，将目光投向Serverless架构，助力Serverless领域快速腾飞。这一部分，将会通过部分论文对Serverless架构在学术界的建设进行初步的分析和探索。2018年，Serverless的发展速度要比想象中的更加快速，这一年UC Berkeley发文《Serverless Computing: One Step Forward, Two Steps Back》，表达了对Serverless架构的担忧和挑战，在这篇文章中，作者认为“通过提供自动缩放功能，今天的FaaS产品在云编程方面迈出了一大步，它提供了一种实际上可管理的，看似无限的计算平台。但是，他们忽略了高效数据处理的重要性；其次，它们阻碍了分布式系统的开发”。任何一个新的技术、概念出现都会遇到一定的挑战和担忧，就如同当年云计算出现时，也被一些人（如Oracle公司总裁Larry Ellison、GNU发起人Richard Stallman）认为只是又一个商业炒作的概念，毫无新意，甚至蠢不可及。当然，事实也证明，任何一个新的事物，都只有在经历各种挑战和质疑之后，才能更茁壮的成长，Serverless也不例外。2019年，时隔一年，UC Berkeley针对Serverless架构再次发文《Cloud Programming Simplified: A Berkeley View on Serverless Computing》，在这篇文章中，作者犀利断言Serverless 将会在接下来十年被迅速采用，获得飞速发展，并对Serverless架构进行了更为激进的断言：Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，这也意味着服务器 - 客户端模式的终结，Serverless架构将会引领云计算的下一个十年。在学术界，不仅仅UC Berkeley 对Serverless发表过多篇论文，很多国内外高校都在Serverless领域投入了足够的精力进行科研探索。就目前来看， Serverless 已经成为学术界的研究热点，每年Serverless架构相关的论文都有比较明显的增长趋势：（该图片来自掘金社区）而到了2021年，Serverless架构在学术界的论文数量不仅仅再次上升，其研究内容和方向也是越发的完善和全面，其中包括不限于冷启动优化、镜像加速、调度策略、缓存机制等诸多热点问题。以阿里云函数计算团队和美国George Mason University Leap Lab合作发表在顶会USENIX ATC (USENIX Annual Technical Conference) 的论文《FaaSNet: Scalable and Fast Provisioning of Custom Serverless Container Runtimes at Alibaba Cloud Function Compute》为例，在文章中就针对容器镜像生态与Serverless架构结合之后的问题“镜像拉取与冷启动优化”问题进行了更为深入的探索，在加速镜像的分发速度方面，常见的业界成熟的 P2P 方案没有做到 function 级别的感知，并且集群内的拓扑逻辑大多为全连接的网络模式，对机器的性能提出了一定需求，这些前置设定不适配 FC ECS 的系统实现，为此设计并提出了一个具有高伸缩性的轻量级系统中间件FaaSNet，FaaSNet利用到镜像加速格式进行容器分发，目标作用场景是 FaaS 中突发流量下的大规模容器镜像启动（函数冷启动），FaaSNet 的核心组件包含 Function Tree (FT)，是一个去中心化的、自平衡的二叉树状拓扑结构，树状拓扑结构中的所有节点全部等价。FaaSNet 可以根据 workload 的动态性实现实时组网已达到 function-awareness，无须做预先的 workload分析与预处理，进而帮助Serverless平台解锁高伸缩性和快速的镜像分发速度技术瓶颈，赋能自定义容器镜像场景的更为深入和广泛的应用。除此之外，作为云计算领域的顶级会议SoCC，在2021年接收的论文中，也可以看到诸多Serverless架构的影子，例如以Microsoft Azure Functions作为实验平台的论文《FaaT:ATransparentAuto−ScalingCacheforServerlessApplications》，针对Serverless架构中函数stateless的特点，针对FaaS平台的Cache问题，提出了一种用于Serverless应用程序的自动伸缩分布式缓存FaaT: A Transparent Auto-Scaling Cache for Serverless Applications》，针对Serverless架构中函数 stateless 的特点，针对FaaS平台的Cache问题，提出了一种用于Serverless应用程序的自动伸缩分布式缓存FaaT:ATransparentAuto−ScalingCacheforServerlessApplications》，针对Serverless架构中函数stateless的特点，针对FaaS平台的Cache问题，提出了一种用于Serverless应用程序的自动伸缩分布式缓存FaaT，可以大幅度提升 Serverless 函数的性能，与已有的通过外部存储作为 Cache 系统的方法相比，Faa$T可以降低绝大多数的开销。另一篇文章《ServerMore: Opportunistic Execution of Serverless Functions in the Cloud》针对Serverless函数短执行时间与低资源需求的特点，介绍了一种服务器级资源管理器ServerMore，可将Serverless 函数与 Serverful 的虚拟机调度在同一台物理机上执行任务，ServerMore 动态调节服务器上的 CPU、内存带宽和 LLC 资源，以确保 Serverful 和 Serverless 工作负载之间的托管不会影响应用程序tail latencies。通过选择性地使用Serverless架构并推断相对黑盒的Serverful工作负载的性能，ServerMore 与之前的模式相比，平均提高了 35.9% 到 245% 的资源利用率；同时对 Serverful 应用程序和 Serverless 架构的延迟影响最小。Serverless架构的学术研究日渐火热，各领域的顶会也出现了诸多优秀的Serverless架构相关论文，这不仅有助于Serverless学术生态的繁荣，也非常有助于突破Serverless架构的技术瓶颈，实现云计算领域技术架构升级。除此之外，近年来国内的Serverless图书专著也逐渐多了起来，仅仅2021年一年的时间就先后有包括《前端Serverless：面向全栈的无服务器架构实战》、《Serverless从入门到进阶：架构、原理与实践》、《Serverless工程实践：从入门到进阶》、《华为Serverless核心技术与实践》等在内的图书被出版，大大丰富了国内的Serverless培训与教育的资料生态。随着时间的发展，Serverless架构在更多领域发挥着越来越重要的作用，在被更多人关注的同时，Serverless架构也逐渐的成为了诸多学者、实验室的研究对象，如何将学术和工业进行有机结合，如何通过工业赋能学术届的科研，通过学术届的科研赋能工业界技术架构的迭代升级，赋能整个行业的前进，这不仅仅是Serverless架构需要做的，也是如今的Serverless架构正在做的。工具链建设Serverless 正在改变未来软件开发的模式和流程，并被预测将引领云计算的下一个 10 年，但尽管如此，开发者在选择使用 Serverless 时仍有诸多担忧，这其中最受关注的无疑就是工具链体系的匮乏。所谓的工具链匮乏，一方面表现在市面上工具链不完善，这导致开发和部署难度大，进而增加成本；另一方面表现在，缺乏相关的工具链在体验层将 Serverless 体验进一步规范，优质工具链的匮乏导致本来就担心被厂商绑定的 Serverless 开发者变得更难与厂商解绑。2020年 10月，中国信息通信研究院发布国内首个《云原生用户调查报告》明确指出在使用 Serverless 架构之前，49% 的用户考虑部署成本，26% 的用户考虑厂商绑定情况，24% 的用户考虑相关工具集完善程度，这些数据背后透露的实际上是：开发者对于完善工具链的强烈需求。尽管，有一些开发者认为入门Serverless架构，通过白屏化的操作相对来说会更容易入门，在一定程度上通过各个云厂商的控制台进行函数的创建、更新也会更为方便。但是不可否定的是，Serverless开发者工具在一定程度上却有着更为重要的价值和作用：通过脚手架，快速创建Serverless架构的应用；在开发过程中，通过开发者工具进行应用的调试等；在开发完成之后，通过开发者工具将应用（可能包括多个函数以及相对应的BaaS类产品）一键部署到线上；项目运维阶段，通过开发者工具进行项目的可观测以及问题定位等；若需要实现科学部署，通过某些CI/CD平台/工具发布Serverless架构的应用，通常是离不开开发者工具的;目前Serverless领域，工具链建设分为两类：云厂商/Serverless框架所提供的针对自身的开发者工具，例如AWS的SAM CLI，阿里云的Funcraft，OpenWhisk的Ask等；由第三方提供的多云开发者框架（包括不限于开源社区驱动），例如Serverless Framework项目，Serverless Devs项目等；通过Serverless开发者工具，开发者可以非常简单的学习和使用Serverless架构，也可以在生产的过程中快速的使用这些工具进行开发效能的提升。以Serverless Framework为例，作为拥有近4万Star的海外老牌Serverless工具链开源项目，目前Serverless.com的官方网站支持11个常见的Serverless平台产品：可以通过Serverless Framework开发者工具，以AWS Lambda为例进行实践，可以通过几行命令快速体验AWS Lambda：# 安装 npm install -g serverless # 配置密钥 serverless config credentials --provider aws --key key--secret secret # 创建一个项目 serverless create --template aws-python3 --path my-service # 进入项目 cd my-service # 部署项目 serverless deploy -v除了对项目的部署和发布操作之外，Serverless Framework还支持项目的删除，回滚等更多的操作，以常见的部分云厂商和开源项目为例，Serverless Framework的常见能力表如下：

1.1.3 工作原理作为云时代新的计算范式，Serverless架构本身属于一种天然的分布式架构，其工作原理与传统架构虽没有翻天覆地的变化，但也是有细微的不同。如下图所示，传统架构下，开发者开发完成应用之后，还需要购买虚拟机服务，初始运行环境，安装需要的软件（例如MySQL等数据库软件，Nginx等服务器软件等），完成环境的准备之后，还需要上传开发好的业务代码，启动该应用，此时用户才可以通过网络请求，成功的访问到目标应用。此时，如果应用的请求量过大或者过小时，开发者或运维人员，还需要针对实际的请求数量进行相关资源的扩充或缩容，并在负载均衡&反向代理模块增加相对应的策略，以确保扩缩容操作的及时生效，当然，在做这些操作的时候还要保证线上用户不会受到影响。而在Serverless架构下，整个应用发布的过程和工作的原理，将会发生一定的变化：如上图所示，当开发者开发完整业务代码之后，只需要部署或更新到对应的FaaS平台即可，完成之后根据真实的业务需求，进行相关的触发器配置，例如为了对外提供Web应用服务，可以配置HTTP触发器等，此时用户就可以通过网络，访问到开发者所发布的应用。在这个过程中，开发者不需要再额外关注服务器的购买，运维等相关的操作，也无需对一些软件的安装，应用资源的扩缩容进行额外的精力支出，开发者所需要关注的仅仅是自身的业务逻辑，至于在传统架构下需要安装配的各种服务器软件等，均变成配置项交给云厂商来管理，同样，传统架构下需要根据服务器的利用进行资源的扩缩行为，也全都自动化的交给云厂商来实现。在整个Serverless工作的流程中，不难发现FaaS平台实际上会作为计算资源，承载着诸多核心能力，包括不限于执行开发者的业务代码，自动进行资源的扩缩等操作，那么Serverless架构中的FaaS平台是什么样子的呢？通常情况下一个简化的Faas系统分为APIServer，Scheduler，ResourceManager，NodeService，ContainerService一共有5个组件。如上图所示：APIServer往往对外暴露整体能力的API服务，例如invokeFunction的功能等；Scheduler模块用于管理系统的Container，例如APIServer通过Scheduler获得可以执行Function的Container；ResourceManager模块用来管理系统里的Node，负责申请和释放，可以认为Node对应于虚拟机，占用虚拟机需要一定的成本，因此Scheduler的一个目标是如何最大化的利用Node，比如尽量创建足够多的Container，不用的Node应该尽快释放。当然申请和释放Node又需要一定的时间，造成延迟增加，Scheduler需要平衡延迟和资源使用时间；NodeService管理单个Node上创建和销毁Container，Node可以认为是一个虚拟机，Scheduler可以在Node上创建用于执行Function的Container；ContainerService用于执行函数；正是这些组件或者模块的联动，才得以让FaaS平台可以为应用提供更为稳定、安全，性能更高的技术支持；对FaaS平台的组成结构有了初步了解之后，可以进一步探索一下FaaS平台的工作流程。如上图所示，当开发者把代码和配置交付到FaaS平台之后，FaaS平台并不会按照用户的预定配置进行资源的分配，而是会将这一部分的内容进行持久化。只有请求到来时，FaaS平台才会根据真实流量进行资源的分配。从FaaS平台接受到函数调用或者被触发的请求时，到函数正式执行并反馈最终结果，粗略的可以认为是两个过程。容器&Runtime准备阶段：这个阶段主要是进行相关的资源准备，例如某些计算资源的准备，某些网络资源的准备等，准备好这些资源之后，系统会根据用户的函数进行相对应的代码的下载，然后在进行实例的启动；这个过程通常也可以认为是冷启动的过程；函数执行阶段：函数执行阶段指的是实例启动之后，函数代码进行初始化以及指定方法执行的过程。当然，在某些开发者眼中，或者某些平台的定义中，代码初始化的过程往往也会被算作是资源准备阶段；当函数执行完成之后，返回了结果之后，就意味着本次触发已经完成。此时函启动的实例通常会有三种处理方案：实例会被搁置一段时间，如果搁置的这段时间内，没有被分配处理新的触发请求，实例会被释放掉；实例会被搁置一段时间，但是在搁置的这段时间内，被分配处理新的触发请求，此时实例会处理新的触发请求；实例由于一些特殊的配置，被标记为长期活跃实例，即使被搁置很久（超过释放的时间阈值）也不会被释放；通过上面所表述的三种处理方法，不难发现实例是可能存在被复用的情况，所以函数在被触发的时候，通常也可能会有两种可能：当前时间段，并没有已经准备好且可以被利用的实例（例如函数的首次调用/触发），此时FaaS平台会全新启动实例，包括容器&Runtime准备以及函数执行等；当前阶段，有已经准备好且可以被利用的实例（例如上述函数执行完成的三种情况中的2，3情况），此时FaaS平台会优先复用已存在的实例，以避免再次进行容器&Runtime准备而浪费时间，提升请求效率，降低请求时延；由此也可见，Serverless架构之所以被认为是天然分布式架构，其原因是Serverless架构的模型实现，是请求级别的隔离，可以认为每次请求都可能会出现一个实例（部分厂商提供的单实例多病发的情况除外），即同一时间段的请求数量会和实例数量成正相关。除此之外，还值得注意的是，Serverless应用是由事件驱动的，即FaaS平台中的函数是由事件触发的，事件的产生者按照某些规范描述不同的事件，并以参数的形式在调用函数指定方法时，传递给函数。所以事件生态也是影响Serverless架构应用领域、应用场景的重要影响因素。如上图所示，按照CNCF白皮书中的规范，FaaS平台可以根据不同的用例从不同的事件源调用函数，例如：同步请求（Req / Rep），例如HTTP请求，gRPC调用客户发出请求并等待立即响应。异步消息队列请求（发布/订阅），例如RabbitMQ，AWS SNS，MQTT，电子邮件，对象（S3）更改，计划事件（如CRON作业）消息发布到交换机并分发给订阅者；没有严格的消息排序，以单次处理为粒度。消息/记录流：例如Kafka，AWS Kinesis，AWS DynamoDB Streams，数据库CDC一组有序的消息/记录（必须按顺序处理）；通常，每个分片使用单个工作程序（分片消费者）将流分片为多个分区/分片；可以从消息，数据库更新（日志）或文件（例如CSV，Json，Parquet）生成流；事件可以推送到函数运行时或由函数运行时拉动。批量作业，例如ETL作业，分布式机器学习，HPC模拟作业被调度或提交到队列，并在运行时使用并行的多个函数实例进行处理，每个函数实例处理工作集的一个或多个部分（任务）当所有并行工作程序成功完成所有计算任务时，作业完成综上所述，将Serverless架构工作原理用一张图完整表示，可参考下图：

1.1.2 概念定义云计算飞速发展的十余年，整个互联网也发生了翻天覆地的变化，作为被UC Berkeley认为是云计算下一个十年的Serverless架构，被很多开发者认为是“实现了云计算最初的梦想”，那么Serverless架构到底是什么呢？其实，Serverless架构与云计算、云原生的情况类似：Serverless架构到底是什么，在不同的人心中也是有着不同的答案的。如上图所示，从目前的认可度来看，Serverless架构可以从狭义与广义两个角度进行探索与分析：从狭义上来看，Serverless架构是FaaS与BaaS的结合；从广义上来看，Serverless架构表示的是服务端免运维的一种形式，一种思想；狭义定义Martin Fowler在Serverless Architectures一文中认为Serverless实际上是BaaS与FaaS的组合，而这一说法也是被最为广泛认可的一种说法。所谓BaaS，就是Backend as a Service（后端即服务），指的是服务商为客户(开发者)提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用；所谓FaaS，指的是Function as a service（函数即服务），即服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性，典型的产品包括AWS的Lambda，阿里云的函数计算（FC），腾讯云的云函数（SCF）等。除此之外，CNCF在CNCF WG-Serverless Whitepaper v1.0中也对什么是Serverless架构进行了进一步的描述，CNCF认为：“Serverless是指构建和运行不需要服务器管理的应用程序概念。它描述了一种更细粒度的部署模型，其中将应用程序打包为一个或多个功能，上传到平台，然后执行、扩展和计费，以响应当时确切的需求”。同时CNCF在白皮书中也强调了：Serverless所谓的“无服务器”并不是“没有服务器”，而是说Serverless的用户不再需要在服务器配置、维护、更新、扩展和容量规划上花费时间和资源，将更多的精力关注到业务逻辑本身，至于服务器，则“把更专业的事情交给更专业的人”去做，即由云厂商来提供统一的运维。在2019年UC Berkeley的文章Cloud Programming Simplified: A Berkeley View on Serverless Computing中，作者对Serverless架构的定义进行了进一步的完善和表达，首先作者肯定了Serverless架构是FaaS与BaaS的结合，除此之外，作者认为：在对于被认为是Serverless的服务，它必须具备弹性伸缩和按量付费的特点。广义定义云计算的发展是飞速的，Serverless架构也在不断迭代升级，不断的进行演进，在随着时间发展的过程中，很多人逐渐发现了Serverless架构不应该是狭义的认为是FaaS与BaaS的结合，而是需要进一步泛华，即符合服务端免运维的这种架构，就可以认为是Serverless架构。在信通院云原生产业联盟所发布的《云原生发展白皮书（2020年）》中对Serverless是什么有这样的一段描述：无服务器（即Serverless）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。这种架构体系结构消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。可以看到，Serverless架构一面可以精确的定义成是FaaS与BaaS的结合，另一面则可以广义的看成是一种思想：一种具备弹性伸缩和按量付费特性的架构思想；一种服务端免运维或者低运维的思想；于是广义的Serverless产品，就逐渐的逐渐如雨后春笋般发展起来，以应用托管的Serverless产品或服务为例，就有阿里云的Serverless应用引擎，Google的CloudRun等。综上所述，或许在2019年的时候，UC Berkeley的文章中或认为某些形态的Serverless产品或者服务，“违背了Serverless精神”，但是事实上，不可否定的是，随着技术的迭代升级，随着用户需求的不断驱动，技术的发展会逐渐的更为泛化。事实也证明，如今广义的Serverless架构概念，已经被更多人更多的厂商逐渐的接受和认可，Serverless架构的形态和未来的机会，也在不断的发生改变。

从IaaS到FaaS再到SaaS，再到Serverless，云计算的发展在近十余年中发生了翻天覆地的变化，从虚拟空间到云主机，从自建数据库等业务到云数据库等服务，云计算的发展是迅速的，Serverless架构也被诸多人寄予厚望，或许Serverless架构正当时，其已然开启从概念到实践的大规模落地之路，正如 Gartner 报告中的预测，到 2025 年，全球一半的企业将采用 FaaS 部署；或许，时至今日的Serverless架构，依旧不是最终形态的的Serverless架构；或许Serverless的精神也需要进一步的建设和完善，但是不可否定的是，Serverless架构都正在：More and more energetic, more and more fast and powerful.Serverless架构迅速发展的过程，其实也映射着云计算领域前进的方向，本节将会通过对Serverless架构的发展历程介绍、概念规范进行探索以及工作原理的研究，生态发展的分析，对Serverless架构进行基础的学习和了解。1.1.1 发展历程自1961年约翰·麦卡锡（1971年图灵奖获得者）在麻省理工学院百周年纪念典礼上第一次提出了“Utility Computing”概念：“计算机在未来，将变成一种公共资源，会像生活中的水、电、煤气一样，被每一个人使用”，云计算的“最初的”，“超前的”遐想模型，就逐步的诞生；经历过1984年，SUN公司联合创始人John Gage（约翰·盖奇）提出“网络就是计算机（The Network is the Computer）”的重要猜想，用于描述分布式计算技术带来的新世界，到1996年，康柏（Compaq）公司的一群技术主管在讨论计算业务的发展时，首次使用了Cloud Computing这个词，并认为商业计算会向Cloud Computing的方向转移。这也是“云计算”从雏形到正式被提出的基本过程。伴随着云计算概念的逐渐完善，云计算的技术也逐渐的完善起来，2003年到2006年间，谷歌发表了The Google File System、MapReduce: Simplified Data Processing on Large Clusters 、Bigtable: A Distributed Storage System for Structured Data等论文，这些论文指明了HDFS（分布式文件系统），MapReduce（并行计算）和Hbase（分布式数据库）的技术基础以及未来机会，至此奠定了云计算的发展方向；随着云计算的飞速发展，因云而生的产品，技术也越来越多，于是Pivotal公司的Matt Stine在2013年首次提出云原生（CloudNative）的概念；随后的2015年云原生计算基金会（CNCF）成立，并为最初的云原生定义范围：容器化封装、自动化管理、面向微服务；到了2018年，CNCF更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。直到今天，如图所示，云原生的战略版图越来越宏伟，覆盖的产品越来越多，覆盖的领域也越来越完整。有人说，因云而生的软件、硬件、架构，就是真正的云原生；因云而生的技术，就是云原生技术。确实如此，出生于云，成长在云，因云而生，或许就是真正意义上的云原生。在云原生技术发展前后，云计算领域又有一个新的概念诞生，那就是Serverless架构，一个主张降本提效的技术范式，一个主张业务聚焦，把更专业的事情交给更专业的人，开发者可以付出更多精力在自身的业务逻辑上的技术架构。2012年，Iron.io的副总裁Ken Form在文章Why The Future of Software and Apps is Serverless中，提出了一个新的观点：“即使云计算的已经逐渐的兴起，但是大家仍然在围绕着服务器转。不过，这不会持续太久， 云应用正在朝着无服务器方向发展，这将对应用程序的创建和分发产生重大影响”。并首次将“Serverless”这个词带进了大众的视野。2014年Amazon发布了AWS Lambda让“Serverless”这一范式提高到一个全新的层面，为云中运行的应用程序提供了一种全新的系统体系结构，至此再也不需要在服务器上持续运行进程以等待HTTP请求或API调用，而是可以通过某种事件机制触发代码执行，通常这只需要在AWS的某台服务器上配置一个简单的功能。2015年，在AWS的re:Invent大会上，Serverless的这个概念更是反复地出现，其中包括了The Serverless Company Using AWS Lambda和JAWS：The Monstrously Scalable Serverless Framework的这些演讲。随着Serverless这个概念的进一步发酵；此外，Ant Stanley 在2015年7月名为Server are Dead…的文章中更是围绕着AWS Lambda及刚刚发布的AWS API Gateway这两个服务解释了他心目中的Serverless，并说Servers are dead … they just don't know it yet.2016年10月在伦敦举办了第一届的ServerlessConf，在两天时间里面，来自全世界40多位演讲嘉宾为开发者分享了关于这个领域进展，并且对未来进行了展望，提出来了Serverless的发展机会以及所面临的挑战，这场大会是针对Serverless领域的第一场具有较大规模的会议，在Serverless的发展史上具有里程碑的意义。2017年，各大云厂商基本上都已经在Serverless进行了基础的布局，尤其是国内的几大云厂商，也都先后在这一年迈入“Serverless时代”。同年，CNCF Serverless WG成立了，并且开始以社区的力量推动Serverless快速前行，包括CNCF Serverless Whitepaper、CloudEvents等相关的立项研究与探索，2017年年末，eWEEK的Chris J. Preimesberger发表文章Predictions 2018: Why Serverless Processing May Be Wave of the Future来表达在“全新的阶段下”大家对Serverless的看法和期盼。2018年，Serverless的发展速度要比想象中的更加快速，在这一年，Google 发布了 Knative， 一个基于 Kubernetes 的开源 Serverless 框架，具备构建容器、流量调配、弹性伸缩、零实例、函数事件等能力。AWS 发布了 Firecracker，一个开源的虚拟化技术，面向基于函数的服务，创建和管控安全的、多租户的容器。Firecracker 的目标是把传统虚拟机安全性和隔离性，和容器的诉求，资源效率结合起来。在这一年，CNCF也正式发布了Serverless领域的白皮书：CNCF Serverless Whitepaper V1.0，阐明Serverless技术概况、生态系统状态，为 CNCF 的下一步动作做指导，同时CloudEvnent规范，进入CNCF Sandbox；同样在2018年，全球知名IT咨询调研机构Gartner发布报告，将Serverless Computing列为十大未来将影响基础设施和运维的技术趋势之一。2019年开始，Serverless进入到了一个真正意义上的生产应用，最佳实践快速发展阶段而2019年对Serverless而言是非常关键的一年，也是Serverless具有里程碑式发展的一年，被很多人定义为“Serverless正式发展的元年”。在这一年不仅有KubeCon在中国上海的CloudNativeCon中关于Serverless的“海量主题演讲”，这些演讲包括来自Captial One银行的Kevin Hoffman的WebAssembly、无服务器和云，IBM的Doug Davis的CNCF CloudEvents项目：迈向无服务器互操作的一步等；同年，UC Berkeley在论文Cloud Programming Simplified: A Berkeley View on Serverless Computing表示“Serverless 计算将会成为云时代默认的计算范式”。2020年，CNCF 发布了2020年度中国云原生调查报告，在报告中明确显示Serverless 正在持续增长，31% 的单位在生产中使用无服务器，41% 在评估，12% 计划在未来12个月使用；同年，Flexera 2020年云状况报告称，Serverless是2020年增长最快的五项PaaS云服务之一；与此同时，Forrester 认为，Serverless 计算的兴起，让 FaaS（Function As A Service）成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供方式。预计 2021 年，将会有大量主流企业的核心应用，从原来的主机架构迁移到 Serverless。随着时间的发展，Serverless架构逐渐从2021年，Serverless架构在权威咨询机构 Forrester 发布的The Forrester Wave™: Function-As-A-Service Platforms, Q1 2021中，开始了新一年的蓬勃发展，在这个报告中，不仅对全球主流的Serverless平台，进行了相对应的评测，对过去的技术发展进行了更为科学的总结，同样也对未来的规划、产品的发展视野进行了展望和探索，作为未来十年云计算的重要趋势之一，Serverless架构已经展示出不俗的潜力。Forrester 认为，Serverless 计算的兴起，让 FaaS（Function As A Service）成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供方式。预计 2021 年，将会有大量主流企业的核心应用，从原来的主机架构迁移到 Serverless。至此，云计算的发展逐渐从IaaS，到PaaS，向Serverless架构升级过渡，同样，Serverless架构也逐渐的从鲜为人知，开始走进寻常百姓家。从2012年，Serverless概念被正式提出之后，2014年AWS带领Lambda开启了Serverless的商业化，再到2017年各大厂商纷纷布局Serverless领域，再到2019年，Serverless成为热点议题在KubeCon中被众多人参与探讨，UC Berkeley发文断言Serverless将引领云计算的下一个十年，Serverless随着时间的不断推进，各种技术部的不断进步，正在逐渐地朝着更完整，更清晰的方向发展，随着5G时代的到来，Serverless将会在更多领域发挥至关重要的作用。

最开始其实还是有点忐忑的 但是跟着实验指导书一起发现实验并不难，并且学到了不少东西​在这里已经将index.js文件复制到了对应的窗口中，一定要注意不要复制错误了在点击测试之后，返回到日志即可查看情况，一定要刷新一下，不然可能看不了这是最后完成了，查看网页的界面，还是有点小成就感的