九九国产热线精品,中文无码肉欲爆乳视频

子游：華為元戎高級工程師

平山：華為云中間件 Serverless 負責人

琪君：華為元戎負責人

|Key Takeaways

冷啟動 (Cold Start) 一直是 Serverless 領(lǐng)域面臨的優(yōu)化難題之一，華為云創(chuàng)新提出了基于進程級快照的冷啟動加速解決方案，致力于在用戶幾乎無感知的前提下，有效提升應(yīng)用的冷啟動性能；
特別的，Java 應(yīng)用冷啟動速度慢的問題尤為突出。本文以 Java 場景為例，介紹華為云在冷啟動性能優(yōu)化方面的探索歷程，并揭秘 90%+ 性能提升背后的技術(shù)實現(xiàn)原理。文末我們也提供了 Quick Start，幫助用戶更快地上手該新特性。

|問題引言：

Java 應(yīng)用冷啟動速度面臨巨大挑戰(zhàn)

Serverless 應(yīng)用啟動時，都需要先進行初始化。其初始化時長一般取決于應(yīng)用本身的屬性，如業(yè)務(wù)邏輯、編程語言等，其中 Java 應(yīng)用的初始化過程通常是最慢的。以下基于一個典型的 Java 應(yīng)用，對其啟動時延進行拆解，各階段耗時分布如圖 1 所示：

圖 1：Java 應(yīng)用啟動耗時分解

其中，端到端冷啟動耗時可分為 2 大部分：

平臺側(cè)時間：

主要包含執(zhí)行環(huán)境創(chuàng)建（如容器啟動）、執(zhí)行環(huán)境初始化（如代碼包下載、部署）等準備工作，此階段最多是秒級響應(yīng)，在冷啟動整體耗時中占比很低，通常不到 5%，平臺側(cè)也支持一些優(yōu)化方式，將耗時進一步壓縮至毫秒級；

服務(wù)側(cè)時間：

主要包含應(yīng)用框架啟動（如構(gòu)建 Spring ApplicationContext）、業(yè)務(wù)初始化（如業(yè)務(wù)數(shù)據(jù)初始化）等動作，此階段耗時一般較長。在本例中，應(yīng)用框架啟動耗時占比約 30%，業(yè)務(wù)初始化占比約 65%。由此推斷，該階段執(zhí)行的動作是 Java 應(yīng)用啟動慢的核心所在。

Java 應(yīng)用啟動慢的根因其實也不難理解，主要有：

框架復(fù)雜：Spring 作為一個企業(yè)級的框架，為了支持廣泛的應(yīng)用需求，存在大量的可配置和初始化邏輯，并通過復(fù)雜的設(shè)計模式來支撐這種靈活性。例如，一個 spring-boot-web 的 hello world，依賴的 class 文件就多達 7404 個，見圖 2；
JVM 的一次編譯，到處運行：類加載時，查找類、校驗類的開銷會隨著應(yīng)用復(fù)雜度而增長；同時，在應(yīng)用剛啟動時，方法還沒有完全被 JIT 編譯完成，因此大部分情況停留在解釋執(zhí)行，影響了應(yīng)用啟動的速度。

圖 2：hello world 依賴的 class 個數(shù)

因此，對于時延敏感型的 Java 應(yīng)用程序，在突發(fā)流量下發(fā)生冷啟動時，可能會導(dǎo)致用戶體驗下降。為了應(yīng)對這一挑戰(zhàn)，用戶可以提前預(yù)留資源來減少冷啟動發(fā)生的頻率，或者對自己的應(yīng)用進行性能調(diào)優(yōu)，但是第一類方案無形中增加了用戶的 keep-alive 成本，第二類方案也有著較高的技術(shù)門檻且往往效果比較有限。

|基于快照技術(shù)的冷啟動加速：

華為云的優(yōu)化探索之路

Part I：站在巨人的肩膀上

業(yè)界針對 Java 應(yīng)用的啟動速度優(yōu)化已有一些優(yōu)秀的實踐，可分為以下幾類：

AOT：

主要有 GraalVM^[1]、EJET 等，AOT 方案是通過在程序運行前，直接將 Java 源碼編譯成本地機器碼，因為提前編譯并不占用運行時間，以此來顯著提升應(yīng)用的啟動速度，同時本地機器碼可以持久化于磁盤中，不占用內(nèi)存且可重復(fù)使用。但是該類方案在特定場景也存在一定的局限性，如 GraalVM 對反射的支持并不友好，在涉及反射的地方都需要新增配置；EJET 雖然解決了反射的問題，但是其編譯時間較長且不穩(wěn)定，在復(fù)雜應(yīng)用場景下也存在性能劣化問題。

AppCDS^[2]：

AppCDS 方案是通過在 JVM 啟動時從 JSA 文件讀取共享數(shù)據(jù)，省略了共享類的加載過程，提升 JVM 啟動速度；同時，多個 JVM 共享同一個歸檔文件，減少動態(tài)內(nèi)存占用，可以提升內(nèi)存使用率。該類方案主要適用于類加載比較多的場景，在一般場景下提升有限，且其對共享類的支持有一定限制，如運行時動態(tài)生成類不支持共享等。

其他針對性（Spring 框架）方案：

如 Lazy Initialization^[3]、Scanning-index^[4] 等，前者通過懶加載的方式來減少啟動時加載類的數(shù)量，一定程度上提升啟動速度；后者通過在編譯階段創(chuàng)建索引，避免啟動時掃描所有路徑來進行加速。但是該類方案在 Serverless 場景缺乏一定的普適性。

華為云 FunctionGraph 創(chuàng)新提出的基于進程級快照的冷啟動加速解決方案，致力于在用戶無感知（無需 / 少量進行代碼適配）的前提下，幫助用戶突破冷啟動的性能瓶頸。本優(yōu)化方案直接從應(yīng)用初始化后的快照進行運行環(huán)境恢復(fù)，跳過復(fù)雜的框架、業(yè)務(wù)初始化階段，從而顯著降低 Java 應(yīng)用的啟動時延，實測性能提升達 90%+。

Part II：快照方案如何優(yōu)化 Java 應(yīng)用啟動速度

當用戶 Java 函數(shù)打開冷啟動加速的配置開關(guān)后，華為云 FunctionGraph 會預(yù)先執(zhí)行函數(shù)對應(yīng)的初始化代碼，獲取其初始化執(zhí)行上下文環(huán)境的快照，并進行加密緩存。后續(xù)調(diào)用該函數(shù)并觸發(fā)冷啟動擴容時，會直接從提前初始化后的應(yīng)用快照來恢復(fù)執(zhí)行環(huán)境，而非重新走一遍初始化流程，以此達到極大提升啟動性能的效果。

先結(jié)合圖 3 直觀對比一下優(yōu)化前、后的冷啟動流程差異：

圖 3：基于快照加速的冷啟動流程

基于快照的冷啟動流程，主要包含以下幾個關(guān)鍵步驟：

Step 1：平臺側(cè)提前準備執(zhí)行環(huán)境，并預(yù)執(zhí)行初始化代碼、保存應(yīng)用快照，此動作后續(xù)統(tǒng)稱為 Checkpoint

與圖 1 對應(yīng)，此階段一般占總耗時的 90% 左右。

Step 2：在請求到達，觸發(fā)函數(shù)新實例擴容時，直接從應(yīng)用快照來恢復(fù)新的執(zhí)行環(huán)境，此動作后續(xù)統(tǒng)稱為 Restore

Restore 耗時是秒級，相當于將數(shù)十秒完整的初始化時間（在圖 1 的示例中）縮短至秒級 Restore 耗時，啟動性能提升了一個數(shù)量級

Step 3：（可選）應(yīng)用進程從快照恢復(fù)后，執(zhí)行 Restore Hook 完成業(yè)務(wù)狀態(tài)的刷新

由于 Image File 是進程運行時的快照，在重建進程之后，會涉及到進程持有狀態(tài)的有效性更新。例如已建立的外部鏈接、加載到進程里的緩存信息等。故我們引入了 Restore Hook 的概念，提供手段讓業(yè)務(wù)對這些狀態(tài)進行刷新，詳見 Part IV。

Step 4：應(yīng)用 Ready，具備接著往下執(zhí)行業(yè)務(wù)邏輯的能力

特別的，容器本身也是主機上的進程，故本優(yōu)化方案也支持容器粒度的 Checkpoint，即對容器內(nèi)指定進程進行 CR，與傳統(tǒng)的輕量化虛機快照相比，其精細化程度更高、也更靈活。其原理詳見圖 4：

圖 4：基于容器的 CR 流程

在 Source 機器上啟動微服務(wù)，通過健康檢查和初始化調(diào)用后，進行 Checkpoint，停止服務(wù)，生成進程快照信息；
在 Source 機器上將進程快照信息和微服務(wù)所有相關(guān)依賴，進行壓縮，加密生成內(nèi)存快照包，并上傳至云端存儲。
在 Target 機器上從持久化存儲中下載對應(yīng)微服務(wù)的內(nèi)存快照包，進行解壓恢復(fù)。
在 Target 機器上 Restore 微服務(wù)進程；

Part III：快照技術(shù)揭秘

華為云提出的基于進程級快照的冷啟動加速方案，其核心技術(shù)依托于 CRIU^[5]，它支持對用戶空間指定的進程進行“凍結(jié)”（即停止進程，并將該進程運行的所有上下文持久化為鏡像文件），并在必要時對其進行“解凍”（即通過保存的鏡像文件來正確恢復(fù)進程運行的上下文），其核心工作流程如圖 5-6 所示^[6]：

圖 5：CRIU 如何工作——Checkpoint

圖 6：CRIU 如何工作——Restore

Checkpoint

CRIU 首先通過操作系統(tǒng)的 /proc 目錄獲取指定進程和該進程下所有子進程的信息，包含文件描述符 (/proc/$pid/fd)、管道參數(shù)、網(wǎng)絡(luò)配置和內(nèi)存映射文件 (/proc/$pid/maps) 等；
CRIU 接著通過 Linux 的 ptrace syscall 接口把一段特殊代碼動態(tài)注入到該進程的地址空間，通過執(zhí)行該動態(tài)代碼，CRIU 以 UNIX 守護進程的方式收集 dumpee 進程存放在寄存器里的內(nèi)存數(shù)據(jù)；
CRIU 將所有進程信息都收集完畢后，再次調(diào)用 ptrace 接口，去掉動態(tài)注入的代碼，恢復(fù)該進程的原有代碼；
CRIU 根據(jù)收集的進程內(nèi)存信息，生成多個以功能分類的鏡像文件，并默認殺死進程，完成 Checkpoint；

Restore

CRIU 解析 Checkpoint 階段生成的鏡像文件，并分析多進程的共享資源；
CRIU 通過 Linux 的 fork 接口重新構(gòu)建、恢復(fù)進程和其共享資源；
CRIU 恢復(fù)所有任務(wù)的資源，但不包含內(nèi)存映射地址，定時器，線程等；
CRIU 根據(jù)鏡像文件重新映射內(nèi)存空間，切換進程上下文，恢復(fù)進程的繼續(xù)執(zhí)行，完成 Restore；

Part IV：Restore Hook

如 Part II 所述，雖然本優(yōu)化方案能極大提升 Java 應(yīng)用的冷啟動速度，但是快照技術(shù)在某些場景也存在一定的局限性，較難做到對現(xiàn)有應(yīng)用的全透明化。通過快照恢復(fù)后，應(yīng)用的網(wǎng)絡(luò)連接狀態(tài)會受到影響，涉及到 TCP Socket 重連等場景，如服務(wù)注冊、DB 連接，分布式通信，消息隊列等。

這部分場景依賴應(yīng)用本身的網(wǎng)絡(luò)重連機制來更新正確，因此，本優(yōu)化方案中也引入了 Restore Hook 的概念，提供手段讓業(yè)務(wù)對這些狀態(tài)進行刷新。Restore Hook 當前已支持大部分主流第三方組件的重連，詳見圖 7：

圖 7：Restore Hook 支持的第三方組件

不難發(fā)現(xiàn)，Restore Hook 需要應(yīng)用本身進行少量的代碼適配。為了進一步簡化應(yīng)用的改造負擔，我們也進行了一種新的技術(shù)嘗試，可以理解其充當了用戶應(yīng)用與 BaaS 之間的紐帶，通過狀態(tài)卸載等手段，對開發(fā)者透明，幫助應(yīng)用完成狀態(tài)的自動化刷新。這部分探索會在后續(xù)的技術(shù)博文中跟大家分享，敬請期待。

|效果實測：

Java 冷啟動時延降低 90%+

我們選取了公司內(nèi)部典型的 Java 應(yīng)用，對其原始初始化流程、Restore 流程進行了對比測試，如圖 8 所示。測試結(jié)果表明，本優(yōu)化方案將應(yīng)用的啟動速度平均提升了 95%+，即使快照包的增大一定程度上增加了包下載、解壓的耗時，但最終端到端的冷啟動時延也降低了 90%+。

圖 8：冷啟加速前后的數(shù)據(jù)對比

|快速上手：

基于華為云 FunctionGraph 的簡單實戰(zhàn)

華為云發(fā)布的基于進程級快照的冷啟動加速方案，是一種性能優(yōu)化服務(wù)，用戶無需額外付費，只需進行簡單的配置、少量的代碼修改，即可享受到該創(chuàng)新方案帶來的冷啟動性能提升。

下文基于華為云 FunctionGraph，為大家?guī)硖匦?Quick Start：

1. 登錄 FunctionGraph 控制臺，創(chuàng)建 Java 函數(shù)，并打開“快照式冷啟動”開關(guān)

2. 可選）配置 Restore Hook，并在函數(shù)代碼中實現(xiàn)對應(yīng)的 Hook 邏輯

3. 函數(shù)發(fā)布新版本后，觸發(fā)快照的自動化制作

4. 請耐心等待快照制作完成（5min 超時時間）

5. 調(diào)用 Java 函數(shù)，體驗快照優(yōu)化后的性能提升

|總結(jié)與展望

本文介紹了華為云對冷啟動優(yōu)化這一業(yè)界難題的探索之路，創(chuàng)新提出了基于進程級快照的優(yōu)化方案。當然，本方案也并非十全十美，它依然面臨著一系列挑戰(zhàn)，如文中提到的應(yīng)用狀態(tài)刷新、進程級 CR 的精細化控制、多平臺的兼容性等，我們也在持續(xù)探索、優(yōu)化中。

同時，F(xiàn)unctionGraph 作為華為元戎內(nèi)核加持的下一代 Serverless 函數(shù)計算與編排服務(wù)，致力于持續(xù)為用戶提供方便、迅捷的 Serverless 服務(wù)體驗。您可以登錄華為云 FunctionGraph 控制臺來深入體驗，更多信息請參閱 FunctionGraph 官方文檔^[7]。后續(xù)我們將分享更多圍繞通用全場景 Serverless 的前沿理論及其案例實踐，回饋社區(qū)。

參考資料：

[1]https://www.graalvm.org/22.3/reference-manual/java/compiler/
[2]https://wiki.openjdk.org/display/HotSpot/Application+Class+Data+Sharing+-+AppCDS
[3]https://spring.io/blog/2019/03/14/lazy-initialization-in-spring-boot-2-2
[4]https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-scanning-index
[5]https://github.com/checkpoint-restore/criu
[6]https://speakerdeck.com/udzura/introduction-to-criu?slide=32
[7]https://support.huaweicloud.com/functiongraph/index.html

原文標題：華為云發(fā)布冷啟動加速解決方案：助力Serverless計算速度提升90%+

文章出處：【微信公眾號：華為DevCloud】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。舉報投訴