子游：华为元戎高级工程师
平山：华为云中间件 Serverless 负责人
琪君：华为元戎负责人
Key Takeaways
问题引言：
Java 应用冷启动速度面临巨大挑战
Serverless 应用启动时，都需要先进行初始化。其初始化时长一般取决于应用本身的属性，如业务逻辑、编程语言等，其中 Java 应用的初始化过程通常是最慢的。以下基于一个典型的 Java 应用，对其启动时延进行拆解，各阶段耗时分布如图 1 所示：
图 1：Java 应用启动耗时分解
其中，端到端冷启动耗时可分为 2 大部分：
平台侧时间：
主要包含 执行环境创建（如容器启动）、 执行环境初始化（如代码包下载、部署）等准备工作，此阶段最多是秒级响应，在冷启动整体耗时中占比很低，通常不到 5%，平台侧也支持一些优化方式，将耗时进一步压缩至毫秒级；
服务侧时间：
主要包含 应用框架启动（如构建 Spring ApplicationContext）、 业务初始化（如业务数据初始化）等动作，此阶段耗时一般较长。在本例中，应用框架启动耗时占比约 30%，业务初始化占比约 65%。由此推断，该阶段执行的动作是 Java 应用启动慢的核心所在。
Java 应用启动慢的根因其实也不难理解，主要有：
框架复杂 ：Spring 作为一个企业级的框架，为了支持广泛的应用需求，存在大量的可配置和初始化逻辑，并通过复杂的设计模式来支撑这种灵活性。例如，一个 spring-boot-web 的 hello world，依赖的 class 文件就多达 7404 个，见图 2；
JVM 的一次编译 ，到处运行：类加载时，查找类、校验类的开销会随着应用复杂度而增长；同时，在应用刚启动时，方法还没有完全被 JIT 编译完成，因此大部分情况停留在解释执行，影响了应用启动的速度。
图 2：hello world 依赖的 class 个数
因此，对于 时延敏感型的 Java 应用程序，在突发流量下发生冷启动时，可能会导致 用户体验下降。为了应对这一挑战，用户可以 提前预留资源来减少冷启动发生的频率，或者对自己的应用进行 性能调优，但是第一类方案无形中增加了用户的 keep-alive 成本，第二类方案也有着较高的技术门槛且往往效果比较有限。
基于快照技术的冷启动加速：
华为云的优化探索之路
Part I：站在巨人的肩膀上
业界针对 Java 应用的启动速度优化已有一些优秀的实践，可分为以下几类：
AOT：
主要有 GraalVM [1]、EJET 等，AOT 方案是通过在程序运行前，直接将 Java 源码编译成本地机器码，因为提前编译并不占用运行时间，以此来显著提升应用的启动速度，同时本地机器码可以持久化于磁盘中，不占用内存且可重复使用。但是该类方案在特定场景也存在一定的局限性，如 GraalVM 对反射的支持并不友好，在涉及反射的地方都需要新增配置；EJET 虽然解决了反射的问题，但是其编译时间较长且不稳定，在复杂应用场景下也存在性能劣化问题。
展开全文
AppCDS [2] ：
AppCDS 方案是通过在 JVM 启动时从 JSA 文件读取共享数据，省略了共享类的加载过程，提升 JVM 启动速度；同时，多个 JVM 共享同一个归档文件，减少动态内存占用，可以提升内存使用率。该类方案主要适用于类加载比较多的场景，在一般场景下提升有限，且其对共享类的支持有一定限制，如运行时动态生成类不支持共享等。
其他针对性（Spring 框架）方案：
如 Lazy Initialization [3]、Scanning-index [4]等，前者通过懒加载的方式来减少启动时加载类的数量，一定程度上提升启动速度；后者通过在编译阶段创建索引，避免启动时扫描所有路径来进行加速。但是该类方案在 Serverless 场景缺乏一定的普适性。
华为云 FunctionGraph 创新提出的基于进程级快照的冷启动加速解决方案，致力于在用户无感知（无需 / 少量进行代码适配）的前提下，帮助用户突破冷启动的性能瓶颈。本优化方案直接从应用初始化后的快照进行运行环境恢复，跳过复杂的框架、业务初始化阶段，从而显著降低 Java 应用的启动时延，实测性能提升达 90%+。
Part II：快照方案如何优化 Java 应用启动速度
当用户 Java 函数打开冷启动加速的配置开关后，华为云 FunctionGraph 会预先执行函数对应的初始化代码，获取其初始化执行上下文环境的快照，并进行加密缓存。后续调用该函数并触发冷启动扩容时，会 直接从提前初始化后的应用快照来恢复执行环境，而非重新走一遍初始化流程，以此达到极大提升启动性能的效果。
先结合图 3 直观对比一下优化前、后的冷启动流程差异：
图 3：基于快照加速的冷启动流程
基于快照的冷启动流程，主要包含以下几个关键步骤：
Step 1：平台侧提前准备执行环境，并预执行初始化代码、保存应用快照，此动作后续统称为 Checkpoint
与图 1 对应，此阶段一般占总耗时的 90% 左右。
Step 2：在请求到达，触发函数新实例扩容时，直接从应用快照来恢复新的执行环境，此动作后续统称为 Restore
Restore 耗时是秒级，相当于将数十秒完整的初始化时间（在图 1 的示例中）缩短至秒级 Restore 耗时，启动性能提升了一个数量级
Step 3：（可选）应用进程从快照恢复后，执行 Restore Hook 完成业务状态的刷新
由于 Image File 是进程运行时的快照，在重建进程之后，会涉及到进程持有状态的有效性更新。例如已建立的外部链接、加载到进程里的缓存信息等。故我们引入了 Restore Hook 的概念， 提供手段让业务对这些状态进行刷新，详见 Part IV 。
Step 4：应用 Ready，具备接着往下执行业务逻辑的能力
特别的，容器本身也是主机上的进程，故本优化方案也支持容器粒度的 Checkpoint，即 对容器内指定进程进行 CR，与传统的轻量化虚机快照相比，其 精细化程度更高、也更灵活。其原理详见图 4：
图 4：基于容器的 CR 流程
Part III：快照技术揭秘
华为云提出的基于进程级快照的冷启动加速方案，其核心技术依托于 CRIU [5]，它支持对用户空间指定的进程进行“冻结”（即停止进程，并将该进程运行的所有上下文持久化为镜像文件），并在必要时对其进行“解冻”（即通过保存的镜像文件来正确恢复进程运行的上下文），其核心工作流程如图 5-6 所示 [6] ：
图 5：CRIU 如何工作——Checkpoint
图 6：CRIU 如何工作——Restore
Checkpoint
Restore
Part IV：Restore Hook
如 Part II 所述，虽然本优化方案能极大提升 Java 应用的冷启动速度，但是快照技术在某些场景也存在一定的局限性，较难做到对现有应用的全透明化。通过快照恢复后，应用的网络连接状态会受到影响，涉及到 TCP Socket 重连等场景，如服务注册、DB 连接，分布式通信，消息队列等。
这部分场景依赖应用本身的网络重连机制来更新正确，因此，本优化方案中也引入了 Restore Hook 的概念， 提供手段让业务对这些状态进行刷新。Restore Hook 当前已支持大部分主流第三方组件的重连，详见图 7：
图 7：Restore Hook 支持的第三方组件
不难发现，Restore Hook 需要应用本身进行少量的代码适配。为了进一步简化应用的改造负担，我们也进行了一种新的技术尝试，可以理解其充当了用户应用与 BaaS 之间的纽带，通过状态卸载等手段，对开发者透明，帮助应用完成状态的 自动化刷新。这部分探索会在后续的技术博文中跟大家分享，敬请期待。
效果实测：
Java 冷启动时延降低 90%+
我们选取了公司内部典型的 Java 应用，对其原始初始化流程、Restore 流程进行了对比测试，如图 8 所示。测试结果表明，本优化方案将应用的启动速度平均提升了 95%+，即使快照包的增大一定程度上增加了包下载、解压的耗时，但最终端到端的冷启动时延也降低了 90%+。
图 8：冷启加速前后的数据对比
快速上手：
基于华为云 FunctionGraph 的简单实战
华为云发布的基于进程级快照的冷启动加速方案，是一种性能优化服务， 用户无需额外付费，只需进行简单的配置、少量的代码修改，即可享受到该创新方案带来的冷启动性能提升。
下文基于华为云 FunctionGraph，为大家带来特性 Quick Start：
1. 登录 FunctionGraph 控制台，创建 Java 函数，并打开“快照式冷启动”开关
2. 可选）配置 Restore Hook，并在函数代码中实现对应的 Hook 逻辑
3. 函数发布新版本后，触发快照的自动化制作
4. 请耐心等待快照制作完成（5min 超时时间）
5. 调用 Java 函数，体验快照优化后的性能提升
总结与展望
本文介绍了华为云对冷启动优化这一业界难题的探索之路，创新提出了基于进程级快照的优化方案。当然，本方案也并非十全十美，它依然面临着一系列挑战，如文中提到的应用状态刷新、进程级 CR 的精细化控制、多平台的兼容性等，我们也在持续探索、优化中。
同时，FunctionGraph 作为华为元戎内核加持的下一代 Serverless 函数计算与编排服务，致力于持续为用户提供方便、迅捷的 Serverless 服务体验。您可以登录华为云 FunctionGraph 控制台来深入体验，更多信息请参阅 FunctionGraph 官方文档 [7] 。后续我们将分享更多围绕通用全场景 Serverless 的前沿理论及其案例实践，回馈社区。
参考资料：
[1]/
[2]
[3]
[4]
[5]
[6]
[7]
VS Code 有多么不安全：一个扩展就可能导致公司 GitHub 中的所有代码被擦除？
清华应届硕士炮轰字节：恶意低薪，硕士白读还倒贴；马云不再实际控制蚂蚁；开源 ROM 魔趣创始人宣布删库跑路｜Q 资讯
百万用户逃离Twitter转向这个小众社交平台，互联网中心化终将走向大溃败？
芯片的后半场，“提速”依旧是第一要务，那除此之外呢？
特别声明
本文仅代表作者观点，不代表本站立场，本站仅提供信息存储服务。