开发者学堂课程【云原生架构实践：Serverless，云的下一个十年】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1054/detail/15304
Serverless，云的下一个十年
内容介绍：
一、软件工程的本质复杂度和次要复杂度
二、计算的发展历史
三、一个 hello word 单机应用有多简单？
四、一个 hello word分布式应用有多复杂？
五、一个 Helloword分布式应用应该多简单
六、Serverless-云的未来
七、异步处理
八、理想中的异步处理
九、现实中的异步处理系统
十、异步系统技术挑战1-可扩展性
十一、异步系统可扩展性-解耦队列和 Worker 资源
十二、异步系统可扩展性-自适应的请求分发
十三、异步系统可扩展性-基于 Partition的负载均衡
十四、异步系统技术挑战2-GB级镜像实例秒级启动
十五、镜像实例启动性能对比
十六、典型案例：网易云音乐音视频算法服务Serverless化
十七、异步系统总结
十八、误解1-Serverless 架构太新了，没有经过验证
十九、误解2-Serverless 应用需要大量改造，迁移成本高
二十、误解3-Serverless 单价比 ECS 贵太多，成本没有优势
二十一、误解4-Serverless 会导致供应商锁定
一、软件工程的本质复杂度和次要复杂度
Serverless是一个软件开发的手段，首先可以抛开Serverless的概念，思考一下软件开发它要解决的本质问题是什么？实际上，这类根本的问题，在很多年前就已经被研究得非常的透彻，人月神话这本书，很多工程师对它非常熟悉，它是非常有名的一本书，它把软件工程的本质阐述得非常透彻，在软件开发中，可以把所有事情分成本质和次要。本质的事务实际是我们要怎么解决业务问题，例如我需要做一个电商的秒杀系统来支撑上面的业务需求，这是本质的问题。次要的部分是我们选择什么技术手段实现它，过去的PC时代或者是软件工程发展有很多技术，软件工程本质上是解决次要复杂度，而且我们也看到它在这个领域中获得了巨大的突破，包括更先进的操作系统，通过相结合来为用户提供统一的开发环境，这些都让我们的整个研发效率大幅度提升。
二、计算的发展历史
可以看到在计算发展历史，实际上每一个大的计算阶段，例如PC阶段，可以看到高级语言的出现，大大地推动了PC的应用开发效率，到了Web&Mobile时代，类似于Java或者JS领域里非常流行的框架，大大地降低了开发Web&Mobile的复杂度。我们很自然的会问，在云也是一个影响力规模特别大的一个计算平台，那么在云的环境里，什么是它的原生的编程模型，怎么做到能让云上的应用开发效率能有十倍的提升，实际上背后的逻辑和在PC时代或者Web&Mobile时代没有什么差别，我们认为云的环境上一定会出现原生的编程模型，带来生产力十倍的提升，这种编程模型具备一些特点，它的抽象能力要是非常高阶的能非常有表达力，它的整个配套应用构建运行的能力，包括工具和框架要是非常完备的。
三、一个 hello word 单机应用有多简单？
首先可以来想一下今天要在一个单机的环境来开发一个hello word应用它到底有多简单，比如要在一个单机环境里并行处理n个文件，该怎么做？可能在Java的一些高级语言里，这些事情非常简单，有经验的程序员只需要两三个小时甚至更短的时间就能完成，比如最简单的创建一个Thread pool，它运行的是自己实现的文件处理的逻辑，只要往Thread pool里提交任务就可以了。可以看到在这样一个场景下面，它的本质复杂度就是我要实现怎么样处理文件，这样一个逻辑，剩下的次要复杂度，例如Thread pool底层是如何运行，如何将Thread它的操作系统或者硬件线程，能够对应起来，怎么实现负载均衡，怎么样让对应的工作队列，能够非常高效接受任务提交，很多的细节实际都不用关注，只需要使用库就行了。
四、一个 hello word 分布式应用有多复杂？
那同样的将它括大一下，想并行处理n 个文件，假设文件非常多，超过了一台机器可以处理的能力，如果我要把它括载到多个机器，它的本质上是一个分布式应用，那么我应该怎么做？这个时候会发觉，这个事情变得非常复杂，首先要创建多个Server或者要计算一下需要多少Server处理，我要创建Server然后配置好服务器的环境和操作系统网络以及运行时依赖的东西，还要去思考，机器挂了或者机器和机器之间的网络传输有问题，或者怎么样让机器它负载均衡，这些问题我都要处理，会发觉我要负责的问题越来越多，那这个复杂度实际上是非常之高的，如果是从头开始，没有几个开发者能够在云上很快的实现这样一个很简单的hello word的分布式应用，首先大量的精力一定花在配置机器上，所以在这件事上，可以看到它的本质复杂度仍然是文件处理逻辑，但是次要复杂度，如果和前面的单机hello word应用对比，我们会发觉，本质在云上需要自己实现Thread pool，所以这个复杂度是非常高的，我们认为以这种Server方式来开发构建分布式应用，它的复杂度和汇编语言类似，开发一个云上分布式应用，它的次要复杂度远远大于本质复杂度。
五、一个 Helloword 分布式应用应该多简单
想一个 hello word分布式应用它应该多简单，能不能达到和单机一样简单，可以思考怎么减小次要复杂度，实际上在这样一个例子中，可以发觉很多的概念是可以很完美的映射过来，例如将云看做是一台计算机，实际是这些单机线程在云计算机中执行的函数实例，今天在Serverless的计算平台，例如函数计算服务上，用户不需要关心函数实例运行在哪一个Server上，只需要关心我实现了函数的处理问题，那么云服务函数计算就可以以一个可靠的方式运行逻辑，那同样的任务队列可以想象成今天云上对应的产品，实际上是不需要在关心这些消息队列中的消息会存储在哪一个Server上，只需要去开通消息队列的产品，通过SDK往消息队列里发消息就好，这些消息能够自动的触发后台的云函数来处理，这是不是就跟单机上的模式很相似，如果是这样一种方式，我们会发觉，我们是在用消息队列函数对向抽象度更高的原语来解决问题，实际上是在更高的层次来做技术方案，这样的效率会有很大的提升。
六、Serverless-云的未来
如果将云看做是一个计算机，今天对云上的产品可以做一个分层，最底层的很像计算机的硬件，以K8S为代表的容器的编排，实际是相当于云的云原生应用的操作系统，在这个之上，云的产品体系已经发展的非常丰富，每一个云厂商可能都有几百款产品，也可以看到，今天这些云产品，大部分的形态是Serverless的，例如对象存储，它是Serverless的存储服务，开发者不需要关心文件数据底层存储在什么Server上，也不需要关心Server什么时候扩容，宕机怎样处理，数据怎么样保存可靠性，所以当越来越多的云服务都是Serverless形态时，很自然的我们可以把类似于函数计算或者是Serverless应用引擎，这样的Serverless计算服务来连接起这些所有云服务，让大家在更高的抽象层上来编写应用，认为Serverless它计算是一个应用类型池的形态，相信在Cloud2.0的时代，云将从汇编语言迈向高级语言时代，带来研发效率颠覆性的提升。
七、异步处理
首先是异步处理，这个场景和Thread pool的场景比较类似，在云上，可以看到发送电子邮件，做文档或者视频图片处理，第三方服务，都很适合以异步的方式处理请求，可以总结出来，当长耗时或者耗费大朗资源或是容易出错的场景，这些逻辑都可以包装出来，用异步的方式去执行，这样对系统的响应速度，对系统的可靠性有很大帮助，例如要实现最常见的登录逻辑，登录成功以后都会发送欢迎文件，这个动作实际可以在登录的主流程中移出去，用异步的方式执行，不需要等待邮件发送成功才结束，而是登录成功后，自动的触发欢迎文件发送，或是调用第三方服务，有可能不知道第三方服务可用性怎么样，不想它对我自己的应用的可用性造成影响，这个时候也可以将第三方服务调用逻辑，用异步的方式去处理。所以我们可以看到，异步处理有非常广阔的使用场景，也可以看到在业界，有大量的实践。
八、理想中的异步处理
理想中的异步处理系统有几个特点，首先资源池是统一的，例如不同类型的应用可以共享资源池，才可以提高资源利用效率。同时，为了让不统一类型的应用，都能用在统一的系统上，这个系统的能力必须覆盖从10ms左右的非常的实时的异步处理的请求到数十个小时的离线任务，都要能负载，在线和离线跑在同一个平台上。当各种不同任务类型都跑在同一个平台时，这个平台必须具备非常完备的能力，这样才可以做到让应用安心的跑在统一的资源池上。
异步处理的第二点一定是弹性可扩展，这个实际是今天大多数用户，自己构建的系统本身是没有弹性的。为了做到弹性可扩展，系统的每一个环节都要具备水平扩展的能力。并且当你弹出去或者缩回来以后，负载需要快速匹配动态伸缩，所以负载均衡能力非常重要。弹性要求实例启用速度要非常快，当实例启动速度越快越有可能让你的资源的使用更贴合负载。
异步处理第三点是系统能力需要比较完备，能够让开发者开箱即用，例如很常见的定时延时触发任务能力，或者暂停终止任务，例如我写了一个任务，发现逻辑有bug，或者发现术语不对，可以立即终止。这些能力非常重要。还有可观测性，可以帮助我们快速定位诊断问题，比较理想的最终是业务上需要实现如何处理异步请求，只需要解决本质复杂度。
九、现实中的异步处理系统
但是现实中，可以看到很多的用户实际上构建的异步处理系统并不是完美的，例如资源池是碎片的，不用的部门和类型，从可溶性角度考虑，采用各自独立的资源池，而独立的资源池导致整个资源池规模非常小，处理能力是很有限的，同时这种碎片化，整个平台的流动能力是薄弱的，更加不敢将不同类型的负载跑在同一个平台上。
第二点是弹性能力弱，大多数用户最典型的是通过消息队列，任务队列，加上底层容器一起构建的任务异步处理系统，弹性是很弱的，特别是实时处理场景下， 从稳定性的角度考虑，很多用户都是以静态方式使用资源，基本上不会做弹性伸缩。整个启动速度比较慢，都是分钟级一样。
第三点是任务处理功能参差不齐，可能有定时触发没有延时触发，或者是提前暂停终止任务能力。可观测性也不是特别完美，使用者除了编写任务处理逻辑以外，还需要和队列打交道，去客户端拉取任务，或者是实现结果回调，异步任务处理之后需要回调下游服务，这些逻辑都需要自己实现。
十、异步系统技术挑战1-可扩展性
在过去的几年里，例如函数计算构建一个非常有弹性的异步任务处理的平台。在打造一个理想的功能完备的异步任务处理平台中间遇到的技术挑战，以及如何解决。在图中左边，所采用的异步任务的架构是非常典型的pull模式，这种架构非常流行，中间是Redis消息队列，用Redis做任务队列，Worker节点也就是任务处理节点，从指定的任务队列里去拉取任务执行，处理完后再拉取任务执行，依次循环，这个过程是比较清晰的，这种架构都有一些普遍的挑战，都是从slack分享的如何改进异步处理系统博客中摘出来的，这些问题是过去碰到的比较有代表性。例如速度持续超出时，Redis的资源消耗会快速地增加，可能有打包的风险。更危险的是当内存大到一定程度后，Redis没有办法出队，系统就没有手段恢复，这个非常危险的。在过去的一些场景下，能看到任务实际被以非常突发性的方式提交上来，通常用户希望一次性的提交大量任务，这些任务以可控的方式来被消耗处理掉。这样一种模式，实际上对典型的异步处理系统带来很大挑战。
第二个问题是，worker无法独立于Redis实例来扩展，提交很多任务或需要快速弹出worker来处理，但是在弹出worker的同时要考虑Redis的连接资源管理，以及如何负载均衡，这些是非常大的难度。
第三个问题是已有的HPA伸缩模式，不适应在任务场景下或者异步请求场景下，通常用户需要自己去实现排队任务数等指标的伸缩逻辑，是比较复杂的。
十一、异步系统可扩展性-解耦队列和 Worker 资源
要提升整个异步系统的可扩展性，最根本的是需要把队列和worker资源解耦。引入了一个任务分配器的角色，任务分配器负责从队列拉取任务请求，分发到对应的worker节点上，在这一层上可以看到系统的每一个环节，队列这个角色或者是分配器，都是可以动态伸缩的，同时彼此伸缩的要求实际上是有很大不同的，队列资源或者是分配器资源相对的是一个扩缩容频度没那么高，而worker节点扩缩容频度非常高，通过这种解耦让worker弹性能够不受队列的限制，这个是提升可扩展性非常关键的手段
十二、异步系统可扩展性-自适应的请求分发
当引入了分配器这个角色以后，让worker和队列解耦以后，有一个新的问题是分配器应该以什么速度去给下面的worker或者任务处理函数来分配请求，例如有些任务处理函数，它的任务限制的上限很小，它希望慢慢处理请求。有一些任务希望短时间能提出很多请求，很多实例来快速处理请求。这就意味着分配器它必须能够识别出来请求处理函数的处理能力以一个合适的速度分发请求。这个地方借鉴了TCP拥塞控制的思想，采用了试探性的拥塞控制的AIMD算法来找到合理的分配速度。在实践中，它的效果也是比较好的，在没有使用算法之前，流控错误非常多，整个处理模式有点像脉冲式带来大量的错误。使用新的算法以后，分配器能以一个比较匹配的速度去分配给下游处理函数，例如图中左边是用户任务负载情况，每天不定时时间有大量任务提交，当使用自适应的请求分发后，流控错误大幅度降低
十三、异步系统可扩展性-基于 Partition 的负载均衡
比较重要的是负载均衡就是弹出来以后如何让平台上的负载能够入流到新的资源上去，不同的节点上的负载比较均衡的，这对整个流量路由和迁移提出很高要求，在这里面有一些指标来衡量要不要做迁移，例如我们会把颜色敏感的，优先级高的应用流量迁移到其他的队列上，例如某一个用户如果他的突然间提交大量的请求或者持续一段时间流量变得特别高，我们会对这个用户增加更多的队列，分配器和worker节点，来消化他的流量，在这个过程中间，让负载能够进入到新的资源上去，这个是非常重要的。也允许用户设置任务的过期时间，对于有时限性要求任务，产生挤压后，快速丢弃挤压任务，这个也是快速恢复服务的能力，在整个过程中间，我们采用了基于Partition的负载均衡，能把不同用户的负载映射到不同的Partition上去，通过分裂或是迁移实现系统负载均衡。
十四、异步系统技术挑战2-GB 级镜像实例秒级启动
异步系统中，另一个比较大的技术挑战是如何启动更快，这意味着必须改变原来的最简单的实例启动模式，比如启动一个实例，要从共享存储加载镜像数据，这种镜像数据通常是GB级别的，甚至更大，可能启动不了多少实例。为了支撑很好的弹性，在镜像实例的秒级启动上做了大量的工作。包括最核心的两点，第一点是按需加载，提交上来一个GB甚至更大的镜像文件，并不是在实例启动时加载全部文件，只是加载需要的文件，从研究数据以及自己的生产环境统计数据表明，只有不到7%的数据才是真正需要的，按需加载能够避免大量的冗余数据的拉取。另一个是整个平台存储是分层的，例如最快的是节点上的云盘，其次是同一个机房实例之间，它的网络交换，也是比较快的，最慢的可能是共享存储，所以把每一个数据分发和缓存，都要让它能够最终实现尽可能前值的缓存，就能够获取数据，通过数据驱动的缓存策略，能够实现很高的缓存应用率，最终能够达到GB级别的秒级启动效果。
十五、镜像实例启动性能对比
这个地方是过去工作总结，过去两年发了两篇顶会的论文，下面主要是对业界厂商的国外或国内的评测指标，可以看到灰色数据代表基准数据，所有镜像数据都加载到云盘上，它的启动开销，可以看到我们相对于所有数据全在云盘上启动相对开销的最小。
十六、典型案例：网易云音乐音视频算法服务 Serverless 化
这个场景下，过去有非常多的大型的用户通过Serverless的方式解决问题，像网易云音乐，有几千万首歌，当上线一个新的算法时，如何去处理曲库的歌，去应用新的算法去处理，一直是一个痛点，对整个资源弹性提出非常高的要求，它采用了一种将弹性部分资源需求放在阿里云上模式，最终取得了非常好的效果，原本一个算法上线需要两个月，才能把整个曲库处理完，最后缩短到一分钟之内就可以完成，通过弹性能够让资源成本大幅度降低。
十七、异步系统总结
最后可以总结一下异步系统，长耗时的消耗大量资源的或者是容易出错的逻辑，非常适合从主流程中剥离出来，整个异步处理能看到它的多租隔离，负载均衡，动态伸缩，启动速度优化，都是需要系统性的解法。下面是一个对比，像Serverless这种异步处理能力和K8S对比，会发觉Serverless异步处理平台的能力会比K8S丰富很多，也能让我们上层的客户能够以更小的代价来鉴定自己业务统一的异步处理平台。
整个Serverless还有非常多的应用场景，可以自行参考相关资料
十八、误解1-Serverless 架构太新了，没有经过验证
Serverless的架构太新了，没有经过验证，它并不是一个非常新的技术，第一个云产品它就是Serverless的一个存储服务，也可以看到今天整个云产品体系正在飞速Serverless化，所以这个架构不是新的，是已经经过很多年发展，而且它是一直更快的速度整个云产品体系在往Serverless转变。另外Serverless在阿里集团过去几年也做了大量的实践。阿里集团内部还是其他的头部客户都有实践，感兴趣的可以去看网上相关介绍。
十九、误解2-Serverless 应用需要大量改造，迁移成本高
这个在开始确实需要相应改造，实际上阿里云提供Serverless产品，整个取向是倾向于让用户能够平滑迁移，无论是函数计算也好，或者计算引擎也好，一些Serverless计算服务各自所处场景下，它的迁移成本是越来越低的，例如函数计算容器镜像方式，意味着其他的外部框架可以非常平滑的迁移过来，像Serverless应用引擎，主打的是零代码改造，让应用非常平滑迁移上来，这些也是很重要的创新。
二十、误解3-Serverless 单价比 ECS 贵太多，成本没有优势
实际上可以看到Serverless降本核心逻辑是提高资源利用率，在今天很多的用户无论国外还是国内，有很详细的数据中心统计数据表明，大多数用户资源应用率低于20%，甚至是个位数，在这种场景下，用Serverless可以通过大幅提升资源利用率降低成本，另外Serverless降本的逻辑不是单纯降低资源层成本，而是降低基础平台的开发和维护复杂度，让大家效率更高了，或者是只需要雇佣更少的人，能够快速开发产品去推销市场，有很多的用户选择了Serverless的架构模式后，可以以一个很小的团队实现非常敏捷的开发效率。
二十一、误解4-Serverless会导致供应商锁定
实际上有好多的维度去判断到底是什么让供应商锁定，例如你讲数据存储在云厂商，当你要迁移到另一个云厂商时，需要搬运数据。在云厂商上使用各家云产品时，功能或多或少有差异的。最后Serverless也好，容器也好，可能会带来哪些供应商锁定，需要我们以更系统化方法去评估，在今天阿里云Serverless产品追求目标是为用户提供没有担忧的产品。所以我们在很多产品设计选择上都是拥抱了开源开放的标准，包括函数计算的设计和支持镜像涉及的格式，所有的最终都是为了让用户能够提交代码到阿里云Serverless平台上以一种标准的方式去运行，也能更开源开放的生态做一个很好的融合交互。
