课时1：初识 Serverless（上）

玩转AIGC训练营：课时1：初识 Serverless（上）

课程地址：https://developer.aliyun.com/trainingcamp/1893257e5f7a442c988fd52c818309b3?spm=a2cwt.28237621.J_9603273760.8.31b2b726xTbsZG

初识 Serverless (上)

 

内容介绍

一、云计算的发展史

二、 云与Serverless

三、架构对比

四、工作流程

五、核心价值

六、面临挑战

 

很高兴能与大家分享关于初时的内容。

在开始分享之前，我先简单介绍一下自己。我的名字是刘宇，也叫江昱。国防科技大学电子信息专业在读博士，硕士毕业于浙江大

学软件工程专业;阿里云Serverless产品经理，阿里云函数计算、Serverless工作流等产品负责人，开源项目Serverless Devs项目发起人、负责人;《Serverless架构:从原理、设计到项目实战》《Serverless工程实践:从入门到进阶》等出版物作者，InfoQ电子书《架构师特刊:人人都能学会的Serverless实践》作者;阿里巴巴Serverless布道师，CIO学院特聘讲师;社区项目Anycodes在线编程负责人;开源项目ServerlessFramework社区贡献者之一;曾在腾讯等公司做后台研发工程师，产品经理等工作。

一、云计算的发展史

 

 

 

首先，让我们来探讨一下云计算。你可以看到一张图和三个关键词，HDFS，MapReduce，Hbase。我想问一下，对于这张图和这三个关键词，大家有什么感觉或印象这张图显示的是一台计算机，被认为是世界上第一台计算机，而右边的三个关键词分别对应着谷歌发表的三篇经典论文。

正是因为这三篇论文，云计算才开始快速发展。所以，从尼克到谷歌的三篇经典论文，计算机科学与技术一直在不断前进。

进入云计算时代后，计算机科学与技术的发展进展迅猛。这也表明，谷歌的三篇经典论文为云计算带来了强大的推动力。

 

二、云与Serverless

 

 

云计算是一个多义词，不同人对它有不同的理解和认知。学术界和工业界对云计算的定义也有所不同。

通过云计算的发展历程、事件以及相关论文，我们可以更好地理解云计算的本质。

· 1961年，麻省理工学院百周年纪念典礼上，约翰·麦卡锡(1971年图灵奖获得者)第一次提

出了“UtilityComputing”的概念，这个概念可以认为是云计算的一个“最初的”，“超前的”遐想模型，它翻译成现今的大意就是:计算机在未来，将变成一种公共资源，会像生活中的水、电、煤气一样，被每一个人使用。

· 1996年，康柏(Compaq)公司的一群技术主管在讨论计算业务的发展时，首次使用了Cloud Computing这个词，并认为商业计算会向CloudComputing的方向转移。这也是“云计算”从雏形到正式被提出的基本过程。

· 2009年，UC Berkeley发表了:Above the Clouds:A Berkeley View of Cloud Computing,在该文章中，明确指出:云计算是一个即将实现的古老梦想，是计算作为基础设施这一长久以来梦想的新称谓，它在最近正快速变为商业现实。在该文章中，明确的为云计算做了定义:云计算包含互联网上的应用服务及在数据中心提供这些服务的软硬件设施。

 

 

UC Berkeley还提出了云计算所面临的10个挑战，包括服务可用性、数据丢失、数据安全性和可审计性等。这些问题实际上也代表了云计算的机遇。

总的来说，云计算的定义和理解随着时间的推移逐渐明晰，它已成为计算领域的重要发展方向。

这个观点强调了云计算领域的一个重要趋势，即向无服务器架构发展。无服务器架构是指应用程序的创建和分发不再需要关注服务器的管理和配置，而是由云服务提供商来承担这些任务。这种趋势对应用序开发和分发产生了深远的影响。

“无服务器方向”这个术语在这个背景下变得非常重要，它描述了这一趋势。亚马逊在2014年推动了无服务器计算的商业化，使其变得更加普及。2016年的伦敦大会进一步强调了这一趋势，并提出了发展机会和挑战。

总的来说，无服务器计算是云计算领域的一个重要发展趋势，尽管在2012年提出，但在商业化方面的发展逐渐加速，对应用程序开发和分发产生了深刻影响。虽然这个概念不是全新的，但它在云计算领域的快速发展使其成为一个重要的话题。

这个观点强调了云计算领域的一个重要趋势，即向无服务器架构发展。无服务器架构是指应用程序的创建和分发不再需要关注服务器的管理和配置，而是由云服务提供商来承担这些任务。这种趋势对应用程序开发和分发产生了深远的影响。

“无服务器方向”这个术语在这个背景下变得非常重要，它描述了这一趋势。亚马逊在2014年推动了无服务器计算的商业化，使其变得更加普及。2016年的伦敦大会进一步强调了这一趋势，并提出了发展机会和挑战。

总的来说，无服务器计算是云计算领域的一个重要发展趋势，尽管在2012年提出，但在商业化方面的发展逐渐加速，对应用程序开发和分发产生了深刻影响。虽然这个概念不是全新的，但它在云计算领域的快速发展使其成为一个重要的话题。

 

无服务器计算的发展历程，包括它在2006年和2011年之前已经存在，但没有被正式命名。随着2014年的商业化，它开始迅速发展。在2016年，在全球举办了大会，全球各大云厂商都投入资源布局无服务器架构，包括IBM、谷歌、微软等。2017年，国内云厂商也开始部署相关服务和布局无服务器计算平台，具有里程碑的意义，这个发展是一个逐渐变快的一个过程。

关于无服务器计算和架构的定义，你提到了在业界没有一个明确的定义，不同人可能会给出不同的解释。这是一个复杂且快速发展的领域，因此确切的定义可能会随着时间和技术的演进而变化。

总之，无服务器计算是一个重要的技术趋势，它正在改变应用程序开发和分发的方式，使开发者能够更专注于代码编写而不必担心底层服务器管理。

 

 

Martin Fowler在ServerlessArchitectures一文中认为Serverless

实际上是BaaS与FaaS的组合

· Serverless最早用于描述那些大部分或者完全依赖于第三方

(云端)应用或服务来管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用(单页应)用或者移动端App)，建立在云服务

生态之上，包括数据库(Parse Firebase)、账号系统(Aut

th0、AWS Cognito)等。这些服务最早被称为“(Mobile)Backendasa Service”，下文将对此简称为“BaaS”。

· Serverless还可以指这种情况:应用的一部分服务端逻辑依然

然由开发者完成，但是和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短(甚至只有一次调用)、完

全由第三方管理。这种情况称为Functionsasaservice/FaaS。AWS Lambda是目前的热门FaaS实现之一。

因此，目前从结构的角度来看，这个领域主要由函数服务和后端技术服务组成，如数据库和账号系统。在2019年，UC博客发表了一篇文章，肯定了从结构的角度对架构进行定义是合适的，同时也认同了这种说法。然后，他从特性的角度给出了一个新的定义，即架构被看作是Serverless的服务，必须具备弹性伸缩和按需付费的特性。

总的来说，我认为架构可以从两个角度来定义，一个是从结构，一个是从特性。在之前提到的UC博客的文章中，云计算的经典文章提出了云计算将引领下一个时代的观点，而后来的文章则认为这个时代包括了UC博客这个学派。

UC博客在对新技术或架构的结构上有不同的观点。最初，他们可能认为架构是一种新的计算模式，虽然推动了整个行业的发展，但实际上是在后退，开了历史的倒车。

然后，他们认为架构不是改变传统计算的新架构，而是颠覆传统计算范式的新计算范式。UC博客在一些观点上也有一些转变。他们提到架构向前迈出了一步，通过提供自动缩放功能，云编程方面的产品取得了一定进展。它提供了一个实际上可管理的、看似无限的计算平台。但他们也认为架构实际上是在开启历史的倒车，因为它们忽略了高效数据处理的重要性，并阻碍了分布式系统的开发。

总之，在学术界中，UC博客对架构的观点一开始并不看好，但经过一段时间的研究和深入思考，他们提出了架构真相符合的一个真相定律。在接下来的一年中，他们发表了一篇关于架构观点的新论文，其中提出了一些激进的观点，包括基于Severless计算的价格将低Severful于计算，至少不会高于计算。

 

2019年UCBerkeley的文章Cloud ProgrammingSimplified:ABerkeleey View on Serverless Computing中也肯定了这一描述:简单地Serverless=FaaS+BaaS。在对于被认人为是Serverless的服务，它必须具备弹性伸缩和按量付费的特点。(Put simplyserverless computing=FaaaS + BaaS. In our definition,for aservice to be considered serverless, it must scale automatically with no need for explicit provisioning,and be billed based on usage.)

 

 

Serverless Computing:One Step Forward,Two Steps Back

One Step Forward :

通过提供自动缩放功能，今天的FaaS产品在云编程方面迈出了一大步，它提供了一种实际上可管理的，看似无限的计算平台。

Two Steps Back:

首先，他们忽略了高效数据处理的重要性;其次，它们阻碍了分布式系统的开发。

Cloud Programming Simplified:A Berkeley View on Serverless Computing

新的BaaS存储服务会被发明，以扩展在Serverless计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择。

比现有的x86微处理器更多的异构计算机。

更加安全、易用的编程，不仅具有高级语言的抽象能力，还有很好的细粒度的隔离性。

基于Serverless计算的价格将低于Serverful计算，至少不会高于Serverful计算。

Serverless将会接入更多的后台支撑服务，如OLTP数据库、消息队列服务等。

Serverless计算一旦取得技术上的突破，将会导致Serverful服务的下滑。

Serverless将会成为云时代默认的计算范式，将会取代Serverful计算，因此也意味着服务器-客户端模式的终结。

因此，这个领域非常激进，最后一条观点是架构将成为云时代的默认计算范式，将替代所有计算，这也意味着服务器客户端模式的终结。虽然在最初，UC博客对云计算的发展持保留态度，但最终他们认可了云计算成为默认计算范式的可能性。从他们的态度变化中可以看出，架构具有巨大的潜力，只要我们深入研究和探索。架构不仅在学术研究中有高度的价值，也在推动整个行业的发展和进步中起到了重要作用。

在之前，我们讨论了云计算的定义、发展历史以及UC博客对架构的看法和观点。

现在，让我们更具体地探讨一下什么是Severless架构。首先，我们可以思考一个问题，你是否曾经创建过在线线上服务，例如个人博客、实验室网站、小程序或其他类型的在线服务,如果是的话，我们可以回顾一下最初的在线服务是什么样的，然后再比较它们与基于架构的形式之间的差异。

 

三、架构对比

 

在传统的Web应用架构中，通常包括客户端、服务端和数据库等元素。在项目开发中，需要购买服务器、选择服务器规格、操作系统、环境配置、服务器软件安装、业务代码上传和监控服务器健康等一系列操作。这些任务需要耗费大量时间和精力。

我们还需要留着团队对服务器的健康进行维护感知，这些流程都是我们需要做的。

然而，在Serverless云原生架构下，整个流程似乎变得更加复杂，但实际上我们可以仔细分析一下。首先，云原生架构中有一个API网关，这个网关扮演了服务器软件的角色，但是它是基于云服务提供的，如阿里云、华为云、百度云、腾讯云等。这些云服务提供了网关，无需我们自己安装服务器软件。这一步可以省略。从左侧过度到右侧，发生了本质的改变，其中包括的网关等业务系统。主张的思想是把更关键的业务交给更关键的人。

接下来，我们考虑架构的其他方面，例如如何处理客户端、API网关以及其他相关元素。

在云原生架构下，我们不再需要关注服务器的购买、规格选择、操作系统配置和服务器软件安装等复杂任务。相反，云服务提供了API网关，这个网关充当了服务器软件的角色。我们可以专注于处理客户端、API网关以及与业务逻辑相关的事项。

所以，云原生架构实际上简化了服务器管理的一些方面，使开发人员可以更专注于应用程序的开发和业务逻辑的实现。同时，云服务还提供了弹性伸缩的能力，使应对流量波动更加容易。这是云原生架构的一个关键优势之一。

在云原生架构中，数据库、身份验证和其他基本能力都由云服务提供，无需我们手动配置和管理。我们只需要关注业务逻辑的实现，通常可以通过编写一些函数来完成。这些函数可以包括搜索、数据库操作和其他业务逻辑。

在传统的外部应用架构中，我们需要考虑的范围更广，包括服务器的购买、操作系统配置、服务器软件安装、数据库管理、身份验证、操作系统等等。而在云原生架构下，这些复杂的底层任务都由云服务提供，使我们可以更专注于编写应用程序的核心功能。

这种变化实际上是一种本质的改变，使开发人员能够更快地开发和部署应用程序，同时具备更高的弹性和可伸缩性，以适应不断变化的需求和流量。这是云原生架构的一个关键优势，它使开发更加灵活和高效。

 

四、工作流程

 

 

在进入架构层面时，实际上只需关注我的业务代码即可，正如我们刚才所讨论的那样。如果突然有大量流量涌入，是否会导致我的服务器崩溃。

或者说，你的系统是否存在安全隐患，或者在你的系统中是否存在问题，可能会被用户发现，然后导致我的服务器受到攻击。

实际上，从架构的角度来看，它主张将更专业的事情交给专业人士处理。开发者只需要关注他们自己的业务逻辑即可。因此，对我来说，我确实可以关注更少的事情，从而获得更多的回报。

让我们来看一下整个架构的工作原理。在最左侧是开发者，开发者编写完代码后，可以将其上传到函数计算这样的架构中心。上传后，可以通过API或SDK对其进行调用或触发。

同样，还可以使用一些云产品事件，比如我们刚才提到的API网关，它是一个典型的云产品。在没有请求时，函数不会启动相应的实例。一旦有请求到来，函数将启动相应的实例来处理请求，因此架构具有弹性缩放的概念。底层的服务和服务器运维等操作都由云厂商来处理，因此在安全性和服务器稳定性方面都有更好的保障。

在我们刚才的描述中，传统的服务架构会一直产生费用，只要服务器运行，即使在没有人使用或流量很低的晚上也是如此。但在架构中，当所有东西都部署好后，实际上是不会产生费用的，只有当你的实例被触发或项目运行时，才会收费。

如果你的服务在晚上没有人使用并处于停止状态，那么此时不会产生费用。因此，架构除了具有弹性，还采用按量付费的模式，这也是刚才所提到的两个特点。

Severless具有哪些特点：

这种基本的云产品通常都具备一些基础的安全能力。首先，这是非常基本的，也就是说，在使用云函数之前，云服务本身已经具备了一些基本的安全能力。这是第一点，它可以帮助您保护您的应用。从传统的角度来看，如果您只使用单台服务器，您认为它具备了足够的安全性，或者说，它的安全性主要取决于什么，或许您需要采取一些额外的措施。

在更底层的层面上，云服务提供商通常会对您的实例进行一些上限限制，包括您可以在特定时间段内上线的实例数量。您还可以在一些地方添加白名单或实施一些特殊的逻辑操作等等。

在这个层面上，他们可以帮助防止一些恶意攻击的发生。因此，不管是从外部还是从云产品本身的角度来看，它们都在增强安全性方面采取了一些措施，包括对抗各种攻击手段。可以看的出开发者的事情越来越多，使用者所负担的越来越少。

 

五、核心价值

 

 

刚才我们描述完之后，您认为架构的优点是什么呢？大家可以思考一下，实际上在整个过程中，开发者或开发团队的责任逐渐减少了，而运维团队的工作也在逐渐减少，而云厂商的责任则逐渐增加。

在阿里巴巴内部，有这样一句口号，叫做“把复杂留给自己，把简单留给他人”。

我认为架构在这一方面与阿里的价值观有一定相似性。它将复杂的任务交给云厂商，将简单的任务留给更多的用户和开发者。这是架构交付的一个核心价值，可以总结为降本提效。

云厂商为用户提供了服务器管理、运维等工作，同时提供了数据库、对象存储等后端服务，使用户可以将更多精力放在自身的业务逻辑上。这提高了研发效率，缩短了项目的创新周期。与此同时，用户无需担心服务器运维或基础设施的额外费用支出，也不需要担心更多的运维工作成本。

架构提供了一种灵活的按量付费模型，用户只需按实际使用的资源付费。从交付的角度来看，架构的核心价值在于降低运维成本、降低人力投入成本、提高研发效率、缩短创新周期以及按需付费，从而降低支出成本。

架构的第二个核心价值，总结出了三个词：安全、方便和可靠。

将更多专业领域的事情交给专业人员来处理，云架构将服务器运维和安全相关工作交给云厂商来处理。

实际上，很多服务器运维和安全领域的工作对于许多用户来说难以做得更好，将这些任务交给云厂商在某种程度上增强了自身业务的稳定性。一旦交给云厂商处理，架构可以大规模提升整个项目的稳定性，同时，架构相对于其他架构来说更加简单。

尽管刚才的图表可能看起来更复杂，但实际上它更加简单，因为外部这些组件已经由云厂商提供，无需自行构建。这意味着用户需要管理的组件更少，这使得项目管理更加简便。此外，架构具备弹性能力，能够自动扩展，以适应流量的增加和减少，从而确保业务的安全和稳定。

专业的团队为用户提供安全性能保障，使架构具备以下五个特点：安全风险更低、资源开销更小、符合绿色计算思想、更加方便管理、弹性扩展符合需求。在这里，有一个相对抽象的术语，即符合绿色计算思想。

实际上，现在国家和全球都在强调资源的可持续性、环境友好性和资源节约。

架构在一定程度上完全符合这种思想和模式。首先，让我们思考一下，如果每个人都有自己的服务器或实验室拥有服务器，那么这些服务器的资源利用率通常是多少，综合资源利用率是多少，服务器的资源利用率在10%以下的时间有多少，达到80%以上的时间有多少，是否曾经达到100%，有多少次，通过这种思考，我们可以发现，通常情况下，服务器的资源利用率非常低。

但是，架构在一定程度上帮助用户提高资源利用率。如果您花100块钱购买了一台服务器，然后这台服务器一直在运行，即使在某个时间点上，它的资源利用率只达到10%，那么您实际上浪费了90%的资源。但架构不同，它根据实际使用的资源来收费。

如果您使用了10%的资源，您只需支付10%的费用；如果您使用了50%，您只需支付50%的费用。因此，架构在一定程度上希望让用户的支出与他们所获得的资源利用之间达到平衡，这也符合绿色计算思想。

 

 

基本上，这就是架构所提供的三个核心价值：快速交付、毫秒弹性、更低成本。刚才还提到了架构面临的挑战，以及它的一些优势，包括提高效率、提高安全性和稳定性、更高效。

 

六、面临挑战

 

 

 

 

实际上，任何技术架构的发展都有其利弊，包括架构本身。尽管架构具有许多优点，吸引了许多人关注并将他们的业务迁移到架构上，但它也面临着挑战，正如我们刚才讨论的云计算一样。尽管云计算被认为可能引领下一个十年的发展，但它也伴随着一些挑战和问题，架构也不例外。

根据我们刚才的描述，架构的一个特点是弹性伸缩。当一个请求到达时，架构会创建一个实例来处理它。这意味着它包括了一个资源准备的过程。

让我举一个具体的例子来说明，假设我向张三发出请求，要求他运行一个程序。在第一种情况下，张三可以立即运行程序，因为他的资源已经准备好，这类似于本地函数调用。而在第二种情况下，张三需要开启电脑、输入密码、下载文件、配置环境、加载代码和依赖项，然后才能执行程序。

这个过程就是资源准备，而架构下可能会面临资源准备时间较长的问题，即启动时间较长。这会导致业务的延迟较高，相对于传统方式，第一次请求的处理可能需要更多的时间，这对于许多业务来说不太友好。

因此，启动时间包括了一系列操作，如初始化工作空间、下载文件、配置环境、加载代码和依赖项，最后才能执行函数。

当资源准备好时，函数可以直接执行。因此，启动时间在架构中是一个重要的因素。在刚才的描述中，我提到了一个具体的词汇，即首次启动时的“冷启动”，我们可以进一步探讨这个概念。

 

 

在这张图上，首次启动的定义需要考虑一些因素。首次启动通常指的是函数实例第一次启动的情况。但是如果你在一段时间后再次请求函数，它是否仍然被认为是首次启动，这涉及到实例的释放时间。在实例释放之前，如果再次请求函数，它可以被复用，因此响应时间会非常短。但是如果实例已经释放，并且过了冷却时间，当再次请求时，它将被认为是冷启动。

 

 

除了冷启动问题，不同云厂商在事件触发器的数据结构上也存在差异。事件触发器是指函数计算通过云服务或API网关等方式触发的事件。

不同云厂商的事件数据结构不同，这会导致业务逻辑在接入层面发生变化，这是架构的一个明显劣势。它使得厂商锁定问题变得更严重，一旦在一个云厂商上部署，很难切换到另一个云厂商，这是架构的一个不受欢迎之处。

总的来说，架构有许多优点，但也存在挑战和劣势，包括启动时间问题和跨云厂商的兼容性问题。