玩转AIGC训练营：课时2：初识 Serverless（下）
课时2：初识 Serverless （下）
内容介绍
一、面临的挑战
二、应用场景
三、公有云产品
四、阿里云 Serverless
五、开源产品
六、常见问题
七、案例演示
一、面临的挑战
现在继续我们的初始 Serverless 的下半场课程。
我们再来看一下刚才所说的面临的挑战。这里面临的挑战，第一个是函数冷启动的问题。
函数冷启动其实在各个云厂商当中，都是在努力想办法解决的事情，大家如果有兴趣的话，可以去查一些关于冷启动的论文，会发现云计算的论文其实是很少的，但关于 Serveless 的论文这几年的数量是在逐渐增加的，而其中关于冷启动的论文也比较多，包括冷启动的综述，冷启动的一些解决方案、解决策略。阿里之前也发过一篇文章，也是和冷启动有一些关联的论文。冷启动这个问题还是备受关注的，解决起来也很有挑战性。
在行业内，解决方案无非就是这样几种。
第一种就是实例的复用，大家可以想一下，我第一次启动是冷启动，第二次就是热启动，那我中间间隔多久启动它才能是冷启动。这个时间间隔就是实例的释放时间，其实它更多的是一个哲学问题。这个时间过长了，其实对于整个云厂商来说，它的资源利用率就下来了，但是如果它的实理释放时间过短了。
对于用户来说，可能冷启动的现象就会变得更加严重，所以其实这是一个哲学问题，但是各个厂商都在想办法平衡这个事情，所以实例复用其实是函数冷启动的比较有效的解决手段之一。
其次，有的厂商会在调度层面做一些迟化的操作。比如，我们可能之前是要从底层，假如说要先起机器，然后再做网络，然后再起这样的容器，然后再往里面放代码，可能不同层级的有这样一些操作。那么我们可以在不同的层级之间来做一些迟化，比如我可以先准备一些东西，然后当用户有自定义时，对于自定义的那一部分，我们再给它往里放。
这样的话，如果原先的冷启动的过程是分成四步的，那么我们是不是就可以变成三步，变成两步，甚至变成最后的一步，仅仅是热启动的一个过程。
除此之外，各个厂商还会有一些比较有效的解决手段。了解用户自己函数的业务流量的，其实最终还是用户本身。所以各个云厂商也会提供一种预留实例的功能，可以设定我在未来某个时间点预留的实例数量，根据某些指标来预留实例数量。
除此之外，阿里云还会有一些比较有特色的解决方案。
比如单实例多并发，其实单实例多并发在一定程度上也可以有效的对抗冷启动问题的，因为像我刚才所说的，如果我有一个请求过来，就占用了一个实例，第二个请求过来就占用第二个实例。那么单实例多并发就是当我同时有两个请求过来，不需要启动两个实例，可以直接启动一个实例来应对。这就是单实例多并发的一个效果，它在一定程度上也可以有效的对抗冷启动。
在我刚才所说的这些点之外，有一些厂商也正在不断的探索一件事情。就像我刚才给大家举的一个例子，张三会告诉我说宇哥我电脑还没开机，那么我现在来进行开机，如果张三能预测到我会让他来运行一个程序，假如说我每天都是八点来运行这个程序，我说张三你给我跑一下这个程序，那张三就会想七点半了，宇哥是不是今天又要找我来运行程序了，我先把机器启动起来。
提前把机器启动起来这样的一个事情，它是和人工智能有一定关系的，所以很多的厂商也在想办法去探究流量的预测，是否可以通过一些流量的预测来对一些实例进行一些调整。当然可能说我对所有的函数，每一个函数有多少流量预测可能不会很准确的。那我就可以逐步的来预测，比如我先来预测大盘在这个时间段可能会有多少个实例，然后再来预测不同的运行时，在这个时间段可能会有多少实例，然后再逐步的一层一层的去做优化。其实我们每优化一层，对于用户的时延降低来说，都是一个比较大的提升。
所以整个函数在冷启动的这个层面，各个厂商其实都是在不断的努力。当然也非常希望这样的一个比较有挑战的事情，也可以是阿里云赋能学术界、工业界，大家来相互赋能，共同的去探索这样的一个事情。
前段时间我也在和教授说这样一个事情，我说现在可能你要在 AI 的领域来发一些论文，其实是比较难的，因为 AI 的领域现在有很多的方向，但都已经是逐渐的处于一个类似于饱和的一个状态了。但是在 Serverless 架构下，大家如果要是说想对这种缓存、冷启动来做一些优化，或者对调度来做一些优化，其实它还是有很大的空间的，所以希望大家可以一起参与进来。
第二个问题就是各个厂商的规范不一致。是不是你上车就真的下不来了，其实也不是这样的，包括 CNCF 在内很多的国际组织，大家也正在努力的推进关于 Serverless 的标准化的规范。
虽然说现在看到的这个东西长得不一样，但实际上有些时候，它也逐渐的做了一些兼容，包括阿里云可能也会有一些 event bridge EB 产品可以融合进来的，这样也可以屏蔽掉不同厂商之间的一些差异。除此之外，刚才在群里看到有人在问，是不是有 adapter 这样的一个适配层来做一些事情，
其实是的，阿里云在去年开源的一个叫做 Serverless 代的一款产品，它本身就是一款在做上层规范的这样的一个工具链，或者一个生态，它也希望大家可以无差别的来使用各个云厂商的产品，然后可以提升自己的一些效能。我们真的希望可以通过自己的一些努力，让本来是一个非常好的的技术变得更好，而不是说本来已经很好的技术，逐渐的会因为暴露的一些缺点或者劣势，阻塞大家来使用，我们是希望让大家更简单、更便捷的来使用。
大家正在努力的去解决一些问题，发现的问题都不算是问题，而是机会，他们都正在努力的把握住这样的一些机会。
二、应用场景
接下来，我们可以来看一下有哪些应用场景。
这张 PPT 上给大家来展示的这几个应用场景，包括这张图，都是 CNCF 。
它所列举出来的，大家可以看到包括异步的并发组件，可独立部署和拓展的场景，应对突发或服务使用量不可预测的场景，短暂、无状态的应用，对冷启动时间不敏感的场景，还有需要快速开发迭代的业务，因为无需提前申请资源，因此业务上线速度加快。我们可以看到它所谓的这些应用场景更多的来说就是对 Serverless 架构的一个优势，或者是一个优点的深入的分析。
云厂商 产品 |
典型场景举例 |
AWS LAMBDA |
·实时文件处理 |
阿里云 函数计算 |
·Web应用 |
华为云 函数工作流 |
·实时文件处理 |
腾讯云 云函数 |
·实时文件处理 |
各个云厂商，在他们官网上所展示出来的这个产品，它的典型的应用应用场景对于这个厂商来说一定是最有优势的，因为只有对我厂商有优势，我才会把这个东西放在我的官网上来进行展示。所以我针对AWS ，阿里云，华为云，还有腾讯云这几个云厂商把他们官网上的一些案例拿出来了。
其实我们不难发现，不管是哪个云厂商，都会有一些案例是直接被拿出来说的，例如 web 应用程序。大家都有 web 应用程序、移动应用后端，还有数据处理，然后包括人工智能、 AI 推理，各个厂商都会有，所以我们可以看到 Serverless 架构，它作为其中的 fast 的部分、函数部分.它作为一个计算平台，或者说 Serverless 架构里的一个计算模块来说，其实是可以处理很多事情的。可以粗略的认为，云服务器能解决的事情，它基本上都是可以解决的，只不过是说和云服务器这种解决方法的兼容性好坏的一个问题，或者说我们是否需要做一些更多的工作的一些问题。大家可以认为它能做的事情真的很多。
1. 应用场景：实时文件处理
我们这里也举出来几个比较典型的场景或者案例，来进行一个说明，然后我也会结合一些比较实际的案例进行一些分析分享。
首先第一个是实时文件处理。所谓的实时文件处理，就是说我们可以将拍的一些视频照片文件，上传到对象存储，然后再通过对象存储触发器来触发函数计算，然后它进行一些运算之后给出一些结果，或者是将数据进行持久化。
我们可以举一个例子。例如，我上传一张图片，假如我们有一个相册的软件，当我们把图片上传上去之后，大家以为就真的结束了吗？其实不是的，这里面要做很多的工作，比如我上传的这张图片可能很大，那我以后在图片列表查看的时候，它也是以很大的一张图片给我返回，这显然是不合理的。那么我是否可以给它进行一个压缩，当我查看图像列表的时候，它是一种压缩图片，当我查看图片详情的时候它才是原图，这样的话，既能保证体验又能节省一些流量和支出。然后这张图片是否要被分享呢，如果被分享，我们还需要做一些鉴黄或者鉴恐这样的一些操作，如果这张图片是有危险的，我就要把它给屏蔽掉或者删除掉了。
所有的这些操作都是可以在函数里面做的，我们直接上传，然后触发函数来做这些事情。也也有人会想，这些事情我在云主机上，在容器服务上，不能做吗？也可以做。但是函数计算它有按量付费、极致弹性、弹性伸缩这样一些能力，所以其实你在函数计算上面是可以做传统平台上面可以做的东西，同时，它又会自动来为你赋能一些 Serverless 架构所具有的优势。
2.应用场景：数据 ETL 处理
接下来是数据 ETL 处理也基本上是类似。我们可以将待分析的一些文件上传到对象存储，然后通过对象存储来触发函数。我们可以有一波函数是对这个任务进行的一些数据拆分或者任务拆分，或者是其他的一些操作。
操作完之后，我们再调用其它的函数来并发的进行一些处理操作，其实这个就有点类似于业务的编排，其实这里面就已经涉及到业务的编排了。当第一个函数运行结果是成功的，我调用哪些函数来做一些处理，当我是失败的，我是否要重试，如果我不重试，那么要调用哪些函数来做哪些处理。整个过程是有些编排的思路在里面的，而这个编排的思路是完全可以通过我们在业务代码里面集成函数的调用来实现，也完全是可以通过一个叫做 Serverless 工作流的产品直接实现。
像刚才所说的这种数据 ETL 的处理，其实它在一定程度上是可以解决传统的一些大数据的问题。比如传统的 Hadoop 或者 Spark 他们的一些问题，所以在一定程度上，我们是可以将这样的一个
Serverless 架构融合到大数据的一些课程当中。
3.应用场景：实时数据处理
除此之外，还包括一些实时的数据处理，比如用户将一些数据上传到对象存储、日志服务、消息队列，然后再触发函数来做一些事情。举一个简单的例子，如果我们这个时候有一个任务是要给用户发邮件，那用户就可以来提交自己的邮箱地址，然后到一些服务里面，然后我们再通过触发函数来发一些邮件，发完邮件之后，我将一些结果存储到一些地方，或者我们对一些日志来进行一些分析，这些都是可以的。
4. 应用场景：机器学习（ AI 推理预测）
除此之外，还有像机器学习这样的一些非常热的，比较典型的场景，我也正在和一个同学一起来写一个关于 Serverless 架构和机器学习的结合的这样的一本新书。其实我觉得两个非常热的领域碰撞到一起，真的是会产生非常多的火花，其实在整个 AI 的领域，是完全可以用户发起一个推理的请求，然后函数计算，进行模型的加载，进行预测，返回推理的结果。当然除了一些推理的过程，还有一些可以是训练的过程，比如把 GPU 加进去之后，再做一些训练包括增量的训练、强化的学习。
5. 应用场景： Web 应用/移动应用后端
除此之外，像我们刚才所说的各个云厂商都会有 web 应用或者移动应用后端。之前在一个比较权威的调研报告上面写的是Serverless 架构，里面有76%的应用都是 Web 相关的应用，这个也和我们最初举的例子很像，比如用户可以访问站点，这可能会有一个内容分发的网络，像 CDN ， API 网关都是可以在这里出现的。
所以刚才有人问说，我是不是可以在流量层面来做一些防攻击或者什么道，当然大家都可以在这个层面上直接来做，包括挂一些防毒的产品在外围也是没有问题的，都是非常简单的直接挂上的。然后，一些计算的事情可以在函数计算来做，一些持久的日志可以落到日志服务里，存储可以落到数据库里，文件可以落到文件存储或者是 OSS 对象存储里面，所以我们所需要做的就是一个函数。而剩下所有的外围的其他的周边东西，原先可能需要我们关注的，但是在架构下都是已经有现成的存在了。
6. 应用场景：音视频转码
然后还有一个阿里的比较典型的案例，就是音视频转码的一个案例。基本上和之前的类似，用户把视频上传到对象存储，触发函数，这个时候我们可以看到有一个函数工作流来触发，然后做这些编排操作，他可能会把一些视频进行一些拆分，拆分后进行分别的转码，转码之后再给它进行一个合并。
像我们在做往哔哩哔哩、优酷、腾讯上传这样一些视频的时候，我们会发现，上传完视频之后你不能直接看，它会有正在转码中的这样一个过程。那这个转码有的时候可能会持续很长时间，可能是几个小时，但也有时候它可能会很快，这个更多的取决于服务器的压力，或者服务器的可用资源，或者是否在排队这样的一个状态。但在 Serverless 架构下不是的，你只要来了，我就可以帮你来做这个处理，从头到尾这个处理可能比较慢，那这个时候我们完全可以把它切片处理，处理完之后再给它合到一起，所以其实在 Serverless 架构下做这样一些事情，在体验上、性能上、成本上其实都是有多重优势的。
