极速启动,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)上快速部署一个弹性的在线商城微服务应用,使得终端用户可以通过公网访问访问该商城,并进行压力测试以验证其性能与稳定性。
相关文章
|
运维 Cloud Native 云计算
未来趋势:云原生技术在后端开发中的应用
随着云计算技术的快速发展,云原生技术作为一种新兴的软件架构理念,在后端开发领域日益受到关注。本文将探讨云原生技术的基本概念、优势以及在后端开发中的应用,展望未来云原生技术对于软件开发的影响和发展趋势。
|
11月前
|
安全 Cloud Native Java
Java 模块化系统(JPMS)技术详解与实践指南
本文档全面介绍 Java 平台模块系统(JPMS)的核心概念、架构设计和实践应用。作为 Java 9 引入的最重要特性之一,JPMS 为 Java 应用程序提供了强大的模块化支持,解决了长期存在的 JAR 地狱问题,并改善了应用的安全性和可维护性。本文将深入探讨模块声明、模块路径、访问控制、服务绑定等核心机制,帮助开发者构建更加健壮和可维护的 Java 应用。
981 0
|
10月前
|
人工智能 自然语言处理 监控
83_角色提示:赋予模型特定身份
在大语言模型(LLM)时代,与AI系统的交互方式正经历着一场深刻变革。从简单的指令式对话到复杂的角色扮演,人类与AI的互动边界不断拓展。其中,角色提示(Role Prompting)作为一种强大的提示工程技术,正逐渐成为释放LLM潜能的关键方法。通过为模型赋予特定身份,我们能够引导其以更符合预期的风格和专业度生成内容,显著提升交互体验和任务完成质量。
681 0
|
人工智能 关系型数据库 分布式数据库
让数据与AI贴得更近,阿里云瑶池数据库系列产品焕新升级
4月9日阿里云AI势能大会上,阿里云瑶池数据库发布重磅新品及一系列产品能力升级。「推理加速服务」Tair KVCache全新上线,实现KVCache动态分层存储,显著提高内存资源利用率,为大模型推理降本提速。
|
缓存 NoSQL Serverless
云数据库Tair:从稳定低延时缓存到 Serverless KV
本次分享聚焦云数据库Tair的使用,涵盖三部分内容:1) Tair概览,介绍其作为稳定低延时缓存及KV数据库服务的特点和优势;2) 稳定低延迟缓存技术,探讨如何通过多线程处理、优化内核等手段提升性能与稳定性;3) 从缓存到Serverless KV的演进,特别是在AI大模型时代,Tair如何助力在线服务和推理缓存加速。Tair在兼容性、性能优化、扩缩容及AI推理加速方面表现出色,满足不同场景需求。
RZ
|
存储 缓存 弹性计算
张弛有道,块存储极致的创盘弹性能力
前言“鸿蒙初判陶镕铁,大禹神人亲所设。湖海江河浅共深,曾将此棒知之切。开山治水太平时,流落东洋镇海阙。日久年深放彩霞,能消能长能光洁。老孙有分取将来,变化无方随口诀。要大弥于宇宙间,要小却似针儿节。棒名如意号金箍,天上人间称一绝。重该一万三千五百斤,或粗或细能生灭。也曾助我闹天宫,也曾随我攻地阙。伏虎降龙处处通,炼魔荡怪方方彻。举头一指太阳昏,天地鬼神皆胆怯。混沌仙传到至今,原来不是凡间铁。”  
RZ
1303 1
|
存储 缓存 Dragonfly
如何进行容器镜像加速?| 深度揭秘阿里云 Serverless Kubernetes(3)
容器相比虚拟机最突出的特点之一便是轻量化和快速启动。相比虚拟机动辄十几个 G 的镜像,容器镜像只包含应用以及应用所需的依赖库,所以可以做到几百 M 甚至更少。但即便如此,几十秒的镜像拉取还是在所难免,如果镜像更大,则耗费时间更长。
2252 0
如何进行容器镜像加速?| 深度揭秘阿里云 Serverless Kubernetes(3)
|
机器学习/深度学习 编解码 人工智能
当前VR技术的限制与挑战:深入剖析与未来展望
【8月更文挑战第26天】当前VR技术在技术、内容、市场等多个层面仍面临诸多限制与挑战。然而,随着技术的不断创新和市场的逐步成熟,这些限制和挑战将逐渐得到克服。未来,VR技术有望在更多领域发挥重要作用,为用户带来更加丰富、便捷的沉浸式体验。我们期待VR技术的持续进步和广泛应用,共同见证这一科技领域的辉煌未来。
1424 2
|
运维 持续交付 开发工具
基础设施即代码(IaC):自动化基础设施管理的未来
基础设施即代码(IaC):自动化基础设施管理的未来
767 0

热门文章

最新文章