极速启动，SAE 弹性加速全面解读

摘要：在当今快速发展的云计算时代，业务的稳定性和响应速度成为了企业竞争力的重要标志。无论是应对突发流量还是确保服务的高可用性，快速而灵活的扩展能力都是关键所在。然而，传统的扩展方式往往难以满足现代应用对极致弹性的需求——尤其是在启动速度和资源利用效率方面。

在当今快速发展的云计算时代，业务的稳定性和响应速度成为了企业竞争力的重要标志。无论是应对突发流量还是确保服务的高可用性，快速而灵活的扩展能力都是关键所在。然而，传统的扩展方式往往难以满足现代应用对极致弹性的需求——尤其是在启动速度和资源利用效率方面。

几年前，为了帮助企业和开发者克服这些挑战，阿里云推出了 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 按需加载模式启动速度明显提高，并且使用到镜像中的数据越少，加速效果越明显。

根据统计，目前部署在 SAE 上软件包大小比较集中在 100MB～300MB 之间。

以 OpenJDK 应用为例，分析启动依赖。

实际测试中，应用启动监听，仅依赖 48% 有效数据，其它数据可能从未被加载，或延迟加载读取。

未加载的数据一般包含以下内容：

操作系统 cli 工具操作系统低频使用库 soJDK 应用未被加载的依赖库应用未加载/延迟加载数据（如 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 两次：

1）第一次 run 应用时的 Java 进程是一个 Tracer 角色

默认在此进程退出的时候 dump 出缓存文件，或者，用户也可以手动使用 jcmd QuickStart.dump 命令在进程启动完成后 dump 出缓存文件。

2）第二次 run 应用时的 java 进程是一个 Replayer 角色

运行过程加速

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 大小对用户来说是完全无感并且免费的。

详细使用教程参看：