作者：陈耿
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
深入浅出Serverless：技术原理与应用实践试读：
前言
容器技术是这几年IT界的热门话题，各行各业都在研究如何通过容器提升企业软件开发、交付和管理的效率。Docker和Kubernetes的成功使得仅凭几个人也可以轻易管理一个包含上千台机器的庞大的计算集群，并且在这个庞大的集群上部署各种各样的应用。云计算催生了容器技术，而容器技术也改变了云计算。凭借在Linux和开源社区的先天优势，这几年Red Hat在容器这一领域风光无限。我在Red Hat参与了各种类型的容器项目，见证了客户使用容器平台满足其各种各样的需求。容器技术的应用可谓百花齐放，范围涉及微服务、DevOps到最近的人工智能和深度学习。在当前容器技术如此火热之际，我突然想，容器会是云计算的终点吗？答案当然是否定的。如果容器不是终点，那么什么东西会成为容器之后的又一个技术热点呢？什么样的技术会让云计算更进一步，让IT及其所服务的各个行业的生产效率更上一层楼呢？
我带着疑问进行了思考和研究。经过一系列调研以及和业界一些朋友的讨论后，我认为Serverless将会是继容器之后又一项改变云计算的技术。回顾云计算发展的历程，从物理机到虚拟机，从虚拟机到容器，业界的关注点其实是一点一点地向上层移动的。通过各种技术手段，我们总是努力降低花费在管理基础设施上的时间和精力，以便将更多的时间放在应用和业务上。因此，过去十多年的云计算的历程，其实是一个“去基础架构”的过程。这个过程让用户可以更快速、更简单、更高效地将想法变成应用，变成在线的服务。
Serverless符合云计算发展的方向，让用户可以将关注点放到具体的业务功能上，而不是底层的计算资源上。Serverless特有的模式存在着潜在的巨大价值。那么，Serverless会取代容器吗？我相信不会。虽然Serverless架构在一些特定的领域会大放异彩，但是容器在未来仍然会是一种重要的应用分发和部署格式。此外容器也将成为许多Serverless平台的基础技术，成为Serverless实现的基石。在未来，Serverless与容器将会有许多结合点。
Serverless还是一个相对较新的技术领域，各种新的观点、技术和开源项目还在不断酝酿和涌现。作为一名架构师，除了要解决企业当下和近期可能面对的问题外，还需要有一定的前瞻性，掌握未来架构可能的选项，才能对未来的架构做出合理决策。作为一名工程师，必须要紧跟技术的脚步，让自己在不断变化的IT洪流中屹立不倒。本书写作的初衷正是为希望了解Serverless领域现状的架构师和技术人员提供指南和参考。本书主要内容
本书是一本介绍Serverless技术的书籍，可以让想了解Serverless的读者快速了解Serverless的概念和原理。此外，书中还用大量的篇幅介绍了当前业界最新的Serverless平台、框架和工具的原理、架构和使用细节，内容涵盖了公有云和私有云的Serverless平台。
全书共分为11章，循序渐进、深入浅出地讲解Serverless相关的知识和技术。
前三章重点介绍Serverless的概念和原理，为读者构建Serverless知识体系打下理论基础。第1章介绍了Serverless的基础知识，让读者了解Serverless的概念及其特点。Serverless的存在不能脱离这个时代，所以第2章详细讨论了Serverless涉及的云计算的各种技术，如微服务、容器和DevOps等，让读者对Serverless的理解更加深入。在理解Serverless的基础上，第3章介绍了业界目前的Serverless的各类平台、工具和框架的实现，让读者对该技术领域的现状有更清晰的认识。
第4章和第5章详细介绍了公有云Serverless平台的技术细节。以AWS Lambda和微软的Azure Functions为例，向读者介绍了当前主流的公有云厂商在Serverless领域的实现。
第6章是容器技术的速成教程。容器技术是当下云计算重要的基础技术，也是许多Serverless平台的实现基础。通过本章读者可以快速了解当下热门的容器技术（Docker和Kubernetes）的原理和基本使用技巧。
第7～10章针对私有云的Serverless计算平台，分别详细介绍了OpenWhisk、Kubeless、Fission及OpenFaaS的系统架构、核心概念以及使用技巧，帮助读者了解各类Serverless平台的技术特点。
第11章针对Serverless技术的落地给出了具体建议，总结了本书对Serverless技术的观点，并对Serverless技术的未来进行了展望。本书亮点
本书是关于Serverless与容器的原创著作。Serverless是当前的一个热门话题，但是大家对Serverless概念并不了解。本书整理了业界当前对Serverless的主流观点，梳理了Serverless技术发展的现状，是一个系统的Serverless指南。
·最新资讯。原创的Serverless著作，为读者呈现业界最新的观点和知识。
·纵览大局。对Serverless的介绍结合了当下云计算的背景，也结合了容器技术。
·细致入微。在介绍原理和观点的同时也讲解了大量Serverless平台的技术细节。
·互动实操。提供了大量可操作的实验步骤，让读者可以动手体验，加深理解。本书读者对象
本书介绍了Serverless架构的概念、原理以及当前公有云和私有云领域的众多Serverless平台的实现，能帮助云计算、容器等领域的软件架构师和技术人员快速了解Serverless这一领域的发展现状，为企业和组织的Serverless技术选型、转型和落地提供参考。此外，本书涵盖了大量关于当前云计算、容器和Serverless领域的观点和话题，因此，也适合作为技术爱好者开阔眼界、增长见闻的指南。如何阅读本书
如果读者是初次接触Serverless的相关知识，推荐按顺序阅读本书的各个章节。通过本书既定的章节顺序，可以循序渐进地了解Serverless的相关原理和实现。如果读者对Serverless领域已有一定的研究，则可以按需直接阅读感兴趣的章节。
本书引入了大量与Serverless、云计算、容器和开源软件相关的话题，并针对相关话题给出了相应的参考资料。笔者希望本书是读者研究Serverless和云计算相关技术的一张地图，希望通过本书帮助读者找到更多对自身有价值的开源项目和技术。关于勘误
本书花费了编辑和笔者大量的时间和精力，书中的文字和图表都经过细心斟酌和校对，所有示例的命令和代码都经过笔者亲自验证。但是由于水平有限，且时间仓促，书中难免存在一些瑕疵和需要改进的地方，欢迎读者将对本书的意见和建议发送至笔者的邮箱（nicosoftware@msn.com）进行交流讨论。读者也可以关注笔者的微信公众号“云来有道”，获取关于本书最新的信息和勘误。致谢
本书的出版得到了许多朋友的帮助。衷心感谢机械工业出版社华章公司的杨福川老师和李艺老师对本书的策划和编审。两位编辑老师为本书的出版花费了大量心血。此外，也感谢我的妻子丽金。她是本书的第一位读者，为本书提供了许多有益的建议，并帮助审校了书中的所有文字。本书的创作占用了我大量的业余时间，感谢她的支持和包容。
谨以此书献给我的妻子和两个宝贝。 第1章 Serverless基础
Serverless架构即“无服务器”架构，它是一种全新的架构方式，是云计算时代一种革命性的架构模式。本章将介绍Serverless架构的基本概念和特点。1.1 什么是Serverless
与云计算、容器和人工智能一样，Serverless是这两年IT行业的一个热门词汇，它在各种技术文章和论坛上都有很高的曝光度。但是和其他技术不同，Serverless是一个不太让人能直观理解其含义的概念。按照英文的字面意思直译的话，Serverless的中文翻译为“无服务器”，听起来很神秘，很多技术圈的朋友一时不能理解其内涵。技术圈中的人们一般称呼Serverless为“无服务器架构”。Serverless不是具体的一个编程框架、类库或者工具。简单来说，Serverless是一种软件系统架构思想和方法，它的核心思想是用户无须关注支撑应用服务运行的底层主机。这种架构的思想和方法将对未来软件应用的设计、开发和运营产生深远的影响。提示 在专业领域的文章中，笔者比较不倾向于使用翻译后的专有名词，故本书保留使用Serverless一词。
所谓“无服务器”，并不是说基于Serverless架构的软件应用不需要服务器就可以运行，其指的是用户无须关心软件应用运行涉及的底层服务器的状态、资源（比如CPU、内存、磁盘及网络）及数量。软件应用正常运行所需要的计算资源由底层的云计算平台动态提供。
Serverless的这种模式颠覆了我们传统意义上对软件应用部署和运营的认识。到底Serverless架构和传统的软件架构有什么不同呢？
在传统的场景里，当用户完成了应用开发后，软件应用将被部署到指定的运行环境，这个运行环境一般以服务器的方式体现，可能是物理主机，也可能是虚拟机。根据业务场景的需要，用户会申请一定数量、一定规格（包含一定数量的CPU、内存及存储空间）的服务器以满足该应用的正常运行。当应用上线后，根据实际的运营情况，用户可能会申请更多的服务器资源进行扩容，以应对更高的访问量。在这个场景里面，用户需要关心服务器总体的数量，以运行足够的应用实例；需要关心每台服务器的资源是否充足，是否有足够的CPU和内存；需要关心服务器的状态，因为每台服务器上应用的部署都要花费不少时间和精力。因为用户需要花费大量的时间、精力在服务器这一计算资源的计划、管理和维护上。
在Serverless架构下，情况则截然不同。当用户完成应用开发后，软件应用将被部署到指定的运行环境，这个运行环境不再是具体的一台或多台服务器，而是支持Serverless的云计算平台。当有客户端请求到达或特定事件发生时，云计算平台负责将应用部署到某台Serverless云计算平台的主机中。Serverless云计算平台保证该主机提供应用正常运行所需的计算资源。在访问量升高时，云计算平台动态地增加应用的部署实例。当应用空闲一段时间后，云计算平台自动将应用从主机中卸载，并回收资源。在这个场景中，用户无须关心应用运行在哪一台服务器上，也不用关心具体需要几台服务器。原本花费在计划、管理和维护具体服务器上的时间和精力在Serverless云计算平台的帮助下被省去了。具体的服务器不再是用户关注的焦点，不再是效率提升的障碍。
通过上述两种场景的对比可见，在Serverless架构中并不是不存在服务器，而是服务器对用户而言是透明的，不再是用户所操心的资源对象。
你会发现Serverless的实现和软件应用所在的Serverless云计算平台有着很大的关系。用户之所以不用再关注服务器是因为底层的云计算平台完成了大量的自动化工作。这个云计算平台可以是公有云，如Amazon Web Services（AWS）、Microsoft Azure、阿里云或腾讯云，也可以是私有云，如通过OpenStack、Kubernetes结合一些Serverless框架实现。本书将在后面的章节中对公有云和私有环境里Serverless的实现进行详细的介绍。1.2 Serverless带来的价值
一项技术被广泛认可和采纳的原因往往不是因为这项技术有多新鲜或多酷，最重要的推动力是其能为业务带来巨大的商业或经济价值。Serverless架构为应用开发和运营带来了全新的思维，从多个方面为IT和企业带来价值。1.降低运营复杂度
Serverless架构使软件应用和服务器实现了解耦，服务器不再是用户开发和运营应用的焦点。在应用上线前，用户无须再提前规划服务器的数量和规格。在运维过程中，用户无须再持续监控和维护具体服务器的状态，只需要关心应用的整体状态。应用运营的整体复杂度下降，用户的关注点可以更多地放在软件应用的体验和改进以及其他能带来更高业务价值的地方。2.降低运营成本
服务器不再是用户关注的一个受管资源，运营的复杂度下降，应用运营所需要投入的时间和人力将大大降低。在最好的情况下，可以做到少数几个应用管理员即可管理一个处理海量请求的应用系统。
Serverless的应用是按需执行的。应用只在有请求需要处理或者事件触发时才会被加载运行，在空闲状态下Serverless架构的应用本身并不占用计算资源。在大多数的Serverless公有云服务中，如AWS及Azure，Serverless应用只有处于在线状态下才进行计费，在空闲状态下用户则无须支付费用。对比而言，在传统的架构下，应用被部署到服务器后，无论应用是繁忙还是空闲，应用都将占用其所在的服务器资源。在公有云的场景下，这意味着用户需要支付应用所占用的计算资源，无论应用是否在处理请求。
在Serverless架构下，用户只需要为处理请求的计算资源付费，而无须为应用空闲时段的资源占用付费。这个特点将为大规模使用公有云服务的用户节省一笔可观的开销。在私有环境中，Serverless这种按需执行的模式，可以带来更高的资源利用率。提示 虽然Serverless应用本身在空闲的状态下并不需要支付费用，但是应用所使用到的一些外部服务（如存储和数据库等）仍然可能会产生相关费用。3.缩短产品的上市时间
在Serverless架构下，应用的功能被解构成若干个细颗粒度的无状态函数，功能与功能之间的边界变得更加清晰，功能模块之间的耦合度大大减小。这使得软件应用的开发效率更高，应用开发的迭代周期更短。应用所依赖的服务（如数据库、缓存等）可通过平台直接获取，用户无须关心底层细节，因此应用部署的复杂度降低，部署起来更加容易。应用开发和部署的效率提升，使得用户把头脑中的想法变成现实中的代码，然后将代码变成线上运行的服务的这个过程变得前所未有地快速。相对于传统应用，Serverless架构应用的上市时间（Time To Market，TTM）将大大减少。4.增强创新能力
应用的开发和部署效率的提升，使得用户可以用更短的时间、更少的投入尝试新的想法和创意。通过Serverless的方法快速做出新创意的应用原型，快速投放给用户使用并获取反馈。如果新的想法获得成功，可以进一步快速对其进行完善和扩展。如果想法不成功，失败所消耗的时间和金钱成本相对于传统的软件应用架构方式而言也是较低的。1.3 Serverless的技术实现
作为一种新的思想和方法论，Serverless可以为企业和用户带来巨大的潜在价值，因此在这几年迅速获得了业界的广泛关注。许多企业和用户都在思考如何能落地和实践Serverless这一思想。1.3.1 理念与实现
首先要明确的一点是，Serverless是一种软件的架构理念。它的核心思想是让作为计算资源的服务器不再成为用户所关注的一种资源。其目的是提高应用交付的效率，降低应用运营的工作量和成本。以Serverless的思想作为基础实现的各种框架、工具及平台，是各种Serverless的实现（Implementation）。Serverless不是一个简单的工具或框架。用户不可能简单地通过实施某个产品或工具就能实现Serverless的落地。但是，要实现Serverless架构的落地，需要一些实实在在的工具和框架作为有力的技术支撑和基础。
随着Serverless的日益流行，这几年业界已经出现了多种平台和工具帮助用户进行Serverless架构的转型和落地。目前市场上比较流行的Serverless工具、框架和平台有：
·AWS Lambda，最早被大众所认可的Serverless实现。
·Azure Functions，来自微软公有云的Serverless实现。
·OpenWhisk，Apache社区的开源Serverless框架。
·Kubeless，基于Kubernetes架构实现的开源Serverless框架。
·Fission，Platform9推出的开源Serverless框架。
·OpenFaaS，以容器技术为核心的开源Serverless框架。
·Fn，来自Oracle的开源Serverless框架，由原Iron Functions团队开发。
上面列举的Serverless实现有的是公有云的服务，有的则是框架工具，可以被部署在私有数据中心的私有云中。每个Serverless服务或框架的实现都不尽相同，都有各自的特点。理论联系实际，在后面的章节里，本书将针对关注度较高的Serverless公有云服务（AWS）及私有云Serverless框架（OpenWhisk、Fission及OpenFaaS）进行详细的介绍。1.3.2 FaaS与BaaS
目前业界的各类Serverless实现按功能而言，主要为应用服务提供了两个方面的支持：函数即服务（Function as a Service，FaaS）以及后台即服务（Backend as a Service，BaaS）。Serverless实现的构成如图1-1所示。1.FaaS
FaaS提供了一个计算平台，在这个平台上，应用以一个或多个函数的形式开发、运行和管理。FaaS平台提供了函数式应用的运行环境，一般支持多种主流的编程语言，如Java、PHP及Python等。FaaS可以根据实际的访问量进行应用的自动化动态加载和资源的自动化动态分配。大多数FaaS平台基于事件驱动（Event Driven）的思想，可以根据预定义的事件触发指定的函数应用逻辑。图1-1 Serverless实现的构成
目前业界FaaS平台非常成功的一个代表就是AWS Lambda平台。AWS Lambda是AWS公有云服务的函数式计算平台。通过AWS Lambda，AWS用户可以快速地在AWS公有云上构建基于函数的应用服务。
AWS Lambda主页：https://aws.amazon.com/lambda/。
FaaS是目前Serverless架构实现的一个重要手段。FaaS平台的特点在很大程度上影响了目前Serverless应用的架构和实现方式。因此，有一部分人认为FaaS等同于Serverless，比如很多人将AWS Lambda称为AWS的Serverless，认为AWS Lambda就是AWS Serverless的全部功能。这些年，随着技术的发展，大家对Serverless研究的不断深入，目前业界主流的观点是Serverless和FaaS并不是等同关系，而是包含和被包含关系。FaaS平台是一个完整的Serverless实现的重要组成部分，仅仅通过FaaS平台并不能完全实现Serverless架构的落地。
FaaS为应用的开发、运行和管理提供良好的Serverless基础。将应用部署在FaaS上，用户无须关注应用运行所需要的底层服务器资源。但是当代的应用并不是孤立存在、单独运行的，一个完整的应用系统往往依赖于一些第三方服务，比如数据库、分布式缓存及消息队列等。如果这些服务还是以传统的方式运维，则意味着用户还是需要耗费时间和精力对这些服务所需的服务器资源进行管理。在这种情况下，就应用程序本身而言，这是实现了Serverless化，但是对应用整体系统而言，并没有完全实现Serverless化。因此，在实现应用架构Serverless化时，也应该实现应用所依赖的服务的Serverless化。2.BaaS
为了实现应用后台服务的Serverless化，BaaS（后台即服务）也应该被纳入一个完整的Serverless实现的范畴内。通过BaaS平台将应用所依赖的第三方服务，如数据库、消息队列及存储等服务化并发布出来，用户通过向BaaS平台申请所需要的服务进行消费，而不需要关心这些服务的具体运维。
BaaS涵盖的范围很广泛，包含任何应用所依赖的服务。一个比较典型的例子是数据库即服务（Database as a Service，DBaaS）。许多应用都有存储数据的需求，大部分应用会将数据存储在数据库中。传统情况下，数据库都是运行在数据中心里，由用户运维团队负责运维。在DBaaS的场景下，用户向DBaaS平台申请数据库资源，而不需要关心数据库的安装部署及运维。AWS的DynamoDB数据库就是DBaaS的一个例子。用户按需申请使用数据库服务，而无须关注数据库的运维和缩扩容。数据库的运维完全由服务提供方AWS负责。
AWS DynamoDB主页：https://aws.amazon.com/dynamodb。
DBaaS只是一个例子，通过BaaS平台应用将其所使用的任何第三方后台服务都进行Serverless化，使得用户可以不再关注所依赖的服务底层计算资源的运维，极大地减少了应用运维工作量和成本。
要实现完整的Serverless架构，用户必须结合FaaS和BaaS的功能，使得应用整体的系统架构实现Serverless化，最大化地实现Serverless架构所承诺带来的价值。因此，一个完整的Serverless实现，必须同时提供FaaS和BaaS两个方面的功能。当我们在考察一个Serverless平台或解决方案的时候，应该全面地考察这个平台或方案在FaaS及BaaS两个方面分别提供了哪些支持，以及在多大程度上可以让底层的服务器这一基础架构资源消失在用户的关注列表中。1.4 Serverless应用架构
要实现Serverless的理念，除了要有相关的工具、框架和平台提供Serverless实现的支持外，对于应用程序本身也有架构上的要求，让应用从架构层面上适应Serverless化的运行和管理环境，以获得Serverless架构的价值最大化。下面我们通过一个简单的例子观察Serverless架构下的应用与传统架构下的应用的异同。1.4.1 传统应用架构
图1-2所示的是一个订单应用程序的架构图。这是一个常见的传统应用设计和部署架构，应用程序部署在数据中心的主机上。在一个应用的交付件（Deliverable）中包含了多个功能，如订单创建、订单查询和订单修改等。应用数据存储在外部数据库中。数据库和应用一样，也部署在数据中心的主机上，由用户负责运维。这是目前大多数企业中应用的设计和部署架构，在业界已经沿用多年，相信有一定IT工作经验的读者一定不会感到陌生。为了获得同样的订单管理功能，在Serverless架构下应该如何实现呢？1.4.2 Serverless应用架构
图1-3是Serverless架构下的应用架构图。这个应用实现的功能和前文的应用一样，即为用户提供订单的增删查改服务。应用被部署在Serverless平台之上。应用的功能点变成若干个函数定义，部署于FaaS之中。数据仍然存放在后端数据库中。应用函数通过访问后端的数据库服务获取订单数据。图1-2 传统应用架构图图1-3 Serverless应用架构图1.4.3 两种架构的比较
通过对上面两个应用架构图的观察，不难发现Serverless架构下的应用和传统架构下的应用有如下相同的地方：
·两个应用都存在一个逻辑层，负责处理用户请求；
·两个应用的数据都存储在应用外部的数据库中。
这两个架构不同的地方是：
·传统架构的应用部署在主机之上，而Serverless架构的应用部署于Serverless平台之上，由Serverless平台提供运行所需的计算资源。
·传统架构的应用里，所有的逻辑都集中在同一个部署交付件中。Serverless应用的逻辑层部署运行在Serverless平台的FaaS服务之上。因此，应用的逻辑被打散成多个独立的细颗粒度的函数逻辑。因为业务逻辑运行在FaaS服务之上，所以相关的业务逻辑拥有事件驱动、资源自动弹性扩展、高可用等特性。用户也无须运维业务逻辑所消耗的计算资源。
·Serverless架构的应用所依赖的数据库从具体的特定数据库实例，变成了数据库服务。用户无须关注数据库所消耗的计算资源的运维。
·在Serverless架构下，由于应用的逻辑分散成了若干个函数，推荐通过API网关对这些函数逻辑进行统一的管控（如流量控制、安全管控、版本管理等）。在完备的Serverless平台上，API网关也会作为一种用户可以快速消费的服务而存在。
·在Serverless架构下，具体的主机资源不再是用户关注的对象，不存于应用架构图中。取而代之的是Serverless平台及其子服务，如FaaS和各类BaaS服务。
Serverless平台的FaaS及BaaS的功能提供了实现Serverless架构理念的技术基础。FaaS是Serverless应用的标准运行环境，BaaS是Serverless应用访问第三方依赖的标准途径。Serverless应用架构的演化其实就是应用为了适应Serverless平台的FaaS和BaaS的一个过程，使得应用的架构可以最大化FaaS和BaaS所带来的价值。
上面的例子只是一个简化的原型，在实际项目中，根据场景的不同，不同Serverless应用架构的具体实现将会有很大的不同。虽然不同应用的架构不同，但是最终要实现的目标还是一致的，那就是实现Serverless这一理念所强调的“无服务器”化。1.5 Serverless的技术特点
为了实现解耦应用和服务器资源，实现服务器资源对用户透明，与传统架构相比，Serverless架构在技术上有许多不同的特点。1.按需加载
在Serverless架构下，应用的加载（load）和卸载（unload）由Serverless云计算平台控制。这意味着应用不总是一直在线的。只有当有请求到达或者有事件发生时才会被部署和启动。当应用空闲至一定时长时，应用会被自动停止和卸载。因此应用并不会持续在线，不会持续占用计算资源。2.事件驱动
Serverless架构的应用并不总是一直在线，而是按需加载执行。应用的加载和执行由事件驱动，比如HTTP请求到达、消息队列接收到新的信息或存储服务的文件被修改了等。通过将不同事件来源（Event Source）的事件（Event）与特定的函数进行关联，实现对不同事件采取不同的反应动作，这样可以非常容易地实现事件驱动（Event Driven）架构。3.状态非本地持久化
云计算平台自动控制应用实例的加载和卸载，且应用和服务器完全解耦，应用不再与特定的服务器关联。因此应用的状态不能，也不会保存在其运行的服务器之上，不能做到传统意义上的状态本地持久化。4.非会话保持
应用不再与特定的服务器关联。每次处理请求的应用实例可能是相同服务器上的应用实例，也可能是新生成的服务器上的应用实例。因此，用户无法保证同一客户端的两次请求由同一个服务器上的同一个应用实例来处理。也就是说，无法做到传统意义上的会话保持（Sticky Session）。因此，Serverless架构更适合无状态的应用。提示 别担心，这并不是说Serverless架构下就无法妥善地处理有状态的场景，后续章节将对此进行详细讨论。5.自动弹性伸缩
Serverless应用原生可以支持高可用，可以应对突发的高访问量。应用实例数量根据实际的访问量由云计算平台进行弹性的自动扩展或收缩，云计算平台动态地保证有足够的计算资源和足够数量的应用实例对请求进行处理。6.应用函数化
每一个调用完成一个业务动作，应用会被分解成多个细颗粒度的操作。由于状态无法本地持久化，这些细颗粒度的操作是无状态的，类似于传统编程里无状态的函数。Serverless架构下的应用会被函数化，但不能说Serverless就是Function as a Service（FaaS）。前文也提过，在笔者看来，这样的认识并不准确。Serverless涵盖了FaaS的一些特性，可以说FaaS是Serverless架构实现的一个重要手段。关于FaaS的详细信息，我们将在后续的章节中进行深入的介绍和讨论。7.依赖服务化
当今的应用往往有各种各样的依赖，比如消息队列、数据库、缓存。如果应用只是摆脱了服务器的限制，而其依赖的各种外部服务仍然部署在各种用户管理的服务器之上，那么应用的整体部署、扩展及运营则仍然将受到服务器这一慢资源的制约。因此，在Server-less架构下的应用的依赖应该服务化和无服务器化，也就是实现Backend as a Service（BaaS）。所有应用依赖的服务都是一个个后台服务（Backend Service），应用通过BaaS方便获取，而无须关心底层细节。和FaaS一样，BaaS是Serverless架构实现的另一个重要组件。在后面的章节中，我们将详细介绍和讨论关于BaaS的相关话题。1.6 Serverless的应用场景
通过将Serverless的理念与当前Serverless实现的技术特点相结合，Serverless架构可以适用于各种业务场景。下面是其中的一些例子。1.Web应用
Serverless架构可以很好地支持各类静态和动态Web应用。比如，当前流行的RESTful API的各类请求动作（GET、POST、PUT及DELETE等）可以很好地映射成FaaS的一个个函数，功能和函数之间能建立良好的对应关系。通过FaaS的自动弹性扩展功能，Serverless Web应用可以很快速地构建出能承载高访问量的站点。
举一个有意思的例子，为了应对每5年一次的人口普查，澳大利亚政府耗资近1000万美元构建了一套在线普查系统。但是由于访问量过大，这个系统不堪重负而崩溃了。在一次编程比赛中，两个澳大利亚的大学生用了两天的时间和不到500美元的成本在公有云上构建了一套类似的系统。在压力测试中，这两个大学生的系统顶住了类似的压力。
参考来源：https://medium.com/serverless-stories/challenge-accepted-building-a-better-austra-lian-census-site-with-serverless-architecture-c5d3ad836bfa。2.移动互联网
Serverless应用通过BaaS对接后端不同的服务而满足业务需求，提高应用开发的效率。前端通过FaaS提供的自动弹性扩展对接移动端的流量，开发者可以更轻松地应对突发的流量增长。在FaaS的架构下，应用以函数的形式存在。各个函数逻辑之间相对独立，应用更新变得更容易，使新功能的开发、测试和上线的时间更短。
部分移动应用的大部分功能都集中在移动客户端，服务端的功能相对比较简单。针对这类应用，开发者可以通过函数快速地实现业务逻辑，而无须耗费时间和精力开发整个服务端应用。3.物联网
物联网（Internet of Things，IoT）应用需要对接各种不同的数量庞大的设备。不同的设备需要持续采集并传送数据至服务端。Serverless架构可以帮助物联网应用对接不同的数据输入源。用户可以省去花费在基础架构运维上的时间和精力，把精力集中在核心的业务逻辑上。4.多媒体处理
视频和图片网站需要对用户上传的图片和视频信息进行加工和转换。但是这种多媒体转换的工作并不是无时无刻都在进行的，只有在一些特定事件发生时才需要被执行，比如用户上传或编辑图片和视频时。通过Serverless的事件驱动机制，用户可以在特定事件发生时触发处理逻辑，从而节省了空闲时段计算资源的开销，最终降低了运维的成本。5.数据及事件流处理
Serverless可以用于对一些持续不断的事件流和数据流进行实时分析和处理，对事件和数据进行实时的过滤、转换和分析，进而触发下一步的处理。比如，对各类系统的日志或社交媒体信息进行实时分析，针对符合特定特征的关键信息进行记录和告警。6.系统集成
Serverless应用的函数式架构非常适合用于实现系统集成。用户无须像过去一样为了某些简单的集成逻辑而开发和运维一个完整的应用，用户可以更专注于所需的集成逻辑，只编写和集成相关的代码逻辑，而不是一个完整的应用。函数应用的分散式的架构，使得集成逻辑的新增和变更更加灵活。1.7 Serverless的局限
前文我们探讨了Serverless的理念及特点，介绍了许多Serverless的优点和价值。和其他很多的技术一样，世界上没有能解决所有问题的万能解决方案和架构理念。Serverless有它的特点和优势，但是同时也有它的局限。有的局限是由其架构特点决定的，有的是目前技术的成熟度决定的，毕竟Serverless还是一个起步时间不长的新兴技术领域，在许多方面还需要逐步完善。1.控制力
Serverless的一个突出优点是用户无须关注底层的计算资源，但是这个优点的反面是用户对底层的计算资源没有控制力。对于一些希望掌控底层计算资源的应用场景，Serverless架构并不是最合适的选择。2.可移植性
Serverless应用的实现在很大程度上依赖于Serverless平台及该平台上的FaaS和BaaS服务。不同IT厂商的Serverless平台和解决方案的具体实现并不相同。而且，目前Server-less领域尚没有形成有关的行业标准，这意味着用户将一个平台上的Serverless应用移植到另一个平台时所需要付出的成本会比较高。较低的可移植性将造成厂商锁定（Vendor Lock-in）。这对希望发展Serverless技术，但是又不希望过度依赖特定供应商的企业而言是一个挑战。3.安全性
在Serverless架构下，用户不能直接控制应用实际所运行的主机。不同用户的应用，或者同一用户的不同应用在运行时可能共用底层的主机资源。对于一些安全性要求较高的应用，这将带来潜在的安全风险。4.性能
当一个Serverless应用长时间空闲时将会被从主机上卸载。当请求再次到达时，平台需要重新加载应用。应用的首次加载及重新加载的过程将产生一定的延时。对于一些对延时敏感的应用，需要通过预先加载或延长空闲超时时间等手段进行处理。5.执行时长
Serverless的一个重要特点是应用按需加载执行，而不是长时间持续部署在主机上。目前，大部分Serverless平台对FaaS函数的执行时长存在限制。因此Serverless应用更适合一些执行时长较短的作业。6.技术成熟度
虽然Serverless技术的发展很快，但是毕竟它还是一门起步时间不长的新兴技术。因此，目前Serverless相关平台、工具和框架还处在一个不断变化和演进的阶段，开发和调试的用户体验还需要进一步提升。Serverless相关的文档和资料相对比较少，深入了解Serverless架构的架构师、开发人员和运维人员也相对较少，但是也许这在某种程度上而言是一个机会。1.8 本章小结
通过本章的介绍，我们了解了Serverless的内涵、实现、特点、价值及局限。作为一种软件的架构思想，Serverless强调的是让底层的计算资源不再成为用户的关注点，简化应用运营的复杂度，从而提高运营的效率，缩短应用上市的时间。Serverless架构的许多特点使得其在众多场景下能解决传统架构难以解决的问题，为企业IT和业务带来巨大的价值。在了解和拥抱Serverless技术的过程中，我们要清晰地认识到Serverless的优点和局限，以发挥这个架构所能带来的最大价值。
在第2章，我们将介绍与Serverless相关的技术和理念，了解它们和Serverless之间的联系，以深化我们对Serverless的理解。 第2章 Serverless与相关技术
IT是一个永远都不消停的行业，在这个行业里不断有各种各样新的名词和技术诞生。作为一个热门词汇，Serverless并不孤单，和它一起受到广泛关注的还有诸如微服务（Microservice）、容器（Container）和云等。其实这些技术之间有着很强的关联关系。正确地理解Serverless和其他技术的关系，是正确理解Serverless架构的一个重要基础。要深入理解Serverless，需要结合当下业界发展的整个大环境和趋势进行思考。2.1 云计算
到目前为止，云计算（Cloud Computing）的出现是21世纪IT业界最重大的一次变革。作为一种计算资源的组织和运作方式，云计算为IT业界的方方面面带来了巨大的改变，推动了一波又一波的技术变革。2.1.1 从私有数据中心到云
按所管控的计算资源的范围来划分，当前的云计算模式可以分为基础架构即服务（Infrastructure as a Service）、平台即服务（Platform as a Service，PaaS）以及软件即服务（Software as a Service，SaaS）。
如图2-1所示，在云计算传统的私有数据中心架构中，让一个应用服务上线跑起来，用户需要负责管理和维护从上到下整个堆栈中的所有资源—从底层网络、存储和主机，到操作系统、中间件，以及应用的开发、部署及运维。这种模式让用户对整个堆栈的各个层次有很强的控制力，这曾经是标准的架构模式。但是随着整个社会经济生活节奏的加快，社会竞争的加剧，业务对IT的要求在不断提高。为了配合业务的创新和推广，支撑业务的应用服务要更快地上线、更频繁地更新、更迅速地扩容。在传统的架构模式中，每上线一个应用服务，都要求用户对架构堆栈中每一个层次的服务进行配置和维护，这极大地拖慢了整体的流程效率，因此难以满足IT的敏捷化需求。传统的架构限制了生产力的发展，于是云计算的变革悄然而至。图2-1 各类云计算服务与传统模式的对比2.1.2 IaaS、PaaS与SaaS
在IaaS架构中，应用架构底层的网络、存储和计算资源（主机、物理机或虚拟机）不再属于用户的管理范围。这些资源由云平台供应商（Cloud Provider）提供和运维。用户在云平台上付费申请所需的网络、存储和计算资源，云平台供应商在一定时间内提供。对于用户而言，这大大减少了底层基础架构管理的工作量，提高了管理的灵活度。对于云平台供应商而言，集中化和规模化地运维及供给使得基础架构资源的成本更低，这是一个不可多得的商机。
IaaS减轻了用户管理基础架构的负担。PaaS则是在这个基础上让用户只关注应用服务。PaaS平台提供了应用的运行环境（如应用运行时）、应用依赖的服务（如数据库、中间件、负载均衡、构建服务、发布服务）以及底层所需的计算资源，用户可以把精力集中在应用的开发和创新上。PaaS模式可以提高应用开发、发布和运维的整体效率，有效缩短了应用上市的时间（Time to Market）。沿着IaaS和PaaS的思路前行，在SaaS模式下，用户完全不用管理任何应用和基础设施，从而变成云服务的消费者。
如图2-2所示，从IaaS、PaaS和SaaS的对比可以看出，通过将应用架构堆栈中各类资源的管理权委托给云计算平台，用户获得了更大的自由度和更低的管理成本。Serverless的思路其实也如出一辙，即将服务器这一资源从用户的管理职权中消除，从而减轻用户的负担，提高应用运营的效率。图2-2 各个云计算类型的自由度与管理成本对比2.1.3 Serverless与云计算
Serverless和云计算的发展是紧密联系的。Serverless是云计算变革过程中的一个必然产物。Serverless架构实现的一个重要基础是函数即服务（Function as a Service，FaaS）。如图2-3所示，FaaS的灵活度和管理成本介于PaaS和SaaS之间。相对于PaaS而言，FaaS有更高的抽象程度和更低的管理成本。相对于SaaS来说，FaaS用户有更高的控制力和灵活度。Serverless架构是对开发和运维的一场解放运动，让用户的焦点回到用户应该关注的地方，回到更有价值的地方，从而进一步提高软件应用的开发和运营的生产力。
毫无疑问，Serverless的出现和日益流行，标志着人们对应用和云计算平台之间的关系有了一个全新的认识。云计算的不断发展是Serverless发展和流行的最大推动因素。Serverless是云计算未来发展的一个方向。笔者认为，一个人对Serverless的理解和认识应该结合云计算发展的大背景，一个企业或组织对Serverless的布局应该结合该企业或组织的云战略。图2-3 FaaS与各云计算类型的对比2.2 微服务2.2.1 从SOA到微服务
从十多年前的面向服务架构（Service Oriented Architecture，SOA）转型开始，业界一直在寻找更灵活的软件架构，以便于更迅速地响应业务的变化。传统的应用倾向于在一个应用中囊括多个不同的功能模块。SOA时代提倡的是应用系统对外暴露功能并提供服务，通过服务的组合形成新的应用。在SOA架构下，应用通过服务暴露功能，实现了彼此信息的交换和集成，使得通过服务的组合和编排形成新的应用系统成为可能。但是多个模块和功能仍然被包含在同一个应用中、同一个交付件中，这使得各个模块的功能相互交缠，彼此制约。
为了解决SOA没有解决的问题，业界出现了微服务架构（Microservice Architecture，MSA）这一思想。微服务架构提倡将应用化整为零，减小颗粒度。如图2-4所示，大型的应用（Monolithic Application）按照一定的规则被拆分成若干个颗粒度更小的应用。这些细小的应用称为微服务（Microservice）。图2-4 微服务架构示意图2.2.2 微服务的价值与挑战
微服务的出现，突破了传统单体应用架构的制约，增加了应用架构的灵活度，为应用的开发和交付带来了价值。
·更清晰的权责。在微服务架构下，应用的颗粒度变小，每一个微服务尽可能只做一件事情，并将这件事情做好。各个微服务之间的职能边界变得更清晰。
·更快速的开发和交付节奏。每一个微服务都可以独立地被开发，可以有自己的开发和交付节奏。每一个微服务都可以被独立地部署，可以有独立的上线和更新节奏。应用系统的更新不再牵一发而动全身，应用更新的节奏将更快。
·更灵活的资源扩展。每一个微服务可以独立地部署和运行，因此可以独立地为每个服务进行扩容和缩容，而不影响其他服务。
微服务架构在带来价值的同时也带来了一些新的挑战，在落地实践微服务架构时，用户必须思考如何解决这些挑战。
·团队组织变化。微服务架构的引入使得应用架构化整为零。应用架构的改变也将导致开发应用的开发团队结构发生变化。用户必须克服和适应组织变化带来的影响。
·运维复杂度。单体应用化整为零，意味着需要运维管理的应用实例数将大大增加。原本只需要部署管理一个应用实例的单体应用，在微服务架构下工作量呈指数级增长。用户需要通过有效的手段降低运维的复杂度，容器是一个好的解决方案。
·微服务治理。微服务之间的通信、调用链的跟踪管理、状态监控、错误跟踪排查等都需要相应的解决方案。
关于微服务的更详细介绍，推荐参考ThoughtWorks的Martin Fowler的文章《Micro-services Guide》，地址为https://martinfowler.com/microservices/。2.2.3 Serverless与微服务
与Serverless相似，微服务也是云计算发展的产物。云计算平台解决了基础架构利用的效率瓶颈，为应用提供更方便的基础服务（如构建、更新、扩容、高可用、错误自恢复等）。微服务架构从应用架构的层面入手，为未来的应用从架构层面上更契合云计算平台提供了各种服务和资源，进一步提高了应用开发和交付的效率。
Serverless和微服务两种架构都强调功能的解构。两者都强调最小的成员单位专注于做一件事情，做好一件事情。但是微服务架构中的最小成员单位是微服务，而Serverless架构中的最小成员单位是函数。Serverless和微服务的目的是一致的，那就是提高应用开发、交付上线的效率。但是两者侧重点不同。微服务强调化整为零，提高应用架构灵活度。Serverless强调的是“减负”，即将服务器移出用户的管理职责范围，从而降低管理复杂度和成本。
在微服务架构下，系统化整为零，架构上带来灵活性的同时，也增加了开发、部署和运维的复杂度。虽然通过容器等技术可以降低相关的复杂度，但是对比而言，Serverless应用的开发和运维的效率更高，管理成本更低。
Serverless是一种具有前瞻性的技术，那么现在许多组织和企业在推进的微服务架构是不是都是徒劳的呢？答案是否定的。Serverless架构的实现有一个很重要的前提，那就是需要一个强大的智能云计算平台，无论是公有云还是私有云。目前而言，并不是每一家企业或组织都具备这个条件。再者，没有一个架构是完美的，Serverless也有它的限制，不是每一个场景都适合引入Serverless架构。2.3 容器2.3.1 容器技术的兴起
随着云计算的日益流行，用户对云的接受程度也日益提升。用户的计算资源从原有的私有数据中心扩展至云计算平台。应用仍然是用户关注的一个核心问题。随着计算资源边界的扩张，应用也需要从私有数据中心迁移到云上。对于很多用户而言，云和非云环境并不是二选一，而是两者都需要。云和非云环境在相当长的一段时间内将同时存在。应用如何快速地在云和非云环境中迁移成为一个重要的问题。此外，越来越多的用户在他们的云战略中包含了不止一个云。为了有更高的可用性，避免厂商的锁定，一些实力雄厚的客户往往同时是多家云平台供应商的客户。因此实现应用在不同云环境中的快速迁移也成为一个重要的需求。
混合云环境的示意图如图2-5所示。图2-5 混合云环境
在IaaS模式下，云平台底层的计算资源是以物理机（Bare Metal）或虚拟机的形式提供的，这些计算资源过于“笨重”，难以在不同的环境中被快速地“移动”。通过IaaS，用户可以方便快速地获取大量的计算资源：主机。但是应用并不能直接消费主机。用户必须在主机上安装应用所需要的中间件，添加应用所需要的系统配置，然后再对应用进行配置才行，这些工作都拖慢了整个应用交付流程的节奏。相对而言，PaaS则没有这些效率低下的步骤，用户只需要关注应用，无须过度关注底层。但是传统PaaS的一个问题在于，PaaS平台对应用有入侵性。为了享用PaaS平台提供的一些高级功能，应用必须在代码中引入PaaS平台的API。这种入侵性导致应用在不同云环境中的迁移变得困难。
容器（Container）技术的出现为前文提及的问题提供了一个很好的解决方案。容器技术以一种称为容器镜像（Container Image）的打包格式为基础，扩大了应用交付件的边界。与以往应用交付件只包含应用本身不同，容器镜像中不仅包含编译构建后的应用，还包含应用所依赖的中间件、类库和操作系统设置等配置，可以为应用的运行提供一个完整的环境。以操作系统的内核为基础，容器引擎在主机之上可以快速实例化容器镜像，生成一个或多个容器实例。容器技术的出现，解决了应用消费主机资源效率低下的问题，使得应用可以被快速地部署到庞大的计算集群中去。容器以操作系统内核为基础，保证了可移植性，让应用可以在不同的云环境中，甚至不同的非云环境中被方便地迁移。与IaaS相比，容器比虚拟机和物理机更加小巧和灵活，便于在不同环境之间传输。与传统的PaaS相比，容器有更清晰的边界，对应用没有入侵性，极大地提高了应用的可迁移性。
经过几年的迅速发展，容器已经不容置疑地成为云计算的一项关键基础技术。Docker（现在已经更名为Moby项目）已成为容器引擎的事实标准。Kubernetes也在竞争中脱颖而出，成为容器编排（Orchestration）平台的事实标准。通过Kubernetes这样的容器编排平台，容器镜像可以快速地被部署到成百上千的主机上。Kubernetes成为一种类似操作系统的存在，有的人认为Kubernetes就是一种云操作系统。传统的操作系统只管理一台主机上的CPU、内存、磁盘和网络资源，而Kubernetes则掌控着数据中心中成百上千台主机的资源。2.3.2 Serverless与容器
容器和Serverless在技术上有相同的地方，如结合容器的特点和Kubernetes这种容器编排平台，用户可以实现对容器应用的自动弹性伸缩。Kubernetes对底层的主机资源进行抽象，在一般场景下，用户也不关注容器应用具体运行在什么主机上。与Serverless类似，容器应用的部署和扩容的效率也很高。不同的地方在于，容器架构中最小的运行单元是容器，而Serverless中则是函数。容器应用一般是预先部署，然后持续在线。而在Serverless架构中，应用是按需加载和执行的。这意味着理论上Serverless的资源使用效率更高。
其实，容器技术可以是Serverless架构实现的一个基础。容器平台的最小运行单元为容器，虽然目前容器内一般运行的是一个完整的应用，但是将容器内运行的对象变成函数显然并无技术困难。Kubernetes上默认没有事件触发的支持，无法做到按需部署容器应用。但是通过Kubernetes叠加上一些FaaS框架运行包含函数逻辑的容器，用户很容易使Kubernetes具备FaaS服务的能力，如图2-6所示。同时，Kubernetes也可以作为基础平台实现各类应用所依赖的服务（如缓存、图像处理、数据库及AI等）的云化。当服务足够丰富时，可形成一个完备的BaaS平台。笔者相信，容器必将是未来私有云构建Serverless能力的一个重要实现基础。
Kubernetes是Google开源的一个容器编排项目，为用户提供一个跨平台的容器部署和管理解决方案。有关Kubernetes的更多详细信息可以参考其主页：https://kubernetes.io。
试读结束[说明：试读内容隐藏了图片]