随着时间的推移，Serverless 架构变得越来越火热，凭借着极致弹性、按量付费、低成本运维等特性，在很多领域发挥着越来越重要的作用；机器学习领域在近些年也非常火热，并在越来越多的行业中得到应用。

实际上，机器学习项目中一直存在两大难题：

• 资源占用率高、利用率低，尤其在流量波峰和波谷差值较大的项目中，资源浪费更为显著；
• 部署、更新、维护复杂度高；

而 Serverless 具有极致弹性、按量付费、低成本运维等特性，若将 Serverless 架构应用在机器学习项目中，在保证机器学习项目性能的同时，降低成本，又能提高资源利用率，是非常值得研究和探索的课题。

前言

本书是一本关于 Serverless 架构下机器学习实战的技术书，通过对 Serverless 架构的基础介绍、项目开发经验总结，以及常见的机器学习算法、模型、框架的学习，对将机器学习项目应用到 Serverless 架构、不同机器学习项目与 Serverless 架构结合以及基于 Serverless 架构进行机器学习应用开发等内容进行了探索。

我们希望通过简单明了的语言、真实的案例，以及开放的源代码，为读者介绍 Serverless 架构与机器学习相关的基础知识。希望读者可以通过本书真正理解 Serverless 架构与机器学习结合的重要价值，并能顺利在 Serverless 架构下开发、上线机器学习项目，从而更加直接地获得云计算带来的技术红利。

本书不仅有基础理论知识，还有大量的经验分享，以及对最新技术点的实践应用，包括但不限于 Serverless 架构下 GPU 实例的上手、多维度的冷启动优化方案、Serverless 架构多模调试能力等。

我们希望读者通过对本书的学习，可以对 Serverless 架构有一个更加全面、直观的了解，对 Serverless 架构下的机器学习有更加深入的认识。同时，希望通过本书的抛砖引玉，帮助读者将机器学习项目在 Serverless 架构下落地，获得云计算发展的技术红利。

初识 Serverless 架构

本章通过对 Serverless 架构概念的探索，对 Serverless 架构的优势与价值、挑战与困境进行分析，以及 Serverless 架构应用场景的分享，为读者介绍 Serverless 架构的基础内容。通过本章的学习，读者将对 Serverless 架构的理论基础有一定的了解和认识。

Serverless 架构的概念

随着云服务的发展，计算资源被高度抽象化，从物理机到云服务器，再到容器服务，计算资源逐渐细腻化。

2012 年，http://Iron.io 的副总裁 Ken Form 在 “Why The Future of Software and Apps is Serverless” 一文中首次提出了无服务器的概念，并指出 “即使云计算已经逐渐兴起，但是大家仍然在围绕着服务器转。不过，这不会持续太久，云应用正在朝着无服务器方向发展，这将对应用程序的创建和分发产生重大影响”。

2019 年，UC Berkeley 发表论文 “Cloud Programming Simplified: A Berkeley View on Serverless Computing”。在文章中，作者犀利断言 “新的 BaaS 存储服务会被发明，以扩展在 Serverless 计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择特性。基于 Serverless 计算的价格将低于 ServerFul 计算，至少不会高于 ServerFul 计算。Serverless 计算一旦取得技术上的突破，将会导致 ServerFul 服务的下滑。Serverless 将会成为云时代默认的计算范式，将会取代 ServerFul 计算，这也意味着服务器—客户端模式的终结”。

Serverless 架构从 2012 年首次走进大众视野到 2019 年成为 UC Berkeley 对云计算领域犀利断言的主角，完成了从一个 “新的观点” 向 “万众瞩目的架构” 转身。在这 7 年时间里，Serverless 架构从鲜为人知到被商业化应用，再到头部云厂商纷纷布局 Serverless 架构作为云计算战略，逐渐成为人尽皆知的新技术范式。

当然，在这 7 年间，Serverless 不仅仅在技术架构方面逐渐升级和完善，概念也越来越明确，发展方向也逐渐清晰、明朗。关于 Serverless 的定义，Martin Fowler 在 “Serverless Architectures” 一文中指出 Serverless 实际上是 BaaS 与 FaaS 的组合。

这个简单明了的定义为 Serverless 架构组成结构奠定了基础。如图 1-1 所示，Martin Fowler 认为，在 Serverless 架构中，应用的一部分服务器端逻辑依然由开发者完成，但是和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短（甚至只有一次调用）、完全由第三方管理，这种情况被称为 Functions as a Service（FaaS）。

除此之外，Serverless 架构还要有部分依赖第三方（云端）应用或服务来管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用（单页应用或者移动端 App），建立在云服务生态之上，包括数据库（Parse、Firebase）、账号系统（Auth0、AWS Cognito）等，而这些服务最早被称为 Backend as a Service（BaaS）。

1-1 Serverless 架构组成结构

同样认为 Serverless 是 FaaS 与 BaaS 结合而成的 CNCF 在 CNCF WG-Serverless Whitepaper v1.0 中对 Serverless 架构的定义进行了进一步完善：Serverless 是指构建和运行不需要服务器管理的应用程序概念；它描述了一种更细粒度的部署模型，其中将应用程序打包为一个或多个功能模块，上传到平台，然后被执行、扩展和计费，以响应当时确切的需求。

与此同时，2019 年 UC Berkeley 的文章 “Cloud Programming Simplified: A Berkeley View on Serverless Computing” 中同样从 Serverless 架构特性角度，对什么是 Serverless 进行了补充描述和定义：简单地说，Serverless = FaaS + BaaS，必须具备弹性伸缩和按量付费的特点。

在中国信息通信研究院（以下简称“信通院”）云原生产业联盟所发布的《云原生发展白皮书（2020 年）》中对 Serverless 的概念也有相关的描述：无服务器（即 Serverless）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。

这种架构体系消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂度，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑开发上。

至此，Serverless 架构从结构、行为以及特性方面的定义可以总结为图 1-2。

1-2 从不同角度对 Serverless 架构进行定义

Serverless 架构的特点

众所周知，事物具有两面性。时至今日，云计算的发展已经取得了巨大的进步，但是作为云计算最新产物的 Serverless 架构，在巨大的优势背后，仍然面临着不可忽略的挑战。

• 优势与价值

亚马逊 AWS 首席云计算技术顾问费良宏曾说：今天大多数公司在开发应用程序并将其部署在服务器时，无论选择公有云还是私有的数据中心，都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等，并需要部署、运行应用程序和依赖的软件到基础设施之上。

假设不想在这些细节上花费精力，是否有一种简单的架构能够满足这种需求？时至今日，伴随 Serverless 架构逐渐 “走进寻常百姓家”，答案已经很明显了。

在项目上线过程中，我们一般需要申请主机资源，这时候需花很多时间和精力去评估峰值最大开销，即使给某些服务按照最大消耗申请资源，也要有专人在不同时间段进行资源的扩容或缩容，以达到保障业务稳定与节约成本的平衡。

对于一些服务来说，有时候申请的资源还需要在最大开销基础上评估，即使可能出现很多流量波谷，并产生大量的资源浪费，也不得不这样做，比如数据库这种很难扩展的应用就是 “尽管浪费资源也比峰值到来时应用程序因为资源不足而无法服务好”。

正如费良宏所说，在 Serverless 架构下，这个问题得到了比较好的解决，不用计划到底需要使用多少资源，而是根据实际需要来请求资源，根据使用时间来付费，根据每次申请的计算资源来付费，且让计费的粒度更小，更有利于降低资源的开销。

Serverless 架构具有 6 个潜在优势：

• 按需提供无限计算资源。
• 消除云用户的前期承诺。
• 根据需要在短期内支付使用计算资源的能力。
• 大规模降低成本。
• 通过资源虚拟化简化操作并提高利用率。
• 通过复用来自不同组织的工作负载来提高硬件利用率。

相对于传统架构，Serverless 架构确实具备业务聚焦、弹性伸缩、按量付费等优势。这些优势往往是开发者在技术选型时的重要参考。

1. 业务聚焦

所谓的业务聚焦，指的是让开发者将更多精力放在自身的业务逻辑之上，而不需要再花费更多精力关注底层资源。

众所周知，单体架构时代应用比较简单，物理服务器的资源足以支撑业务的部署。随着业务的复杂程度飙升，功能模块复杂且庞大，单体架构严重阻塞了开发部署的效率。于是，业务功能解耦，可并行开发和部署单独模块的微服务架构逐渐流行开来。业务的精细化管理不可避免地推动着基础资源利用率的提升。

如图 1-3 所示，虚拟化技术不断被完善和广泛运用之后，打通了物理资源隔阂，减轻了用户管理基础架构的负担。容器和 PaaS 平台则进一步抽象，提供了应用的依赖服务、运行环境和底层所需的计算资源。这使得应用的开发、部署和运维的整体效率再度提升。Serverless 架构则将计算抽象得更加彻底，将应用架构堆栈中的各类资源的管理全部委托给平台，免去基础设施的运维，使用户能够聚焦高价值的业务领域。

1-3 虚拟机、容器、Serverless 架构演进简图

2. 弹性伸缩

所谓的弹性伸缩，指的是可以根据业务流量波动，自动进行资源的分配和销毁，以最大限度地实现平衡稳定、高性能以及提高资源利用率。

众所周知，从 IaaS 到 PaaS 再到 SaaS 的过程中，去服务器化越来越明显。到了Serverless架构，去服务器化已经上升到一个新的高度。相对于 ServerFul 而言，Serverless 对业务用户强调的是 Noserve r的心智。

所谓的 Noserver，不是说脱离了服务器或者说不需要服务器，而是去除有关对服务器运行状态的关心和担心，这也就意味着原先需要对服务器进行扩容和缩容的操作也都不再需要业务人员关注了，都交给云商场进行管理。如图 1-4所 示，折线为一个网站在某天的流量走势。

1-4　传统云主机架构与Serverless架构弹性模式下流量与负载对比示意图

图 1-4a 的分析如下：

• 技术人员需要对网站资源用量进行评估，评估结果是这个网站最大的流量峰值为 800PV/小时，所以购买了对应的云服务器。
• 但是在当天的 10 时，运维人员发现网站流量突然增加，逐渐临近 800PV/小时。此时，运维人员在线上购买了一台新的云主机并进行了环境的配置，最后在 Master 机器上添加了对应的策略，度过了 10～15 时的流量峰值。
• 过了 15 时，运维人员发现流量恢复正常，对后加入策略的云主机进行停止，并将额外的资源释放。
• 到了 18 时，再次发现过载流量的到来……

从图 1-4b 可以清晰地看到，负载能力始终和流量是匹配的（当然，这个图本身存在一定问题，即真实的负载能力在一定程度上可能略高于当前流量），即并不需要像传统云主机架构那样在技术人员的干预下应对流量的波峰和波谷，其弹性能力（包括扩容和缩容）均由云厂商提供。

通过对图 1-4 的分析不难看出，Serverless 架构所具备的弹性能力在一定程度上来源于厂商的运维技术支持。

Serverless 架构所主张的 “把更专业的事情交给更专业的人，让开发者更加专注自身的业务逻辑即可”，在弹性模式上也是一个非常直观的体现。

3. 按量付费

所谓的按量付费，指的是 Serverless 架构支持用户按照实际的资源使用量进行付费，可以最大限度提高用户侧资源使用效率，降低成本。

在传统云主机架构下，服务器一旦被购买和运行，就在持续消耗资源，并且持续产生费用。尽管每台服务器的可用资源是有限的，通常也是固定的，但是服务器每时每刻的负载是不同的，资源使用率也是不同的，这就导致传统云主机架构下，会比较明显地产生一定的资源浪费。

一般情况下，白天资源利用率相对较高，资源浪费少一些；夜间资源利用率较低，资源浪费会相对高一些。按照《福布斯》杂志的统计，商业和企业数据中心的典型服务器仅提供 5%～15% 平均最大处理能力的输出，这无疑证明了刚刚对传统云主机架构的资源使用率和浪费程度分析的正确性。

Serverless 架构则可以让用户委托服务提供商管理服务器、数据库和应用程序，甚至逻辑。这种做法一方面减少了用户自己维护的麻烦，另一方面用户可以根据自己实际使用的粒度进行成本的支付。

对于服务商而言，它们可以将更多的闲置资源进行处理。这从成本、“绿色” 计算角度来说，都是非常不错的。

1-5　传统云主机架构与 Serverless 架构弹性模式下流量与费用支出对比示意图

如图 1-5 所示，折线为一个网站在某天的流量走势图。

图 1-5a 是传统云主机架构下流量与费用支出示意图。通常，业务在上线之前是需要进行资源使用量评估的。工作人员在对该网站的资源使用量评估之后，购买了一台可以承受每小时最大 1300PV 的服务器。

在一整天内，这台服务器所提供的算力总量为阴影面积，所需要支出的费用也是阴影面积对应算力的费用。但是很明显可以看出，真正有效的资源使用与费用支出仅仅是流量曲线下的面积，而流量曲线上方的阴影部分则为资源损耗与额外的支出部分。

图 1-5b 是 Serverless 架构弹性模式下费用支出示意图。可以清晰地看到，费用支出和流量基本是正比关系，即当流量处于一个较低数值时，对应的资源使用量是相对较少的，对应的费用支出也是相对较少的；当流量处于一个较高数值时，资源使用量和费用支出为正相关增长。

在整个过程中，可以清晰地看出 Serverless 架构并未像传统云主机架构样产生明显的资源浪费与额外的成本支出。

通过对图 1-5 的分析，不难看出 Serverless 架构所具备的弹性伸缩能力与按量付费模型进行有机结合，可以最大限度地避免资源浪费、降低业务成本。

4. 其他优势

除前面所说的业务聚焦、弹性伸缩、按量付费等优势，Serverless 架构还具备其他优势：

• 缩短业务创新周期：由于 Serverless 架构在一定程度上是 “云厂商努力做更多，让开发者更关注自身的业务” 的模式，因此我们可以认为开发者将会付出更少的时间、精力在 ServerFul 架构所需要关注的 OS 层面、云主机层面、系统环境层面，更专注自身的业务逻辑，这带来的直接效果就是提高项目的上线效率、降低业务的创新周期、提高研发交付速度。
• 系统安全性更高：虽然 Serverless 架构在一定程度上有一种 “黑盒” 即视感，但正因为如此，Serverless 架构往往不会提供登录实例的功能，也不会对外暴露系统的细节。同时，操作系统等层面的维护也都交给云厂商，这意味着在一定程度上 Serverless 架构是更加安全的：一方面表现在 Serverless 架构只对外暴露预定的，且需要暴露的服务和接口，相对云主机在一定程度上免去了被暴力破解的风险；另一方面表现在云厂商有 更加专业的安全团队和服务器运维团队来帮助开发者保障整体的业务安全与服务稳定。
• 更平稳的业务变更：Serverless 架构是由云服务商提供的一种天然分布式架构，同时又因为 Noserver 的特性免除了开发者对服务器运行状态的关心和担心，所以在 Serverless 架构下，开发者对业务代码、配置的变更操作非常简单，只需要通过云厂商所提供的工具进行更改即可，待新的业务逻辑平稳生效后则不再需要开发者关注。所以，Serverless 架构在业务的平滑升级、变更、敏捷开发、功能迭代、灰度发布等多个层面有着极大的优势。

当然，即使上面已经举例说明了很多 Serverless 架构的优势，我们仍然没办法枚举出其全部的优势和价值。但不可否认的是，Serverless 架构正在被更多人关注，也正在被更多团队和个人所接受和应用，其价值已快速突显出来。

原文链接

本文为阿里云原创内容，未经允许不得转载。