从0入门，Serverless 实战与创新：课时1：Serverless 赛题设置和解题思路解析
Serverless 赛题设置和解题思路解析
内容简介
一、赛道背景
二、解题思路
三、调试和赛题提交
一、 赛道背景
欢迎大家来参与我们的云原生编程挑战赛很高兴能为大家带来云原生编程挑战赛Serverless赛道的赛题。我是来自阿里云云原生团队的讲师项健。我们猜到一的题目是针对35度问题的弹性优化。下面我们先简单介绍一下我们的赛迪背景。
想必大家都已经了解到serverless的一个框架才是云计算的一个未来。Server less技术是一种全新的一个系统架构。伯克利大学在2019年的时候就预测，server less技术将成为云计算的一个新的计算范式。那么server less技术到底能为我们带来什么？
从左左边这张图可以看出，随着serverless技术的发展，最重要的事情是让我们把注意力从基础设施的一个管理和维护转移到我们最重要的一件事情，就是业务逻辑上。Serverless的核心价值呢，可以概括为三点。包括弹性伸缩，按需付费,以及让用户更加聚焦于他的业务代码。
1.弹性伸缩
在传统的服务器架构中，如果你要处理大量的流量，就需要准备大量的服务器和资源。但在Serverless架构中，系统会自动的为你分配和扩展资源。你不需要担心服务器的数量和配置。系统会根据你的需求来进行自动的扩展和收缩，这样的设计不仅仅省心，而且可以大大提高系统的效率和稳定性。而且在Serverless架构中，也许需要为你实际使用的资源付费，而不是可能会使用资源。这是一个非常重要的优势。特别是对于小型和中型的企业来说，它可以大大的降低it的成本，让你的预算更加的灵活和有效。当然Serverless架构最重要的一个功能是让开发者从繁重的手动资源管理和性能成本优化中解放了出来。因此，他们可以更加专注于创新和业务逻辑的开发,大大提高了甚工程师的一个生产力。
因此，Serverless就像一股新生的力量，正在引领着云计算的方向。因此，理解Serverless技术无疑是我们每一个云原生技术的从业者和爱好者应该具备的能力。在接下来的挑战赛中，我们期待您能够发挥你的创新能力和技术才能来解决我们为你设计的挑战。
2. Serverless产品的解决方案与一些挑战
目前已经有的一些server less产品的解决方案，比如说阿里云的server less cooks s,以及阿里云的函数计算FC业务。他们都做到了我们在上一页PPT中所介绍的三种特性。包括资源的按需调度和使用，以及根据应用实际需要的资源来进行自动的伸缩功能，但是它还存在一个优化的空间。我们这个赛题主要聚焦于弹性伸缩过程中应用的一个冷启动的问题。
那么，什么是冷启动呢？冷启动，就是Serverless架构或者Serverless产品收到一个资源请求的时候到这个实例实际可以运行请求的时间叫做冷启动的时间。冷启动的时间一般包括两个部分，包括资源调度过程，资源初始化，资源的拉取带来的时长。二应用代码的初始化过程也有冷启动，比如说下面的函数计算哪个int的一个过程。而这些，因而这些冷启动的时长，短则是毫秒，长则是分钟级。如果我们每次调用的过程中都进行初始化和销毁实例，那么调用的时延可能会让用户无法接受，那么现有的Serverless框架呢，其实有的时候会采用预热实例的方式，以及调用结束后会按照规则保留部分实例的方式来降低应用的一个响应延迟。比如我们可以看到下面这张图函数计算的一个处理过程。
当我们的第一个请求到达时，我们会进入一个资源启动，然后会进入应用代码的一个inT。在资源闲置了以后，我们在短短的一分钟内是不会释放我们的应用实例，这样当下次请求到来的时候，我们就可以直接复用我们的实例，避免的我们前面这一段冷启动的时间。但是我们不能总是保持这样的状态，因为空闲的时间过长会造成资源的大量的浪费。因此，函数计算对于闲置时间过长的资源，我们也会采取回收的策略，比如说上面这张图。
在闲置时间过长，比如说十分钟的时候。我们队伍的实力已经被释放，那么当下次请求到来的时候，我们就还仍然需要进行一个冷启动和应用代码的一个in it的一时间。从上面的分析，我们可以看出。为了降低冷启动的实验，其实我们往往是需要预留资源。但是预留资源又有可能会造成资源的一个极大的浪费，因此。本次赛季最大的挑战就是做好资源成本和请求实演的一个平衡。而这种平衡在ServerlessI场景下其实会更加的敏感。这种差异主要是来自于在ServerlessI场景下ServerlessI请求对于资源的消耗会特别的大。比如说最近大火的纹身图step defusion,她可以使用Serverless10 gpu卡来进行部署。而一块Serverless1 0卡启动step defusion的服务，一次却只能处理各位数的一个文本。一旦同时请来的请求过多，就会出现超时的一个情况。
而ServerlessI类型的倾向往往特别的大，应用的启动时间又很长。往往Step defusion的GPU镜像的启动时间就要60秒以上。因此如果我们不能复用实例，很有可能又会造成请求的超时现象。所以在ServerlessI场景下我们需要非常精准的调度请求和实力数的一个匹配关系。因此做好冷启动的实验和资源成本的平衡，在当今的时代下就至关重要。
二、解题思路
下面分析我们本次赛题的一个解题思路。以下是server less产品的一个常见架构。
Serverless产品一般是通过一个网关来承接外部的一个流量请求。请求到达网关后会转发到后端实例上。在这个过程中，我们往往需要一个scServerlessnner。来控制后端实例数。使得实例数和请求对资源的诉求来达到一个匹配。ScServerlessner可以通过监控请求的一个请求的数量，类型或者实例的一个资源用率等Metrics来完成对后端实例资源的一个自动扩缩。因此scServerlessnner其实是Serverless架构过程中的一个核心的一个组件，这个组件的一个智能程度直接决定了Serverless平台的一个成本控制水平。比如说coolness社区的HPV 66 ，以及阿里云服务的户头hpServerless，都是典型的scServerlessnner模块的实现方案。
在本次赛题比赛中，我们需要选手去实现这样scServerlessnner模块的功能。在比赛时，我们对以上常见的一个Serverless场景来进行了一个抽象,如下图。
在实际的生产环境scServerlessler模块为了实现弹性伸缩的功能，需要解决很多的工程问题。而具体的工程问题往往和实际的环境和技术站有相关。因此本赛季抽象了以上的一个常见的Serverless场景。通过仿真框架，来屏蔽了这些因环境而异的繁琐的工程细节。只需要聚焦在scServerlessler核心逻辑即可。在本次比赛的过程中。赛题方会提供测试的数据集以及Serverless仿真框架和代码样例。本次提供的数据集来自于阿里云线上的一个真实负载但已经进行了严格的脱敏处理。而选手需要进行遵循gr PC协议的scServerlesslServerlessr模块。下面介绍选手需要实现的scServerlessle模块的主要接口。
scServerlessler是一个gr PC的服务，他需要对外实现的两个主要接口为Serverlessssign和ReleServerlessse。而releServerlessse在代码中，它的名称为Idel。同时选手在实现这两个接口的过程中，需要调用到仿真框架的接口。包括CreServerlesste slot， in IT，delete slot。CreServerlesste slot的一个主要功能是创建一个资源占位。slot其实一个未初始化的一个资源占位图。
一个slot只能被分配至一个实例。而in it和creServerlesste slot其实是一对一出现的。inIt的主要功能呢是将一个slot来初始化一个可以执行为请求的事例。也就是说，我们在执行creServerlesste slot,基本上都要执行一的函数。所谓的init的函数，其实就是我们资源调度的一个能启动的一个过程。在容器场景下，unit包括垃圾箱，启动容器,应用启动等。对于函数计算来说，init常见包括调度代码包的加载,持续启动等耗时。而delete slot则是最后请求执行完以后进行实例的一个删除和释放操作。基于我们的一个仿真框架来提供的这三个接口。
选手需要实现Serverlessssign和ReleServerlessse。Serverlessssign方法是其中之一的核心接口。他的主要目的是分配资源实力来满足任务请求。下面是一个si接口的一个常见的事情逻辑。当一个请求到来的时候，我们的模拟框架会给scServerlessler发送一个请求，而收到请求以后，scServerlessler会调用我们的Serverlessssign函数。这个时候常见的操作，包括我们首先需要判断是否有空闲的实例。一个应用实例，只能被分配一个请求，如果没有空闲的应用实例的过程，我们则需要创建出一个应用实例来供请求使用。在这个过程中，我们需要调用creServerlesstslot和init 函数。
而releServerlessse方法。
第一道方法，会在请求执行完毕后,仿真框架会向scServerlessler发送释放实例的一个请求，此时就会调用一道方法。改方法的一个简单实现就是直接释放我们请求所占用的一个实例资源。但是选手也可以自行的判断是否释放。因为如果不释放实力的话，我们就可以供下一次同一类型的请求来复用，这样可以减少冷启动时间。但是需要注意的是，目前，在我们的scServerlessler 的demo 代码中，选手需要自行进行资源池的管理。
通过以上介绍，想必大家也理解了本次比赛的一个核心挑战。就是做好资源成本和请求实验的平衡。极致的降低冷启动，比如我们的每个请求执行后，我们都等待十分钟再释放实例。通过这样的方式来启动的实验，果然降低了，但是闲置的自变量会大幅度增加。而如果每次请求执行完立马的释放实例，又会导致请求密集时，用户会承受过长的时间来启动实验。当应用的冷启动时间过长时，甚至有可能会导致请求的执行失败。一个合理的做法是，当我们判断同类型的请求密集时，我们可以保留实例，不立即释放，降低冷启动的实验。当同类型的请求稀疏时可以立即释放实例，来避免实力长时间行使带来的一个资浪费。
在合适的情况下采取合适的策略往往需要选手对于请求的分布状况有所判断。选手可以通过分析进行规则性的编程来实现这一目标。选手也可以通过设计自己的一个机器学习算法来识别数据集的周期性。本次比赛提供的部分数据集中存在较为明显的周期性。选手可以通过机器学习算法来检测种机型。预测未来不同类型请求的分布状况。根据预测结果来采取不同的一个处理措施。需要强调的是，并不是所有的数据集都具有明显的收集性，还要求选手的算法具有较强的一个普适性。对于选手的成绩，我们将从以下三个方面来进行评估。
包括稳定性，资源启动和冷启动时间。
首先，稳定性是基础。我们需要选手的代码至少保证掉用Serverlessssign和releServerlessse接口的执行成功率大于99.95%以上。在云计算里稳定性是最重要的基石，因此当选手的代码稳定不达标时我们会判定为0分。在稳定性达标的基础上，我们从资源使用量，冷启动时间两个角度来考量选手的代码优化程度。且权重分别为50%。在前面的所有的描述中，我们主要还是通过提前创建资源或者延迟释放资源来优化资源调度的一个冷启动的时间。但是在之前我们也介绍了，冷启动的时间一般包括资源调度的冷启动时间和应用的冷启动时间。
比如说目前火热的纹身图step defusion。 step defusion gpu芯片大小有15g。程序的一个启动时间要60秒以上。因此，本次比赛我们还提供了一个额外的附加题。
让选手除了优化调度的一个冷启动时间以外，还可以发挥自己的能力来降低应用的一个冷启动时间。选手可以通过fork或者拷贝代码仓库的代码，通过阅读我们的reServerlessd me，开发环境配置及二次开发要求，并实现自己的优化逻辑。至于评判的指标，我们需要您在优化完成后，将优化后的stServerlessble-defusion 和原始的stServerlessble-defusion 冷启动时间做一个比对，至少会取五次的平均值。
关于附加题的评分标准。您可以通过将您优化后的项目打包成一个压缩包。包含您优化的思路背景以及对比的一个基准，发送到以下邮箱中，邮箱 ls147258@ServerlesslibServerlessbServerless-inc.com dixing.chenjie@ServerlesslibServerlessbServerless- inc.comqiulin.nql@ServerlesslibServerlessbServerless-inc.com
由导师来人工为您做出评判。如果您的解决方案足够优秀。你的比赛成绩将有一个可观的一个附加分。
三、调试和赛题提交
最后是关于赛季的一个调试和赛季的一个提交。在参赛过程中，我们涉及到的阿里云产品包括容器服务，ServerlessSK，容器镜像服务ServerlessCR。其中Serverlesscr供大家完成代码后上传镜像。在在提交到天池的一个评分系统中，我们也需要您使用到我们的ServerlessCR气象仓库。而ServerlessSK产品其实Serverless cook less, 主要用于大家的一个本地调试。除了需要使用以上两种云产品以外，你的本地环境还应该安装有cServerlesst,docter,以及k8s命令行工具，goup control在完成以上准备工作以后，我将给大家演示一下如何使用Serverlesssk集群来进行本地调试。
对于阿里云的新用户，我们可以进入我们的赛题官方页。进行我们的免费产品的一个领取，ServerlessSK的领取。完成领取以后，在您的容器服务控制台看见这样一个集群(cloudnServerlesstive-chServerlessnllenge),进入我们的集群内部，我们将看到我们的集群，包括我们的内部的信息。为了能够在我们的本地能够连接上我们的集群，我们需要将我们连接信息中的config文件进行一个复制，然后在我们的本地中，我们要把config文件拷贝到以下路径中。我们将我们的config文件拷贝到一下路径以。这样我们就可以看到我们连接到我们的集群。在调试的过程中，我们可以通过部署一下job来进行一个本地的一个测试。需要注意的是，这里的镜像地址可以更换为您实现的镜像地址，再将这部分进行替换，以后我们可以进行一个镜像的部署。这样我们就能看到我们部署的一个参数文件。关于这一部分的一个调试工作，可以详见我们的一个reServerlessdme。ScServerlessnner本地开发中，我们已经详细描述了如何进行一个本地的一个测试服。可以看到我们这里的测试应用都已经部署成功。你可以通过查看我们的一个部署的日志来进行调试。可以看到，实现代码已经在正常的运行。你可以通过这里的日志来对自己的应用进行一个错误的排查。这里的是我们仿真框架的一个日志，通过查看仿真框架的日志，你可以查看到自己的一个资源使用状况，处理的请求数，失败的请求数，以及冷启动的时间。通过以上代码你可以判断你的代码的优化程度。
