极速启动,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极速部署弹性微服务商城
本实验带您体验在Serverless应用引擎SAE(Serverless App Engine)上快速部署一个弹性的在线商城微服务应用,使得终端用户可以通过公网访问访问该商城,并进行压力测试以验证其性能与稳定性。
相关文章
|
监控 Go 数据处理
阿里云可观测 2025 年 3 月产品动态
阿里云可观测 2025 年 3 月产品动态
464 22
|
人工智能 开发框架 安全
Serverless MCP 运行时业界首发,函数计算让 AI 应用最后一公里提速
作为云上托管 MCP 服务的最佳运行时,函数计算 FC 为阿里云百炼 MCP 提供弹性调用能力,用户只需提交 npx 命令即可“零改造”将开源 MCP Server 部署到云上,函数计算 FC 会准备好计算资源,并以弹性、可靠的方式运行 MCP 服务,按实际调用时长和次数计费,欢迎你在阿里云百炼和函数计算 FC 上体验 MCP 服务。
973 31
|
12月前
|
监控 测试技术 Go
告别传统Log追踪!GOAT如何用HTTP接口重塑代码监控
本文介绍了GOAT(Golang Application Tracing)工具的使用方法,通过一个Echo问答服务实例,详细展示了代码埋点与追踪技术的应用。内容涵盖初始化配置、自动埋点、手动调整埋点、数据监控及清理埋点等核心功能。GOAT适用于灰度发布、功能验证、性能分析、Bug排查和代码重构等场景,助力Go项目质量保障与平稳发布。工具以轻量高效的特点,为开发团队提供数据支持,优化决策流程。
759 89
|
运维 Prometheus 监控
🎉 WatchAlert - 开源多数据源告警引擎【运维研发必备能力】
WatchAlert 是一个开源的多数据源告警引擎,支持从 Prometheus、Elasticsearch、Kubernetes 等多种数据源获取监控数据,并根据预定义的告警规则触发告警。它具备多数据源支持、灵活的告警规则、多渠道告警通知、可扩展架构和高性能等核心特性,帮助团队更高效地监控和响应问题。项目地址:https://github.com/opsre/WatchAlert
1878 18
🎉 WatchAlert - 开源多数据源告警引擎【运维研发必备能力】
|
监控 Java Go
无感改造,完美监控:Docker 多阶段构建 Go 应用无侵入观测
本文将介绍一种基于 Docker 多阶段构建的无侵入 Golang 应用观测方法,通过此方法用户无需对 Golang 应用源代码或者编译指令做任何改造,即可零成本为 Golang 应用注入可观测能力。
545 85
|
存储 人工智能 监控
一键部署 Dify + MCP Server,高效开发 AI 智能体应用
本文将着重介绍如何通过 SAE 快速搭建 Dify AI 研发平台,依托 Serverless 架构提供全托管、免运维的解决方案,高效开发 AI 智能体应用。
7090 65
|
数据采集 SQL 数据处理
当实时消费遇到 SPL:让数据处理更高效、简单
SLS 对实时消费进行了功能升级,推出了 基于 SPL 的规则消费功能。在实时消费过程中,用户只需通过简单的 SPL 配置即可完成服务端的数据清洗和预处理操作。通过SPL消费可以将客户端复杂的业务逻辑“左移”到服务端,从而大幅降低了客户端的复杂性和计算开销。
519 56
|
人工智能 运维 安全
函数计算支持热门 MCP Server 一键部署
云上托管 MCP 搭建 AI Agent 将成为趋势。函数计算 FC 目前已经支持开源 MCP Server 一键托管,欢迎体验。
1451 113
|
人工智能 Cloud Native Serverless
从理论到落地:MCP 实战解锁 AI 应用架构新范式
本文旨在从 MCP 的技术原理、降低 MCP Server 构建复杂度、提升 Server 运行稳定性等方面出发,分享我们的一些实践心得。
4803 102