作者：刘宇
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Serverless架构：从原理、设计到项目实战试读：
前言
云计算的不断发展给社会带来了诸多便利，云计算与大数据、人工智能的结合，更让我们的生活悄然发生着翻天覆地的变化。从IaaS到PaaS，再到如今的FaaS，每一个阶段都是人类文明前行的一小步，但却是当前技术发展的一大步。Serverless自概念被提出到现在，搜索热度与关注度、相关开源项目的增长速度与社区活跃度，都充分显示了广大云厂商、开发者对这个架构的支持和期待。甚至有人说Serverless才是真正的云计算，这种说法可能有些夸张，但是不可否认，Serverless技术确实在逐渐融入人们的生活并改变世界，无时无刻不在向我们阐述“云时代”真的要到来了。
本书将通过对Serverless架构的基本描述，介绍其发展历史、应用场景及未来展望，让读者可以更好地了解什么是Serverless及Serverless的过往、未来。本书也对Serverless架构的规范、标准等进行了描述，对开源框架、开源工具、工业化产品进行了相关分析，让读者在明白如何使用Serverless或者Serverless有哪些特性的同时，可以真正地使用Serverless相关产品，甚至可以通过开源项目搭建一套自己的Serverless服务。最后，本书通过监控告警、网站后端、人工智能、大数据、物联网、高可用等多个领域的场景实践，以及两个完整的项目实战，并且与Web应用、微信小程序、快应用等结合，为读者进行了更加细致的分析和讲解，希望通过这种方式使读者不仅知道Serverless是什么，Serverless能做什么，还可以获得更多的启发，并将Serverless架构应用于实战，通过Serverless架构创造更多的价值，实现自身业务的快速上云。
本书共分为7章，详细介绍了Serverless的概念、标准规范、场景实践及项目实战。
第1章，主要介绍什么是Serverless、Serverless架构的优势和劣势、影响和价值、典型应用场景及对未来的展望，这一章是Serverless架构的介绍部分，读者可以对Serverless架构有一个全面深刻的认识，甚至可以评估出自己目前的产品是否适合接入Serverless架构、如果接入会有哪些好处和变化等。
第2章，主要介绍Serverless相关的标准和规范、开源产品发展情况、工业化产品发展情况及开发工具建设情况等。读者可以明确地知道Serverless架构的组成及各种相关产品的关系等，同时通过对开源产品的分析和探讨，深入了解OpenWhisk、Fission、Kubeless等相关开源项目，甚至可以动手搭建一个属于自己的Serverless平台。通过对工业化产品的分析，读者可以知道AWS、Google、Azure、腾讯云等云厂商在Serverless架构方面的发展情况。通过开发者工具部分，读者可以明白自己如果使用Serverless架构，应该如何进行开发。
第3、4、5章，结合Web服务、监控告警、大数据、人工智能及物联网等为读者带来十余个场景实践，通过这些场景实践希望读者对Serverless架构的作用及应用场景有更多的思考、获得更多启发，并深度认识Serverless架构给开发者、运维者等带来的变化，进而将Serverless架构与自身的项目和业务结合，并拓展思路探索更多的应有场景，创造更多的价值。
第6章和第7章，是两个相对完整的实战项目，从需求分析开始，到功能设计、数据库设计、接口设计，再到后端功能实现、前端功能实现，最后部署上线，通过将对象存储、云数据库及云函数、API网关等产品进行融合，构建出完整的Web项目和微信小程序项目。在这两个项目中有大量的人工智能技术的应用，包括自然语言处理、推荐系统及计算机视觉等技术，不仅为学习增加了趣味性，也提高了项目的应用价值。
本书在编写过程中力求深入浅出、重点突出、简明扼要，尽可能方便不同专业背景和知识层次的读者阅读，同时通过基础知识与实践项目结合，力求为读者打造一种可学习、可实践、可思考、可探索的阅读体验。
在本书的编写过程中，腾讯云Serverless团队给予了大力支持，包括Yunong、Cliff、Scott、Horace等在内的前辈们都提供了大量帮助。Tina、Liujiang等也对本书的编写及相关文章的发表等提供了重要帮助和保障。在此特别感谢大家。另外，本书部分内容参考了公开资料和网络上的资源，在此也对相关作者致以深深的感谢。
最后需要说明的是，Serverless是目前非常火的一种技术，其底层原理相对复杂，应用领域相对广泛，因此编写一本完美的Serverless图书绝非易事，书中难免存在疏漏或者错误，希望广大读者不吝赐教。如有任何建议、意见或者疑问，请及时联系作者，以便在后续版本中改进和完善。
读者服务微信扫码回复：37628
● 获取本书配套素材
● 获取更多技术专家分享视频与学习资源
● 加入读者交流群，与更多读者互动第1章 初识Serverless1.1 什么是Serverless
近年来，IT技术的更新迭代速度非常快，每个时间点都有典型的代表名词及概念，就目前而言，人工智能领域中的机器学习、深度学习、强化学习等，还有区块链、物联网等非常火热。在云计算领域，有一种技术被众多云厂商认为是“风口项目”，甚至可以颠覆现有云计算中的某些格局，为此AWS、Google腾讯云、阿里云等云厂商都投入了大量精力进行相关产品建设，这种技术就是Serverless。
Serverless又名无服务器，所谓无服务器并非是说不需要依赖和依靠服务器等资源，而是开发者再也不用过多考虑服务器的问题，可以更专注在产品代码上，并且无须管理和操作云端或本地的服务器，同时计算资源也开始作为服务出现，而并非作为服务器的概念出现。Serverless是一种构建和管理基于微服务的架构的完整流程，允许你在服务部署级别而不是在服务器部署级别来管理你的应用部署。与传统架构的不同之处在于，它完全由第三方管理，由事件触发，存在于无状态（Stateless），暂存（可能只存在于一次调用的过程中）在计算容器内。Serverless真正做到了部署应用时无须涉及更多的基础设施建设，就可以基本实现自动构建、部署和启动服务。
众所周知，云计算的发展历程如图1.1所示，从IaaS、PaaS、SaaS到最新的BaaS、FasS等。图1.1 云计算的发展历程
在云计算的发展过程中，从IaaS到PaaS再到SaaS的过程中，去服务器化越来越明显，如图1.2所示。
目前的Serverless去服务器化到了什么程度呢？有人这样说，无服务器架构是传统的云计算平台的延伸，是PaaS向更细粒度的BaaS和FaaS的发展，那么Serverless与FaaS有什么关系？FaaS与PaaS又有什么区别呢？图1.2 IaaS和PaaS、SaaS的区别
微服务（Micro Service）是软件架构领域另一个热门的话题。如果说微服务以专注于单一责任与功能的小型功能块为基础，利用模组化的方式组合出复杂的大型应用程序，那么我们可以进一步认为Serverless架构可以提供一种更加“代码碎片化”的软件架构范式，我们称之为Function as a Services（FaaS）。而所谓的“函数”（Function）提供的是相比微服务更加细小的程序单元。例如，微服务可以代表为某个客户执行所有CRUD操作所需的代码，而FaaS中的函数可以代表客户所要执行的每个操作：创建、读取、更新及删除。当触发“创建账户”事件后，将通过函数的方式执行相应的“函数”。单就这一层来说，可以简单地将Serverless架构与FaaS概念等同起来。但是如果就具体的概念深刻探索，Serverless和FaaS还是不同的，UC Berkley发表过一篇关于Serverless观点的文章：Serverless [1]Computing: One Step Forward， Two Steps Back：因此，云提供商很快就会强调Serverless并非不存在服务器，也并不仅仅是FaaS。它是由“Standard library”支持的FaaS：即由供应商（例如AWS、阿里云、腾讯云等）提供各种底层能力。对于AWS而言，这种底层能力包括S3（Large object storage）、DynamoDB（Key-value storage）、SQS（Queuing services）、SNS（Noti-fication services）等，这些能力也可以称为BaaS。这些基础设施或者说底层能力由AWS管理和运营，开发人员只需注册使用相应服务即可，开发人员通过编写函数代码，使其运行在FaaS平台上，在适当的时候，可以使用这些底层能力，并且“即付即用”，即按量付费。
其中关于One Step Forward及Two Steps Back的说法大概如下：One Step Forward：通过提供Autoscaling（自动伸缩，也称为自动扩缩容），今天的FaaS产品向云编程迈出了一大步，提供了一个实际上可管理的、看似无限的计算平[2]台。Two Steps Back：首先，它们（Serverless架构）忽视了高效数据处理的重要性，即在Function的情况下，每个Function是独立的，Function之间的交互是通过持久或临时的存储、事件驱动来完成的，导致了完成交互的时间比以前慢了很多很多；其次，也阻碍了分布式系统的开发，即通常分布式系统会依赖很多的类似leader election协议、数据一致性、事务机制等，而这些在目前的FaaS类型的平台里是很难实现的。
FaaS与PaaS的概念有许多相似的地方，人们甚至认为FaaS就是另一种形式的PaaS，但是Intent Media的工程副总裁Mike Roberts有自己的不同看法：Most PaaS applications are not geared towards bringing entire applications up and down in response to an event， whereas FaaS platforms do exactly this.（大多数PaaS应用程序都不适合响应事件而对整个应用程序进行调整，而FaaS平台是可以这样做的。）
FaaS和PaaS在运维方面最大的差异在于缩放能力。对于大部分PaaS平台，用户依然需要考虑缩放。但是对于FaaS应用，这种问题完全不存在。就算将PaaS应用设置为自动缩放，依然无法在具体请求的层面上进行缩放，而FaaS应用在成本方面少很多。AWS云架构战略副总裁Adrian Cockcroft曾经针对两者的界定给出了一个简单的方法：If your PaaS can efficiently start instances in 20ms that run for half a second， then call it serverless.（如果PaaS可以在20ms内有效地启动运行半秒的实例，那么它就可以被称为Serverless架构。）
正因为Serverless与PaaS的不同，以及Serverless与FaaS和BaaS的关系，所以有人说Serverless真正实现了当初云计算的目标，更有人这样定义Serverless：Serverless=BaaS+FaaS+…
诚然，这种说法未必是百分之百准确的，就像Martin Fowler的一句话：Like many trends in software， there's no one clear view of what Serverless is. 但是不可否认的一点是Serverless在很多层面、很多领域，越来越显现出“期望中云计算”的样子了。Martin Fowler在Serverless Architectures中对Serverless这样定义：
· Serverless was first used to describe applications that significantly or fully incorporate third-party， cloud-hosted applications and services， to manage server-side logic and state.These are typically “rich client” applications—think single-page web apps， or mobile apps—that use the vast ecosystem of cloud-accessible databases （e.g.， Parse， Firebase），authentication services （e.g.， Auth0， AWS Cognito）， and so on. These types of services have been previously described as “（Mobile） Backend as a Service"， and I use "BaaS" as shorthand in the rest of this article.
· Serverless can also mean applications where server-side logic is still written by the application developer， but， unlike traditional architectures， it's run in stateless compute containers that are event-triggered， ephemeral （may only last for one invocation）， and fully managed by a third party. One way to think of this is “Functions as a Service” or “FaaS”.（Note: The original source for this name—a tweet by @marak—is no longer publicly available.） AWS Lambda is one of the most popular implementations of a Functions-asa-Service platform at present， but there are many others， too.
通过Martin Fowler的描述可以大概用图1.3来总结Serverless与FaaS及BaaS的关系。图1.3 Serverless与FaaS、BaaS关系图
讲到此处，想必各位读者已经对Serverless及FaaS、BaaS、SaaS、PaaS、IaaS等都有了一定的了解，同时对什么是Serverless也有了比较清晰的基本认识，那么Serverless在实际项目中到底有什么具体表现呢？此处以一个Web项目为例，当我们做一个Web项目的时候，用户通过浏览器获得数据的流程，如图1.4所示。图1.4 Web项目传统结构图
这里面服务器中可能涉及路由规则、鉴权逻辑及其他各类复杂的业务代码，同时开发团队要花很多精力在服务器的运维上面，包括客户量突然增多时是否需要扩容服务器，服务器上的脚本、业务代码等是否还在健康运行，是否有黑客在不断地对服务器发起攻击。当我们切换到Serverless的逻辑之后，就变成了如图1.5所示的结构。图1.5 Web项目Serverless架构下的结构图
可以看出，在这个结构下，在客户端和数据库未发生变化的前提下，服务器变化巨大，之前需要开发团队维护的路由模块及鉴权模块都接入了服务商提供的API网关系统及鉴权系统，开发团队无须再维护这两部分的业务代码，只需要持续维护相关规则即可。业务代码也被拆分成了函数粒度，不同函数表示不同的功能。同时，在这个结构下，我们已经看不到服务器了，因为Serverless的目的是让使用者只关注自己的业务逻辑，所以部分安全问题、资源调度问题（例如用户量暴增时如何实现自动扩容等）交给云厂商负责。传统项目无论是否有用户访问，服务都在运行中，都有成本支出，而在Serverless架构下，只有在用户发起请求时，函数才会被激活并且执行，从而节约了成本。更多Serverless架构的优势、应用场景和价值等，会在后续章节详细说明。
总而言之，Serverless技术是在传统容器技术和服务网格上发展起来的，更侧重让使用者只关注自己的业务逻辑。它是云计算发展到一定阶段的必然产物，云计算作为普惠科技，发展到最后一定是绿色科技（最大限度地利用资源，减少资源浪费）、大众科技（成本低，包括学习成本及使用成本），而Serverless将很好地诠释这些！1.2 优势与劣势
Serverless架构并不是脱离了服务器或者不需要服务器，而是意味着去除有关对服务器运行状态的关心和担心，例如对服务器是否在工作、应用是否正常运行等问题，不需要关心和担心，这不仅是Serverless架构的一个特性，更是其给予开发者的便利，也是其一大优势。除此之外，Serverless架构的其他优势也是非常明显的，包括Serverless架构本身的优点，以及用户使用Serverless架构时可以带来的开发优势、体验优势等。
Serverless架构的优势主要包括降低运营成本和开发成本，拥有优秀的扩展能力、更简单的管理，以及符合“绿色”计算的思想。在使用传统服务器的时候，我们的服务器每时每刻的用户量是不同的，资源使用率也是不同的，可能白天资源使用率比较合理，夜间就会出现大量资源闲置。按照《福布斯》杂志的统计，企业数据中心的典型服务器使用率仅5%～15%，这无疑是一种资源的巨大浪费。而Serverless架构的出现，则可以让用户委托服务提供商管理服务器、数据库和应用程序甚至逻辑，这样做一方面减少了用户自己维护的麻烦，另一方面用户可以根据自己实际使用函数的粒度进行成本的支付。对于服务商而言，他们可以将更多的闲置资源进行额外的处理，这从成本的角度、“绿色”计算的角度来说，都是非常不错的。
对于用户和开发者而言，Serverless架构有降低人力成本、降低风险、减少资源开销、增加缩放灵活性、缩短创新周期等优点，如图1.6所示，使用Serverless架构，用户不需要再自己维护服务器，也不需要自己操心服务器的各种性能指标和资源利用率，可以有更多的时间和精力去关心和关注应用程序本身的状态和逻辑。同时Serverless应用本身的部署十分容易，我们只要上传基本的代码即可，例如Python程序只需要上传其逻辑与依赖包，C/C++、Go等程序只需要上传其二进制文件，Java程序只需要上传其Jar包等，无须使用Puppet、Chef、Ansible或Docker来进行配置管理，这大大降低了运维成本。对于运维来说，Serverless架构也不再需要监控底层的数据，例如磁盘使用量、CPU使用率等，可以更加专注地将监控目光放到监控应用程序本身的度量上。在Serverless架构下，运维人员的工作角色会有所转变，部署将更加自动化，监控将更加面向应用程序本身。图1.6 传统项目上线和Serverless项目上线对比图
在降低风险层面，对于组件越多、结构越复杂的系统，出故障的风险就越大，而在Serverless架构下，很多模块都可以托管给服务商，例如存储系统、API网关系统等，对于传统项目中需要我们自己维护的触发模块、路由模块、存储模块，我们不再直接维护，如果出现问题，可以交给服务商来处理，让服务商的专业人员来处理有时候比我们自己来处理更可靠，利用专业人员的知识来降低停机的风险，缩短故障修复的时间，可以让我们的系统稳定性更高。当然，这一点也充分说明，找到一个专业的服务商是非常必要的。
在传统项目上线过程中，需要申请主机资源，这时候一般会评估出一个峰值（最大开销），再根据峰值来申请资源，这意味着即使在主机闲置的状态下也要支付峰值容量的开销，往往会导致主机资源过度配置。对于某些应用来说这是不得已的做法，比如数据库这种很难扩展的应用。而对于普通应用这就显得不太合理了，虽然很多时候我们都觉得即使浪费了资源也比当峰值到来时应用程序因为资源不足而无法提供服务好。这个问题最好的解决办法就是，不计划到底需要使用多少资源，而是根据实际需要来请求资源，当然前提是整个资源池里的资源是充足的（公有云显然更适合）。根据使用时间来付费，根据每次申请的计算资源来付费，让计费的粒度更小，将更有利于降低资源的开销。这是对应用程序本身的优化，例如让每次请求耗时更短，让每次消耗的资源更少，将能够显著节省成本。
如图1.7所示，以腾讯云SCF（Serverless Cloud Function）为例，当平台接收到第一个触发函数的事件时，它将启动一个容器来运行代码。如果此时收到了新的事件，而第一个容器仍在处理上一个事件，平台将启动第二个代码实例来处理第二个事件。SCF的这种自动的零管理水平缩放，将持续到有足够的代码实例来处理所有的工作负载为止。图1.7 函数自动弹性伸缩示意图
除了上述各种优势，Serverless也更容易上手操作，有利于提升团队效率，降低人力成本。2019年8月，在腾讯云位于深圳的技术沙龙中，“乐凯撒”团队的同学对其项目中的两个使用了Cloud Function的模块进行了分享，其中一个是云打印服务，通过使用腾讯云Cloud Function提供的Web Socket服务，避免了难度较大的底层框架的开发，研发人员只要关注业务开发即可，一个人大概花了2周时间就完成了项目开发，人力和时间成本至少节约50%；另一个例子是会员花销标签计算系统，使用CMQ、API网关和Cloud Function快速搭建起来一个高性能的计算服务架构，一个中级研发工程师（3年经验）从研究[3]使用方法到搭建框架再到开发完成用了不到两周时间。通过这两个生动形象的例子，我们可以看到，Serverless架构可以使用短而简单的函数和事件来黏合强大的驱动数据存储和服务的API。完成的应用程序具有高度可用性和可扩展性，利用率高，成本低，部署速度快，可以大大节约时间成本和人力成本。如果说以Docker为代表的容器技术缩短了应用程序的迭代周期，而Serverless架构则直接缩短了创新周期——从概念到最小可行性部署的时间，让初级开发人员也能在很短的时间内完成以前通常需要经验丰富的工程师花很长时间才能完成的项目。
当然，所有事情都有“利”的一面，也有“弊”的一面，Serverless架构也是如此，它在为我们提供便利的开发模式、开发策略的同时，为我们提供优秀的底层服务的同时，为我们提供按量使用服务的同时，也暴露出了一些劣势。例如Serverless架构难以进行状态管理，要想实现自由缩放，无状态是必需的，而对于有状态的服务，使用Serverless就会丧失其灵活性，有状态服务需要与存储交互就不可避免地增加了延迟和复杂性。说到增加延迟，就不得不说Serverless架构的另一个劣势，那就是由冷启动带来的延迟问题，应用程序中不同组件的访问延迟是一个大问题。Serverless应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题。由于不同的云厂商或者不同的开源框架都有不同的入参格式，并且不同的触发器也有不同的格式，以腾讯云的Serverless产品为例，其入参有[4]event和context。通过event入参对象，云函数代码可以与触发函数的事件（event）交互；通过context入参对象，代码将能了解到运行环境及当前请求的相关内容。不同触发器的event的格式也不尽相同，例如腾讯云CMQ触发器的event格式模板为：
Ckafka触发器的event格式为：
正是这种厂商之间的入参内容不一致，不同触发器的参数格式不一致，导致了Serverless架构项目本地测试难度相对较大，这是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于Serverless应用的集成或者端到端测试尤其困难，很难在本地模拟应用程序的各种连接，并与性能和缩放的特性结合起来测试，并且Serverless应用本身也是分布式的，简单地将无数的FaaS和BaaS组件黏合起来也是有挑战性的。
除了上述劣势，Serverless架构还有语言版本落后、完全依赖于第三方服务等缺点。
就目前而言，无论是AWS还是腾讯云或者Google云，其Serverless相关产品所支持的Runtime都是有限的，很多语言版本不能及时更新已经成为共性问题，以AWS为例，在Node.js 6出来的时候，AWS Lambda只支持到Node.js 4.3.2；在Node.js 9出来的时候，AWS Lambda仅支持到6.10.3。
由于Serverless过分依赖服务商，例如一个网站业务使用Serverless可能需要绑定服务商的API网关、对象存储、数据库、云函数等众多产品，而且每个服务商的函数之间的编排规则、event参数的格式又不一样，就会导致更换服务商困难重重。例如，目前用户在AWS上部署了一套基于Serverless架构的网站后端服务，那么此时想要将这个业务迁移到Google云上，基本上要对全部函数进行改造，这是非常有风险的，且要投入很大精力。
总结一下，Serverless的技术特点就是按需加载、事件驱动、状态非本地持久化、非会话保持、自动伸缩和应用函数化，其优势就是节约成本（包括时间成本、人力成本等）、减少运维需求、缩短迭代周期。同时Serverless架构也有与云厂商高度耦合、难以解绑，冷启动问题严峻，函数编排较困难等劣势。但是我们不可否认，Serverless正在以我们肉眼可见的速度快速地发展。1.3 影响力和价值
2019年，Serverless被Gartner称为最有潜力的云计算技术，是必然的发展趋势。Serverless从底层开始变革计算资源的形态，这为软件架构设计与应用服务部署带来了新的设计思路。
腾讯云Serverless团队产品经理黄文俊对Serverless架构这样描述[5]：首先，从开发者使用来说，不用更多地考虑服务器的相关内容，比如服务器的规格大小、存储类型、网络带宽、自动伸缩等问题，也无须再对服务器进行运维，无须不断地打系统补丁、应用补丁，无须进行数据备份、软件配置等工作；其次，Serverless产品是完全自动伸缩的，在业务量处于高峰时，产品的计算能力与容量自动扩容，承载更多的用户请求，而在业务量下降时，所使用的资源也会同时收缩，避免资源浪费；再次，完全自动化的伸缩所带来的是全新的计量计费模式，开发者仅需根据使用量来付费，在深夜无业务的情况下，不会有空闲资源占用的情况，因此也不会产生费用。除了国内的腾讯云相关成员对Serverless有高度的评价，国外各个团队甚至一些知名人物，也对Serverless抱有热烈的期盼。在文章Predictions 2018: Why [6]Serverless Processing May Be Wave of the Future中有来自知名团队及公司的相关负责人对Serverless架构的看法：
· Sumo Logic产品营销副总裁Kalyan Ramanathan：Serverless架构可能是容器之后的未来。
· Avere Systems技术总监Dan Nydick ：我们将看到更多的Serverless技术和相关的托管服务。
· Atlassian平台负责人Steve Deasy：2018年（Serverless）将改变软件的构建方式。
· Evident.io首席执行官Tim Prendergast和客户解决方案副总裁John Martinez：容器和Serverless正在迅速发展，但它们也会带来安全问题。
· Contino美国总裁Jason McDonald：Serverless架构将会持续增加其影响力，也会被更多人或者组织所采用。
· OVH US的现场宣传员兼原理系统工程师Paul Stephenson：Serverless可以解决哪些问题将变得更加清晰，其应用范围、领域也会越来越明确。
· 数据探险公司首席执行官Seth Nobl：2018年，Serverless将会与其他更多技术集成。
· Platform9首席执行官Sirish Raghuram：Kubernetes将在AWS Lambda（AWS的Serverless产品）部署中发挥更大的影响力。
· Accelerite首席执行官Nara Rajagopalan：Serverless将会改变（软件开发的）发展模式。
同样，近些年云厂商也对Serverless架构情有独钟，在开源届也先后出现了众多Serverless架构相关的开源产品，如表1.1和表1.2所示。表1.1 工业化项目举例表1.2 开源项目举例
同时CNCF也将这些Serverless架构相关的产品进行了进一步整理，其中包括Tools、Security、Framework及Platform（Hosted、Installable），如图1.8所示。[7]图1.8 CNCF整理的Serverless相关产品
作为一个不断发展的新兴技术，如图1.9所示，Google Trends显示，自2015年开始Serverless的搜索量直线上升，到撰写本书时其热度翻了数十倍。图1.9 Serverless关键词在Google Trends上的搜索量
这也充分说明了Serverless架构近几年的发展速度之快，更说明了云计算确实正在越来越朝着去服务器化发展。
整体而言，Serverless架构的价值在于它对成本的降低，在于它对传统分工的改变，也在于它通过为开发者创造一个更加人性化和美好的开发环境和运维条件，进而节约精力、节约人力、节约成本，让开发者可以更加关注自身代码、自身业务、自身逻辑和自身产品。其影响力在于，它正在不断地、迅速地融入“云计算”的大家庭，正在为“理想中的云计算”贡献自身力量，为整个云计算的发展贡献巨大的力量。1.4 技术难点与挑战
前面我们已经介绍了一些Serverless架构的劣势，实际上，当时举例说明的一些劣势是包括设计特性及技术难点在内的。所谓设计特性就是说，Serverless架构本身设计之初就是无状态的，是函数级别的，所以有超时机制存在也算合理现象，这就导致了用户代码不能长期运行。但是随着时间的推移，技术的发展，以及用户本身需要的函数状态的保留，各大厂商也在积极对云函数进行改造和升级，例如腾讯云Serverless团队提出了HTTP Service概念。除了所谓设计特性产生的劣势，还有技术难点产生的劣势，这一部分也是Serverless架构现在和未来一段时间面临的挑战。
在众多挑战中，函数的冷启动是最值得关注和重视的。使用Serverless架构的时候，一定要考虑冷启动问题，由于函数是无状态的，所以每次执行某个函数，实际上都可能从头开始。这里所谓的从头开始，在某些情况下也指从建立镜像、运行容器到初始化函数及执行函数的过程，对于某些对时间要求严格的项目而言，或者对于某个可能有多个函数组合的请求而言，这样的流程是会大大增加延时的。
2019年5月29日，腾讯云+社区技术沙龙“互联网架构”成功举办，腾讯工程师对函数冷启动部分做了一个描述，如图1.10所示。图1.10 本地函数调用与云函数调用区别图
开发者提交代码之后你不知道他是否会调用，第一次调用函数会有一个函数冷启动的过程，把网络环境全部打通，这个函数才能提供服务。如果没有优化好冷启动部分，可能一些比较关键的产品首次启动会产生超时，体验非常不好。以前开发者在本地运行函数的时候，并不会关注本地函数执行花了多少毫秒或微秒，但是在云函数场景下就不一样了，云函数有一个部署的过程，无论是在公有云平台上还是[8]在开源方案上，冷启动都是值得不断探讨的话题和优化的方向。
另外，New Relic官方博客上的Understanding AWS Lambda [9]Performance—How Much Do Cold Starts Really Matter？一文曾对AWS Lambda的冷启动时间进行研究和分析，如图1-11所示。图1.11 AWS冷启动时间
可以看到，大部分请求都落在了50ms以内，但是还有很多请求超过100ms甚至150ms，这也充分说明了冷启动问题的存在。在这篇文章中作者只对AWS Lambda进行了冷启动的分析和研究，但是实际上不同厂商对于冷启动的优化程度是不同的，以文章Serverless：
试读结束[说明：试读内容隐藏了图片]