云原生环境下研发综合效能提升探索（上） | 学习笔记

开发者学堂课程【第八届大学生创新创业大赛阿里命题云原生命题培训：云原生环境下研发综合效能提升探索（上）】学习笔记，与课程紧密连接，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1044/detail/15204

云原生环境下研发综合效能提升探索（上）

内容介绍：

一、从云计算到 Serverless

二、Serverless 架构及应用场景

从 Serverless 到 Serverless Devs 云原生环境下研发综合效能提升的探索就是本次技术研读班的课程的一些内容。近些年来，云计算的发展是飞速的，云原商的概念也被炒得火热，Serverless 的架构更是被 UC·伯克利认为是云时代的默认编程范式。所以今天将会以此作为切入点，和大家一起分享在 Serverless 架构的发展以及带来的技术红利。最后，也会和大家分享开源项目 Serverless Devs 工具链项目。

将会从以下三个部分来进行，分别是从云计算到 Serverless、Serverless 架构及应用场景，还有 Serverless Devs 让 Serverless 更好用。

一、从云计算到 Serverless

第一个部分是从云计算到 Serverless 架构。

这张是 ENIAC，是世界上第一台通用计算机，自从其诞生以来，计算科学与技术的发展就从未停止过前进的脚步，尤其是近些年来，计算机的发展更是日新月异，有不断突破和进化的人工智能领域，有5G 带来更多机会的物联网领域，还有可信的区块链技术，也有不断更新、不断迭代、不断走进寻常百姓家的云计算。

HDFS、MapReduce、Hbase 三个关键词，是2003年到2006年之间，谷歌所发表的三篇重要论文，这些文章指明了 HDFS 分布式文件系统，还有 mapreduce 并行计算和 Hbase 分布式数据库的技术基础，以及未来的机会，至此，也奠定了云计算的发展方向。关于这三个文章或者是三个技术点，有人曾经说，正是因它们，云计算才得以正式拉开帷幕。

云计算的发展是飞速的，也是有目共睹的，但是，随着云计算的发展，另外一个名词又悄然的诞生了，并且迅速的夺去了风口大旗，被更为广泛的关注，就是云原生。云原生实际上就是在云与计算之间增加了一个 native，所以可以认为，云计算的飞速发展，无论是从技术迭代还是从概念升级，最终产生了耳熟能详的也是目前炒得火热的云原生。

什么是 Serverless 架构？无论是中文还是英文，在很多时候都有看其字就能明白其含义的样的可能或者效能，或许就叫顾名思义。通过 Serverless 的结构，不难发现它所要传递的一个心智，Server 指的是服务器，Less 指的是更少的经历，所以 Serverless 架构所传递的心智是把更专业的事情交给更专业的人，开发者可以更少的关注服务器等底层相关的内容，把更多的精力放在更具价值的业务逻辑之上。翻译成中文之后的名字叫无服务器，让很多人都觉得无服务器是不是不需要服务器了，包括云原生的翻译也不是很好，不是不需要服务器了，而是更少的精力去关注服务器等底层资源。

2009年，UC·伯克利发表了一篇关于云计算的文章，在这篇文章中 UC·伯克利为云计算做出了一个比较明确的定义，同时，也提出了包括服务的可用性、数据的安全性和可审计性等在内的十项云计算所面临的各类困难和挑战，并断言云计算将会引领未来的10年。2019年，也正好恰隔10年的时间，UC·伯克利再次发文，不仅从多个角度说明了什么是 Serverless 架构，例如从结构的角度肯定了 Serverless 是 fass 与 bass 的结合。除此之外，他又说，从特性的角度，对于被认为是 Serverless 架构的产品或者是服务，它还需要具备按量付费和弹性伸缩的特点，并且非常激进的表示，Serverless 将会成为云时代的默认计算范式，将会取代 Serverful 计算，因此，也意味着服务器和客户端模式的终结。他的断言到底是不是对的，在这里不进行更多的评论或者探索，但是，至少通过他这样的更为激进的断言，能感受到这些前辈或者大佬对 Serverless 架构热忱的期望。

从 IaaS 到 pass 再到 Serverless，云计算的发展越来越清晰，也越来越明确，去服务器化也是越来越明显。无论此时是云原生还是 Serverless 架构，云的概念确实都在不断的升级，云的技术也确实都在不断的迭代，而这一切的改变其实都是为了效能的提升，为了安全的提升，为了成本的降低以及生产力的驱动。

二、Serverless 架构及应用场景

接下来，简单的看一下 Serverless 架构及其应用场景。

它包括了两张图，直观来看，左边的图更简单，右边的图可能会稍微复杂一些。其实，这是一个宠物商店网站在传统架构与 Serverless 架构下不同的表现。左侧是传统的 C/S 架构，右侧是 Serverless 架构，简单的来考虑一下，如果要做一个传统的这样的网站或者功能，都需要做哪些事情？包括了开发代码，购买服务器，而且还要清楚要购买多少台，多大的配置，是否要加购，在服务器里面安装各种软件，配置环境，必要的时候还要有分布式架构等一些内容，然后将代码部署到服务器上，业务上线，结束了吗？其实并没有结束，项目在运行的过程中还要有人看着，如果流量比较大的时候，要进行扩容，如果流量降低了，还要进行及时的缩容。

在 Serverless 架构下它是什么样的表现？首先，客户端浏览器这一部分可以先不用管，权限模块有单独的云产品提供能力，也无需额外的操作，数据库也不需要管，原先要在服务器里安装的 nginx 等软件这里有 API 网关这样的产品来解决，只需要填一些表单，配置一下就可以了。其实剩下的只是4和5这样的两个函数，就是业务逻辑，这也就是 Serverless 架构交付的一个非常重要的心智，就是把更专业的事情交给更专业的人，开发者不再关心更多底层的能力，只需要关心自身的业务逻辑就可以了。这样做的好处或者带来的好处是精力的支出更加专一，可以有效的提升业务创新效率，降低产品迭代周期，推进项目快速上线。什么都不用管，流量多少该怎么办？谁来做扩容？谁来做缩容？这就涉及到了函数计算的弹性能力。看这样一张图，

当用户写完代码之后，它可以直接把代码部署到线上。函数计算实际上是通过事件进行驱动的。什么叫做事件？上传 OSS 一个文件，API 网关收到一条请求，往数据库里面写了一条数据的，完成这些事情之后，它都可以认为会产生一个事件，产生的事件会触发函数，函数会根据实际的请求数量进行实例的启动，例如有十个请求，系统可能就会判断需要十个实例，此时，就会有十个实例进行启动。

接下来可能就是收费问题，在 Serverless 架构下，按量付费是非常重要的，只有在使用的时候才收费，在不用的时候基本是免费的。试想一下，你的流量突然变高，有人做弹性，你的流量走低，有人帮你释放掉，这些额外的资源不再收钱，如果业务在三更半夜就没有流量，基本上就是免费的，这种按量付费的模型在一定程度上就是成本的节约。所以，Serverless 架构就是一种新的编程范式，和之前的业务模式或者编程模式基本上是一致的，只是架构有一些微微的变化而已。一个天然分布式架构原先能做的事情，做网站、做后台、做小程序、做音视频处理、做人工智能、函数计算也都可以做，只不过它就是一种天然分布式架构，把它当成一种分布式的架构来看待就和原先没有任何区别了。

再来回顾一下，Serverless 架构是 fass 与 bass 的结合，UC·伯克利还说，对于被认为是 Serverless 架构的产品或者服务，它还需要具备按量付费、弹性伸缩的特点，当然，有些人也会认为这是从狭义上对 Serverless 架构做的定义，还有一些人可能会比较激进或者有一些更多的想法，他们对 Serverless 又给了一个更为广泛的定义，认为在服务端免运维或者是在服务端低运维的技术架构，或者是一种思想，或者是一种开发范式，它也算是 Serverless。所以，不管是从狭义上还是从广义上来说，Serverless 架构所表现出的这种低运维，所表现出的这种弹性伸缩、按量付费的特点，都是它的核心价值或者是所交付的技术红利。

在这里也可能会额外的多加一些内容，我想用一个更为形象的例子或者更为形象的比喻探索 Serverless 架构到底是什么。我们和汽车的关系，可以想一下，其实我们和汽车会有三种关系，第一种关系是买一台汽车，第二种关系是租赁一台汽车，第三种关系，当我们想从 A 到 B，可能会随手叫一台出租车或者拿打车软件叫一台快车，这时会发现一件事，在最原先在买车的条件下需要做很多的事情，包括需要一次性投入很多的钱，要花几十万甚至上百万来买一台车，然后还要关注加油的问题，还要关注车的年检问题，还要关注车上的每一个零部件的问题，所以，这实际上是最原始的或者最原先的一种模式，它就是物理机的模式，原先可能要自己自建机房，或者自己购买服务器，一次性可能要投入很多的东西，自己拉宽带，自己做服务器层面的运维，要做很多的事情，再往后，可能就是一种租车的过程了，当到达一个新的城市之后，假如去旅游想要自驾，不可能到一个城市就买台新车，这个时候就可以租一台车，租一台车和买一台车它的区别是什么？租一台车一次性不需要支出很多的钱，只需要支出少量的钱就可以，所以可以认为就是一个按量付费的过程了。除此之外，也不需要再关注机房有多少台空调，机房的温度是多少，都不需要关注了，租车不再需要关注车的这些底层，只需要关注这台车能不能开，能不能够三天。换算成云计算发展的下一个步骤就是云主机时代，相对于原先的这种模式，不再需要关注机房的温度，不再需要关注这些底层硬件设施，关注的就是服务器，还有自身的业务逻辑。

还有一种模式就是我们和车的另外一种关系，就是来叫一台车，假如今天要上班，不可能为了上班租一台车或者为了上班就从 A 地到 B 地买一台车，可能随手招一台出租车就走了。这个时候需要关注的是什么？甚至连车有没有油都不需要关注，连这台车什么品牌都不需要关注，连这台车能够开多少天也不需要关注，关注的就是它能不能顺利的把我从 A 地送到 B 地，这个时候对应的就是 Serverless 架构，会发现 Serverless 架构本身也是按量付费的，但是云主机好像也可以认为是一种按量付费的过程，但是 Serverless 架构的按量付费的力度会更加的细腻，它甚至可以达到秒级、毫秒级的计费力度，这是一种情况。另外一种情况，就是所关注的内容会更加少了，除了不再需要关注服务器等硬件的资源，甚至连很多的这些服务器等底层的运维工作也不再需要关注了，其实这就是云计算发展的规律，就是去服务器化越来越明显。

这里一张图，分别是关于 Serverless 架构和在传统架构下的弹性伸缩和按量付费的简单描述。在上面这张图是弹性伸缩，可以这样想，蓝色的这条曲线实际上是一天真实的业务流量的曲线，除了蓝色这条曲线，还有黄色的面积，可以认为黄色的面积就是可负载的能力，可以认为这个时候它有一台机器正在运作，流量是这样，当到这个时候，有个运维同学突然发现网站流量突然变高了，是不是有更多人来了？好像一台机器马上就要扛不住了，这个时候他可能就立马再买一台机器来做扩容，扩容之后扛住了这波流量，扛住完之后好像流量现在又稳定下来，它又逐渐的开始往下走了，多开一台机器有点浪费资源，他又把这台机器释放掉了，它会不断的因为流量的多少，来进行一些服务端的运维的操作。

在这张图里会发现一件事，蓝色线以下的黄色面积实际上是真实使用的负载，而蓝色线以上的黄色面积是准备额外的负载，或者是已经被浪费掉的负载。基于 Serverless 架构的弹性伸缩的能力，它在客户端的表现实际上是当来了10个请求，分配10个请求的资源，当来了1个请求，就给分配1个请求的资源，当突然来了1000个请求，给分配1000个请求的资源，所以在 Serverless 架构下是需要多少资源，给分配多少，而相对不会产生冗杂的一些额外的资源的支出，整个扩容和缩容的弹性的过程都是云厂商来提供的，所以 Serverless 架构是一个天然的分布式架构，是一个天然的弹性伸缩的架构，和刚才所说的弹性伸缩是一致的。

下面这个图对应的就是按量付费的过程了，可以认为，当购买一台服务器的时候，服务器只要开机放在那里，不管用没用，它都是在花钱。一个开源社区有一个项目，这个项目要有一些私有化的搭建才能使用，这个时候我就在阿里云上面，因为它这个搭建可能是需要一套集群，还是相对比较传统的，所以只能买一台服务器来做这个事情，买完之后就放在那里，后来发现开源项目没搭建几次，就没用多少、没用多久，就没有再用了，但是服务器一直处于付费的状态，只要在开机，它就一直在付费，不管流量多少，流量少了它就浪费了，流量多了它就爆了，所以它是一直在付费的过程。

在 Serverless 架构下也发生了一个变化，使用了多少资源花多少钱就行，使用多少资源是弹性伸缩来决定的，实际上在 Serverless 架构下，可以认为，在传统架构下，蓝色线以上的黄色部分是额外浪费的钱，而在 Serverless 架构下，至少在客户端或者用户层的感知，好像资源利用率是100%，好像把所有钱都花在了刀刃上，其实，资源利用率是绝对达不到百分百的，资源浪费的点在哪？可以认为，所有额外的资源或者额外的资源池都是云厂商来备的，所以可以认为其实是云厂商在帮助大家来 cover 或者来扛一部分的成本，所以大家才会觉得原来好像是真的就是花了多少资源消耗多少钱，用了多少资源消费多少。所以，这也是 Serverless 架构传递的一种心智，至少在客户端的一种表现，至少给大家的一种表现是能让大家觉得花了多少钱，使用了多少资源。

Serverless 架构除了按量付费，还有弹性伸缩之外，其实 Serverless 架构还有一个非常重要的点，就是效能的提升，可能都会觉得 Serverless 架构所带来的效能提升的价值远远超过弹性伸缩或者按量付费的价值。为什么它会有效能的提升？当把更专业的事情交给更专业的人之后，开发者可以付出更多的精力在自身的业务逻辑之上，不需要再额外的关注其他的一些事情了。

从另一个角度来看，其实就是精力之处更加专业了，所以它带来的效果就是效率更高、质量更好，所以三心二意不如一心一意。举一个比较真实的例子，就是我之前本身也是一个研发，有一个自己的项目，经常在做那个项目的时候，如果要启动一个新的项目的时候，往往搭建这套环境或者把整个开发环境，例如测试环境、线上环境，搭这套环境就需要花费很长的时间，花费很多的精力，但是现在在 Serverless 架构下，很多的流程都已经避免掉了，包括后期的一些运维的工作也都节省掉了，需要关注的就是把业务代码写好就可以了，写好代码就等于项目可以上线了，写好业务逻辑就证明可以让它发挥真正意义上的价值了。大家可以认为很多额外的工作其实都不需要我们做了，所以它的效率自然而然就提升了很多。

不妨进一步想一下，就是 Serverless 架构能做什么，它的应用场景是什么，也可以对标一下自己的场景，看看自己的场景是不是和 Serverless 架构有缘分，能收获一波技术红利，抓紧来收割。在说到 Serverless 架构能做什么之前，可以先来想一个问题，UC·伯克利说，Serverless 架构是云时代的默认计算范式。什么是计算范式？或者能被称为计算范式的东西是什么样子的？再或者能被称为默认计算范式的东西应该是什么样子的？其实，从我的角度，能被称为默认计算范式，其实在一定程度上也表明了 Serverless 架构在一定程度上它是可以做一切事情的，它没有哪个场景能不能做，只有想不想做的一件事情。

所以，无论是实时的文件处理，还是实时流处理，还是机器学习 lOT 后端，再或者是移动应用后端，web 应用场景等等，可以认为 Serverless 架构都可以做。而这一切，在如今的 Serverless 架构上其实都有能拿的出手的一些案例了，例如，

现在所显示的其实是一个常见的音视频处理的场景，通常情况下，如果想要对音视频做一些处理，大家要明确一件事情，就是音视频处理的时候往往会需要消耗大量的资源，在白天处理高峰和在晚上低谷的时候，它的资源的消耗真的是天差地别，这个时候就需要有一个非常大的池子来做这样的事情了。不管是对运维层面的工作，还是对资源的支出，或者是额外成本，还有整个效率，其实都是面临着很大一个挑战，在 Serverless 架构下它是怎么样的表现？可以将这些资源上传到对象存储，通过对象存储触发函数计算，再由函数计算来做一些处理，处理完之后持久化或者反馈给客户端，而函数计算这里的处理，它也可以有很多的优化方案，比如可以单个函数做处理，也可以先用一个函数把视频切片，切片完成之后再分别处理，处理完之后再做合并，所以整个流程会变得非常的简单，非常的清亮。

除此之外，还有一些 AI 的场景，

例如用户他可以发起一个推理的请求，函数计算可以从一些云存储的系统里面加载模型，加载完之后中途也可能会有一些日志的产出，会把一些推理结果返回给用户。

这里是一个常见的 web 应用的场景，当有用户请求网站的时候，到内容分发，到函数计算，然后读取数据，挂载硬盘做一些处理，或者记一些日志做一些处理，再把结果返回给用户。