共计 6863 个字符，预计需要花费 18 分钟才能阅读完成。
作者：Serverless
随着工夫的推移，Serverless 架构变得越来越炽热，凭借着极致弹性、按量付费、低成本运维等个性，在很多畛域施展着越来越重要的作用；机器学习畛域在近些年也十分炽热，并在越来越多的行业中失去利用。
实际上，机器学习我的项目中始终存在两大难题：
- 资源占用率高、利用率低，尤其在流量波峰和波谷差值较大的我的项目中，资源节约更为显著；
- 部署、更新、保护复杂度高；
而 Serverless 具备极致弹性、按量付费、低成本运维等个性，若将 Serverless 架构利用在机器学习我的项目中，在保障机器学习我的项目性能的同时，降低成本，又能进步资源利用率，是十分值得钻研和摸索的课题。
基于此，由阿里云官网出品，来自阿里云、蚂蚁团体的 4 位专家刘宇、田初东、卢萌凯、王仁达（排名不分先后）零碎梳理阿里在 Serverless 架构下的 AI 教训，联袂推出新书 《Serverless 架构下的 AI 利用开发：入门、实战与性能优化》。
前言
本书是一本对于 Serverless 架构下机器学习实战的技术书，通过对 Serverless 架构的根底介绍、我的项目开发经验总结，以及常见的机器学习算法、模型、框架的学习，对将机器学习我的项目利用到 Serverless 架构、不同机器学习我的项目与 Serverless 架构联合以及基于 Serverless 架构进行机器学习利用开发等内容进行了摸索。
咱们心愿通过简单明了的语言、实在的案例，以及凋谢的源代码，为读者介绍 Serverless 架构与机器学习相干的基础知识。心愿读者能够通过本书真正了解 Serverless 架构与机器学习联合的重要价值，并能顺利在 Serverless 架构下开发、上线机器学习我的项目，从而更加间接地取得云计算带来的技术红利。
本书不仅有基础理论常识，还有大量的教训分享，以及对最新技术点的实际利用，包含但不限于 Serverless 架构下 GPU 实例的上手、多维度的冷启动优化计划、Serverless 架构多模调试能力等。
咱们心愿读者通过对本书的学习，能够对 Serverless 架构有一个更加全面、直观的理解，对 Serverless 架构下的机器学习有更加深刻的意识。同时，心愿通过本书的抛砖引玉，帮忙读者将机器学习我的项目在 Serverless 架构着落地，取得云计算倒退的技术红利。
初识 Serverless 架构
本章通过对 Serverless 架构概念的摸索，对 Serverless 架构的劣势与价值、挑战与窘境进行剖析，以及 Serverless 架构利用场景的分享，为读者介绍 Serverless 架构的根底内容。通过本章的学习，读者将对 Serverless 架构的实践根底有肯定的理解和意识。
Serverless 架构的概念
随着云服务的倒退，计算资源被高度抽象化，从物理机到云服务器，再到容器服务，计算资源逐步细腻化。
2012 年，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 架构正在被更多人关注，也正在被更多团队和集体所承受和利用，其价值已疾速突显进去。
点击此处，查看函数计算 FC 更多详情！
