Serverless AI训练营：课时5：云原生体系下 Serverless 弹性探索与实践（三）
课时5：云原生体系下 Serverless 弹性探索与实践（三）
在这个时代下，SE 就应运而生了。SE 是首款面向应用的 serverless 平台。它与 se 有一定的差异，支持 spring cloud， dubbo 等主流的应用开发框架，用户可以零改造，也是主打的特色零改造。将它的应用复制到 SE 上，并且按需使用，按量计费，目前是按照 CPU 来进行按量计费的，可以充分发挥 severless 的优势，为用户节省闲置的资源成本，同时体验上采用了免费的方式，也是上堂课讲到的。
用户只需要聚焦于核心业务逻辑开发，而像应用寿命周期管理、微服务管理、日期监控等，都是由SE 来完成的。大家可以看到这个图也是 SE 整体的用户视角的架构图，它支持多种应用类型，支持比较完善的全方位的 pass 应该的有的一些功能，它都支持。
然后 SE 后端分两侧，内部分上层的状态。它是做具体的录用网应用的生命周期管理。
然后底层用户资源是布带多租的内部的 K8S。它是提供使用裸金属安全容器和VK对接机两种方式来提供了对应的资源，就是 SE 给用户部的应用，刚才也看了，SE给部署用户部的应用映射到 K8S 中对应的压力，对应的资源，实力是 k8s 中的，它的多度能力也是通过了系统隔离，数据隔离，网络隔离和服务隔离等一系列隔离来实现的，让多个用户跑在一个 k8s 上。
2.弹性效率：分析
对于弹性效率，首先讲一下效率是怎么优化的。首先对弹性效率进行整体分析。对 SE 应用它的整个生命周期进行数据化数据统计和可视化分析。
可以看一下最顶上这个图，整体应用的启动也就是 pao 的创建是分为以下几个流程。
首先是调度，就相当于把某一个应用调到某一个具体的 node，然后是init 创建，这个是比如一些监控的组件是通过 init 进行预达渠道。还有通过赛通过旁的方式进行部署。
然后是拉取用户镜像，创建用户容器，启动用户容器这几个阶段。这个示意图，就是通过它的长度，它的间距，也可以看到整体的耗时的分布情况。
通过分析应用创建耗时集中于以下三个部分。首先是调度，然后就是拉取用户镜像，然后是用户容器启动。调度目前是会实行打通用户 VPC 的操作,联通它的专用网络。
由于该步骤是强耦合于调度，导致调度整体时间较长。由此，我们产生的疑问是是否可以优化调度阶段，甚至是否可以跳过调度阶段，不让它调度了。
然后是拉取用户镜像。拉取用户镜像细分下来使用分两个，一个是拉取镜像，另一个是假镜像，就是镜像不能直接使用，需要给它解压，特别是在大容量镜像的情况下尤为突出，尤其是在像java，这个可能依赖非常多，或者是一些大数据的应用，它的镜像非常大。这个关注点是拉取镜像是否可以优化，是否可以使用缓存或者是解压镜像是否可以优化。而对于应用冷启动这一点，因为SE 它是零改造，是非常满足用户的诉求，而且对于传统的应用是十分友好，所以现在存在着很多单体和微服务的java应用。这些应用大家都知道，java 应用它的应用启动往往是依赖很多，然后加载的配置慢，初始化过程长，导致冷启动速度往往达到分钟级。
期望这个诉求是否可以避免冷启动流程，或者是否可以避免流程的时候，需要用户尽量无改造，不用它改代码，要不基本上用户兴趣也不大。
3. 弹性效率：原地升级
首先，采取了原地升级的策略。SE 在深化初期，它是采用原创的deployment进行发布，它是采用滚动升级的策略，就可以看一下左上角的示意图。滚动升级是相当于不走的时候，先破一个新 pod，然后再销毁一个老 pod，是这种加一减一的方式进行升级。
而相应的原地升级是只更新 pod 中的一个或多个容器版本，而不影响整个pod 的对象，其余容器的升级，它对比普通升级，相当于 pod 还是那个 pod，只是把它内部的某一个中的 container 镜像给换了。
它的实践原理是通过 k8s 的能力，可以直接原地升级container 以及通过 k8s 能力，可以实现整个升级过程中的流量无损。通过刚才说的原地升级的能力，给SE 带来了诸多价值，其中就是最主要的话是避免了成交度，避免了容器的重建，使得整个部署耗时，从整个 pod 的生命周期到只需要拉取和创建容器。
可以看一下下面这张图，通过原地升级，直接就把调度和营地的创建这两个步骤给免去了，因为原地升级过程中只改，用户部署的时候可能只改了自己的代码或者只改了自己镜像，这时候就会触发原定升级，就相当于 pod 还是原来那个 pod，它不用再调度到别的上，其他的 init container 也不用再变，或者容器也不用再变，它只是改 pod 的指定的业务的 container。所以把调度创建的过程给免去了。整体的弹性效率提升了42%。同时，因为无需调度可以来实现缓存能力，下面会予以展开，还有一些附加能力，比如不用调度，然后它的IP 也不变，也可以减少对其他的像调度器注射中心的一些压力。用阿里开展项目的作为的我们的新的工作负债，它的核心能力就是原地升级能力，来实现了效率的提升。
4. 弹性效率：镜像预热
除了原地升级，也加了镜像预热。它包括两种方式。一个是调度前预热，一个是调度中预热。调度前预热是 SE 会对于一些通用的基础镜像进行全节点，每一个节点对于基础镜像都已经预拉取了。
因为这个基础镜像比如像 java 的 open jk，基本上java 应用都需要，这样就不需要从远端直接从近端点拉就行。避免平安从远端进行拉取。同时对于封闭的场景，借助刚才所说的原地升级能力，在分批场景，可以在调度中进行预热。怎么做到，因为原地升级，它的node 是不变的，也就是在分批的时候，第一批部署之后，知道余下的这几批pod 是在哪个节点上，就直接在那几个节点上把镜像先给拉一下。
这样就可以在第一批部署新版本镜像的同时，对后面批次的镜像进行预拉取，进而实现拉取用户镜像和调度。它实际上变成了并行措施。通过这样技术 SCE 的弹性效率提升了30%。
5. 弹性效率：镜像加速
除了镜像预热，还有一个是镜像加速，镜像加速是解压镜像。传统的容器运营中，它是需要将全让的镜像进行下载，然后再解压的。然而容器启动往往只需要一部分内容，不需要全拉取。
由此导致容量容器的启动速度耗时较长，而且标准镜像是采用 tar.gz 格式，它是无法随机读取的。镜像加速功能是将标准的镜像自动转化为加速镜像，是带着自定义索引的，支持随机读取的镜像。这样就可以实现整个镜像按需压载和在线解压。
从而大幅度提升了应用分发效率。同时介入了 acr，就是阿里云的 POP分发能力，无需只从远端，而可以通过用户自己的节点进行拉取镜像，也是有效的。提升了拉取镜像和解压镜像的整体效率。
6. 弹性效率：Dragonwell 11
同时，对于 java 运动启动慢的痛点，SE 联合了Dragonwell 11提供了增强了 AppCDS 的启动加速策略。阿里巴巴是java JDK 的阿里的开源版本，它是对原有的 JDK 进行增强。
