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

简介: 本文将深入探讨 SAE 如何通过镜像加速、应用启动加速、CPU Burst 等核心技术手段,实现极速启动与高效运行,帮助用户构建更加稳定、高效的云端应用。

作者:牛通(奇卫)


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


几年前,为了帮助企业和开发者克服这些挑战,阿里云推出了 Serverless 应用引擎(SAE),并通过一系列创新技术实现了显著的性能提升。到了现在,SAE 的弹性能力进一步得到提升,本文将深入探讨 SAE 如何通过镜像加速、应用启动加速、CPU Burst 等核心技术手段,实现极速启动与高效运行,帮助用户构建更加稳定、高效的云端应用。

镜像加速


镜像的拉取速度,对于弹性效率的影响非常大。在 SAE 的弹性场景中,用户新的实例能对外提供服务的时间,基本等同于镜像拉取时间+程序启动时间。在镜像加速场景中,SAE 主要的优化方向包括:


1. 镜像缓存


SAE 除了用户镜像外,也包含其他的一些 Sidecar 镜像等。例如监控组件 ARMS 的镜像,日志采集的 SLS 的镜像等等。这些基础镜像的拉取耗时在无缓存的情况下,对整体的镜像拉取耗时是一个不可忽视的时长,尤其在网络出现抖动等情况,甚至会超过 10 秒,对用户来说基本是一个不可忍受的时间,无镜像缓存情况下,以 ARMS 基础镜像为例,统计下来整体耗时大概如下图(单位为毫秒),镜像缓存的重要性可见一斑。


image.png


为了系统的稳定性和容灾,SAE 底层包含两种资源池。因为资源池系统架构的差异,每种资源池都有对应的镜像缓存方案。


方案一:镜像预热机制


SAE 的镜像预热采用 DADI 系统的 P2P 方案实现。先来看一下什么是 DADI P2P 方案。DADI 系统使用的是一种树形拓补结构的 P2P 网络。具有每个节点的最大子节点个数恒定的特点。基于这个特点,它的负载均衡性更好,最大层数也是可预期的。因此传输数据更稳定一些,性能也更高一些,适合在生产环境中使用。


DADI 架构图如下所示:


image.png


数据先下发到 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。


image.png


根据阿里内部对不同大小的包进行测试,采用 DADI 按需加载的模式进行耗时测试。采用了 DADI 按需加载模式启动速度明显提高,并且使用到镜像中的数据越少,加速效果越明显。


来源:FC DADI 数据块按需读取耗时对比实验


image.png


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


image.png

image.png


以 OpenJDK 应用为例,分析启动依赖。实际测试中,应用启动监听,仅依赖 48% 有效数据,其它数据可能从未被加载,或延迟加载读取。未加载的数据一般包含以下内容:


  • 操作系统 cli 工具
  • 操作系统低频使用库 so
  • JDK 应用未被加载的依赖库
  • 应用未加载/延迟加载数据(如 lib 包、前端文件、数据文件等)


image.png


因此 DADI 按需加载的模式,对于 SAE 整体的加速效果是很明显的。


3. 镜像加速


SAE 目前支持镜像部署和代码包部署两种方式。


镜像部署的情况下,如果用户本身使用的是 ACR 的个人免费版,是不支持镜像加速能力的,并且个人版是共享带宽,存在被限流等风险,所以对性能要求高的场景,并不是特别推荐。


而镜像部署如果使用了 ACR EE,则是独享。不存在上述问题,且 ACR EE 是支持镜像加速的。


这里着重介绍一下代码包部署。


代码包部署底层本质上还是镜像部署,代码包部署实际上是 SAE 替用户把代码包打成了一个镜像,最终还是会生成一个镜像。


image.png


整个过程大概如上图所示:


  1. 用户的 jar 包或者 war 包上传上来后,SAE 会将用户的程序包存储到 SAE 管控 OSS。
  2. 接着 sae 的镜像构建服务会拉取用户的程序包,触发镜像构建。构建成功后镜像推送到 SAE 管控的镜像仓库。
  3. 接着加速镜像转换程序启动,将上传的镜像转换为用户加速镜像。
  4. 转换成功后,推送到 SAE 管控的加速镜像仓库。


通过加速镜像的转换,用户在拉取镜像的时候会优先拉取加速镜像。在加速镜像不存在的情况下,会降级到拉取普通的镜像。这个过程用户无感知,且对用户完全免费。加速镜像的成本由 SAE 兜底。


启动加速


1. Java 启动加速


SAE 对 Java 应用在部署过程中的不同阶段的启动效率做了一系列优化与提升。目前 SAE 支持设置应用启动加速,以及运行过程加速。先来看一下效果图。


image.png

image.png


应用启动加速


SAE 的应用启动加速是基于 Dragonwell 11 环境来实现的。


应用启动加速使用了 Dragonwell 11 的 quickstart 能力。


这个能力的原理大概如下:应用进程需要 run 两次:


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


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


2)第二次 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


image.png


整个过程如上图所示:实例会在状态为 Running 阶段后,将 CPU 规格临时上调,等预设时间结束后,在缩小到真正的预设值。


以上是 SAE 弹性加速的全面解读。弹性加速是一个复杂,长期的优化项。弹性速度是 Serverless 的核心竞争力,SAE 会持续增强这方面的能力,给用户带来更好的体验。

相关实践学习
SAE 极速部署专属AI证件照神器
本实验带您体验在SAE快速部署一套自己专用的AI 证件照神器。使用SAE部署应用,您无需长期租用服务器,SAE允许在不使用时实例缩容为零,不产生费用。
相关文章
|
10月前
|
人工智能 Cloud Native 安全
DeepSeek 给 API 网关上了一波热度
API 网关并不是一个新的概念,但 DeepSeek 的全民化趋势给 API 网关上了一波热度。本文将围绕 API 网关的上下游概念、演进历程和分类、核心能力、DeepSeek 如何接入 API 网关等方面,和大家一起更加立体的重新认识下 API 网关。
615 135
|
9月前
|
人工智能 中间件 程序员
大模型上下文协议 MCP 带来了哪些货币化机会
本文探讨了MCP(Model-Calling Protocol)的兴起及其对AI生态的影响。自2月中旬起,MCP热度显著提升,GitHub Star和搜索指数均呈现加速增长趋势。MCP通过标准化协议连接大模型与外部工具,解决了碎片化集成问题,推动AI应用货币化及生态繁荣。文章分析了MCP与Function Calling的区别,指出MCP更适用于跨平台、标准化场景,而Function Calling在特定实时任务中仍具优势。此外,MCP促进了 supply端(如云厂商、大模型、中间件服务商)和消费端(终端用户)的变革,尤其以Devin和Manus为代表,分别改变了程序员和普通用户的交互方式。
1132 37
大模型上下文协议 MCP 带来了哪些货币化机会
|
9月前
|
机器学习/深度学习 人工智能 数据可视化
AI开源框架:让分布式系统调试不再"黑盒"
Ray是一个开源分布式计算框架,专为支持可扩展的人工智能(AI)和Python应用程序而设计。它通过提供简单直观的API简化分布式计算,使得开发者能够高效编写并行和分布式应用程序 。Ray广泛应用于深度学习训练、大规模推理服务、强化学习以及AI数据处理等场景,并构建了丰富而成熟的技术生态。
1659 102
AI开源框架:让分布式系统调试不再"黑盒"
|
10月前
|
存储 缓存 Prometheus
阿里云下一代可观测时序引擎-MetricStore 2.0
我们开发了 MetricStore 2.0 版本,从存储到计算进行了全面升级,致力于成为阿里云下一代可观测时序引擎。
601 48
|
9月前
|
人工智能 JSON 自然语言处理
我终于成为了全栈开发,各种AI工具加持的全过程记录
本文从一个需求出发,全程记录如何进行全栈开发。
1820 51
我终于成为了全栈开发,各种AI工具加持的全过程记录
|
9月前
|
人工智能 运维 安全
函数计算支持热门 MCP Server 一键部署
云上托管 MCP 搭建 AI Agent 将成为趋势。函数计算 FC 目前已经支持开源 MCP Server 一键托管,欢迎体验。
1334 113
|
9月前
|
消息中间件 运维 监控
智能运维,由你定义:SAE自定义日志与监控解决方案
通过引入 Sidecar 容器的技术,SAE 为用户提供了更强大的自定义日志与监控解决方案,帮助用户轻松实现日志采集、监控指标收集等功能。未来,SAE 将会支持 istio 多租场景,帮助用户更高效地部署和管理服务网格。
596 52