作者：奇卫
在当今快速发展的云计算时代，业务的稳定性和响应速度成为了企业竞争力的重要标志。无论是应对突发流量还是确保服务的高可用性，快速而灵活的扩展能力都是关键所在。然而，传统的扩展方式往往难以满足现代应用对极致弹性的需求——尤其是在启动速度和资源利用效率方面。
几年前，为了帮助企业和开发者克服这些挑战，阿里云推出了Serverless应用引擎（SAE），并通过一系列创新技术实现了显著的性能提升。到了现在，SAE的弹性能力进一步得到提升，本文将深入探讨SAE如何通过镜像加速、应用启动加速、CPU Burst等核心技术手段，实现极速启动与高效运行，帮助用户构建更加稳定、高效的云端应用。
镜像加速
镜像的拉取速度，对于弹性效率的影响非常大。在SAE的弹性场景中，用户新的实例能对外提供服务的时间，基本等同于镜像拉取时间+程序启动时间。在镜像加速场景中，SAE主要的优化方向包括：
1.镜像缓存
SAE除了用户镜像外，也包含其他的一些sidecar镜像等。例如监控组件ARMS的镜像，日志采集的SLS的镜像等等。这些基础镜像的拉取耗时在无缓存的情况下，对整体的镜像拉取耗时是一个不可忽视的时长，尤其在网络出现抖动等情况，甚至会超过10秒，对用户来说基本是一个不可忍受的时间，无镜像缓存情况下，以ARMS基础镜像为例，统计下来整体耗时大概如下图（单位为毫秒），镜像缓存的重要性可见一斑。
为了系统的稳定性和容灾，SAE底层包含两种资源池。因为资源池系统架构的差异，每种资源池都有对应的镜像缓存方案。
方案一：镜像预热机制
SAE的镜像预热采用DADI系统的P2P方案实现。
先来看一下什么是DADI P2P方案。DADI系统使用的是一种树形拓补结构的P2P网络。具有每个节点的最大子节点个数恒定的特点。基于这个特点，它的负载均衡性更好，最大层数也是可预期的。因此传输数据更稳定一些，性能也更高一些，适合在生产环境中使用。
DADI架构图如下所示：
数据先下发到ROOT节点，Agent在从父节点拉取。对应到SAE的流程中：
● 当部署SAE应用时，开启前置镜像预热流程，预热P2P ROOT节点的数据
● 当触发部署后，此时P2P网络已经拉取了数据到Agent（或者正在拉取数据），达到加速的效果
方案二：采用ImageCache 缓存实现
ImageCache通过SAE制作的crd提前对常用的基础镜像做下载。提前下载到k8s的worker节点。用户的镜像需要拉取的时候，直接能命中缓存来拉取了。
2.按需加载
SAE的按需加载使用的是DADI的能力。这里介绍一下DADI按需加载的核心思想。
容器启动的瀑布模型通常需要花费很长的时间（镜像下载，镜像解压缩，容器启动）。但是就容器启动而言，往往病必须要使用到全部的镜像数据。这就造成了启动过程中大量的时间以及空间的浪费。往往会增加大量的解压缩时间，启动时间等，对整体的扩容速度造成很大的影响。
传统镜像的结构是分层的，每层保存着较上一层差异的文件。使用时，通过overlayfs 或者类似的联合文件系统来将各层按顺序叠加起来。上传到镜像仓库之前，必须将该层中的差异文件，封装进一个压缩包中。镜像在仓库中由一个描述文件 manifest来表示，存储了镜像各层tar包的哈希值。
这种层级的tar结构是无法实现按需加载的。它没有索引，无法随机读取，也无法快速定位到文件所在的位置。因此想要读取某个特定的文件，不得不将整个包进行下载并解压，做了很多额外的工作和耗时。
DADI 摒弃了基于文件系统的镜像格式，而是基于块设备的镜像格式。它将容器镜像抽象为虚拟块设备，使用时在其上挂载文件系统。相当于 DADI 提供了一块硬盘，用户根据需要加载适合自己的文件系统。
DADI 镜像保留了分层功能，每一层不再是文件的差异，而是块数据的差异。DADI 的 overlaybd 模块负责将这些层叠加为一个虚拟块设备。在 DADI 中，用于读取和写入粒度为扇区级别，可以实现细粒度的差异，可以避免 overlayfs 等基于文件系统方案中的 copy-up。
根据阿里内部对不同大小的包进行测试，采用DADI按需加载的模式进行耗时测试。采用了DADI按需加载模式启动速度明显提高，并且使用到镜像中的数据越少，加速效果越明显。
<来源：FC DADI 数据块按需读取耗时对比实验>
根据统计，目前部署在SAE上软件包大小比较集中在100MB～300MB之间。
以 OpenJDK 应用为例，分析启动依赖。
实际测试中，应用启动监听，仅依赖 48% 有效数据，其它数据可能从未被加载，或延迟加载读取。
未加载的数据一般包含以下内容
● 操作系统 cli 工具
● 操作系统低频使用库 so
● JDK 应用未被加载的依赖库
● 应用未加载/延迟加载数据（如 lib 包、前端文件、数据文件等）
因此DADI按需加载的模式，对于SAE整体的加速效果是很明显的。
3.镜像加速
SAE目前支持镜像部署和代码包部署两种方式。
镜像部署的情况下，如果用户本身使用的是ACR的个人免费版，是不支持镜像加速能力的，并且个人版是共享带宽，存在被限流等风险，所以对性能要求高的场景，并不是特别推荐。
而镜像部署如果使用了ACR EE，则是独享。不存在上述问题，且ACR EE是支持镜像加速的。
这里着重介绍一下代码包部署。
代码包部署底层本质上还是镜像部署，代码包部署实际上是SAE替用户把代码包打成了一个镜像，最终还是会生成一个镜像。
整个过程大概如上图所示：
- 用户的jar包或者war包上传上来后，SAE会将用户的程序包存储到SAE管控OSS
- 接着sae的镜像构建服务会拉取用户的程序包，触发镜像构建。构建成功后镜像推送到SAE管控的镜像仓库
- 接着加速镜像转换程序启动，将上传的镜像转换为用户加速镜像
- 转换成功后，推送到SAE管控的加速镜像仓库
通过加速镜像的转换，用户在拉取镜像的时候会优先拉取加速镜像。在加速镜像不存在的情况下，会降级到拉取普通的镜像。这个过程用户无感知，且对用户完全免费。加速镜像的成本由SAE兜底。
启动加速
1.Java启动加速
SAE对Java应用在部署过程中的不同阶段的启动效率做了一系列优化与提升。目前SAE支持设置应用启动加速，以及运行过程加速。先来看一下效果图。
应用启动加速
SAE的应用启动加速是基于Dragonwell 11环境来实现的。
应用启动加速使用了Dragonwell 11的quickstart能力。这个能力的原理大概如下：
应用进程需要 run 两次
• 第一次 run 应用时的 Java 进程是一个 Tracer 角色
默认在此进程退出的时候 dump 出缓存文件
或者，用户也可以手动使用 jcmd QuickStart.dump 命令在进程启动完成后 dump 出缓存文件。
• 第二次 run 应用时的 java 进程是一个 Replayer 角色
读取 Tracer 进程的缓存文件而执行优化，获得性能收益
运行过程加速
SAE的运行过程加速也是基于Dragonwell 11环境来实现的，其核心原理为使用到了Wisp2（协程）。开启相关配置后，SAE会自动注入-XX:+UseWisp2启动参数，配置了这个参数就可以获得异步的性能提升。
协程是一种比线程更加轻量级的存在，一个进程可以拥有多个线程，一个线程可以拥有多个协程。一个线程内的多个协程的运行是串行的。它具有更加轻量，创建成本更小，降低了内存消耗的特点，可以减少同步枷锁，整体上提高了性能。缺点是针对I/O密集型应用，效率很高，但是不适用CPU密集型应用
开启了这个参数，相当于打开了：
-XX:-UseBiasedLocking # 关闭自旋锁
-XX:+EnableCoroutine # 开启JKU协程支持
-XX:+UseWispMonitor # 开启objectMonitor支持
-Dcom.alibaba.transparentAsync=true # 开启阻塞API自动切换
-Dcom.alibaba.shiftThreadModel=true # 开启线程模型变换
-Dcom.alibaba.wisp.version=2 # 使用wisp2实现
-Dcom.alibaba.wisp.allThreadAsWisp=true # 使用全部线程转换成协程的方式做线程模型变换
2.CPU Burst
CPU Burst是SAE上启动加速的另一利器。
很多用户的应用在启动阶段会加载大量的初始化数据等，这个过程对于CPU的消耗巨大，但是运行态却不需要消耗过多的CPU。如果采用传统的技术手段，可能为了满足启动阶段的资源消耗，不得不加大CPU的规格，及时后面运行态不需要了。但是开启了CPU Burst，可以做到在应用启动阶段，例如实例运行前3分钟，可使用的CPU规格为设置的2倍，3分钟之后，CPU规格恢复到预设值。
其本质上的原理为SAE底层会临时调大实例的Limit上线，预设时间之后恢复正常。这个临时突破CPU大小对用户来说是完全无感并且免费的。
详细使用教程参看：
https://help.aliyun.com/zh/sae/serverless-app-engine-upgrade/user-guide/enable-cpu-burst-function?spm=a2c4g.11186623.help-menu-search-118957.d_1
整个过程如上图所示：实例会在状态为Running阶段后，将CPU规格临时上调，等预设时间结束后，在缩小到真正的预设值。
以上是SAE弹性加速的全面解读。弹性加速是一个复杂，长期的优化项。弹性速度是Serverless的核心竞争力，SAE会持续增强这方面的能力，给用户带来更好的体验。
