介紹

在使用無(wú)伺服器程式碼時(shí)，一種相當(dāng)常見(jiàn)的方法是將其編寫為 Python、Node 或 Go 應(yīng)用程序，因?yàn)樗鼈円苑浅？焖俚睦鋯?dòng)而聞名。

但是，如果我們面臨現(xiàn)有針對(duì) AWS Lambda 等無(wú)伺服器環(huán)境的 Java 應(yīng)用程式該怎麼辦？也許我們的大部分程式碼庫(kù)都託管 Java，並且我們已經(jīng)開(kāi)發(fā)了一個(gè)豐富的工具和庫(kù)生態(tài)系統(tǒng)，我們希望重複使用它們。將整個(gè)此類應(yīng)用程式重寫為不同的語(yǔ)言是昂貴的，更不用說(shuō)，我們正在放棄靜態(tài)類型安全性和編譯時(shí)最佳化等功能。

不久前，我遇到過(guò)這樣的場(chǎng)景：9 個(gè)用 Java 編寫的 AWS Lambda 應(yīng)用程式在冷啟動(dòng)時(shí)會(huì)非常慢，甚至其中一些應(yīng)用程式偶爾會(huì)超時(shí)。

相關(guān) Lambda 被放置在 API Gateway 後面，並透過(guò)呼叫對(duì)應(yīng)的 REST API 用於管理任務(wù)。此功能並未被廣泛使用，因此遇到冷啟動(dòng)是不可避免的；然而，因?yàn)檫@不是一項(xiàng)關(guān)鍵服務(wù)，所以它是一個(gè)絕佳的實(shí)驗(yàn)機(jī)會(huì)：弄清楚這些 Lambda 是否可以被挽救。

不久之後，我遇到了其他幾篇關(guān)於開(kāi)發(fā)人員成功使用 GraalVM 和 Quarkus 等框架來(lái)解決這個(gè)問(wèn)題的部落格文章。所以我決定親自嘗試看看。

但是這些工具到底是什麼？

GraalVM

簡(jiǎn)而言之，GraalVM 是一個(gè) Java 虛擬機(jī)，它附帶了一個(gè)工具集，能夠?qū)?Java 編譯為本機(jī)映像並使用 Graal JVM 執(zhí)行它。

通常 Java 使用「即時(shí)」(JIT) 編譯器，顧名思義，它在程式碼執(zhí)行期間執(zhí)行最佳化和編譯。鑑於 JVM 優(yōu)化器不斷監(jiān)視程式的執(zhí)行並執(zhí)行微調(diào)，隨著時(shí)間的推移，可以轉(zhuǎn)化為更好的效能，因此長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程式可以從中受益。

如果應(yīng)用程式實(shí)例化一次，並且預(yù)計(jì)運(yùn)行幾個(gè)小時(shí)或更長(zhǎng)時(shí)間，那麼這很好，但如果我們正在處理Kubernetes、AWS Lambda 和希望快速啟動(dòng)Java 應(yīng)用程式的批次作業(yè)，執(zhí)行對(duì)時(shí)間敏感的操作和規(guī)模取決於需求- 對(duì)於汽車愛(ài)好者來(lái)說(shuō)就是渦輪遲滯。

這就是 GraalVM 的 Native Image 功能可以提供幫助的地方。它沒(méi)有使用 JIT 編譯器，而是選擇了一種非常不同的提前編譯程式碼的方法 (AOT)。它使用靜態(tài)程式碼分析來(lái)預(yù)先烘焙我們的餡餅，甚至在建置期間預(yù)先初始化某些類，以便它們?cè)谖覀兊膽?yīng)用程式程式碼執(zhí)行時(shí)隨時(shí)準(zhǔn)備好觸發(fā)。

結(jié)果呢？非?？焖俚睦鋯?dòng)，這使得 Native Images 在應(yīng)用程式生命週期短暫且必須快速啟動(dòng)的無(wú)伺服器領(lǐng)域中非常有能力。

需要注意的一點(diǎn)是，儘管 GraalVM 具有 AOT 能力，但鑑於 GraalVM 用 Ja??va 編寫的新 JIT 編譯器，它也可以作為現(xiàn)有 JVM 的直接替代品，提供更好的性能。

但是等等，還有更多！由於 Native Image 僅包含已知執(zhí)行路徑上的程式碼，因此我們會(huì)修剪多餘的程式碼，並且所有未明確聲明保留的 Java 類別將不可用。因?yàn)槲覀冎槐Ａ纛A(yù)期執(zhí)行的位，所以我們提高了應(yīng)用程式的安全性。

以臭名昭著的 Log4J 漏洞為例，該漏洞使用遠(yuǎn)端程式碼執(zhí)行作為危害主機(jī)的手段。對(duì)於本機(jī)映像，小工具連結(jié)不太可能成功，因?yàn)閭鬟_(dá)攻擊所需的庫(kù)程式碼片段甚至無(wú)法存取。

誇庫(kù)斯

Quarkus 另一方面，是一個(gè)針對(duì)無(wú)伺服器應(yīng)用程式進(jìn)行最佳化的Java 框架，它附帶一個(gè)工具箱，透過(guò)提供專門配置和建構(gòu)AWS Lambda 作為本機(jī)可執(zhí)行檔的擴(kuò)展，使建置本機(jī)映像變得更加容易。

C1編譯器

在 Lambda 最佳化之旅中，我還遇到了替代最佳化技術(shù)。其中一項(xiàng)最佳化是建議在 Lambda 執(zhí)行期間獨(dú)佔(zhàn)使用 C1 編譯器，這有望提供更快的冷啟動(dòng)。通常，在 JVM 內(nèi)執(zhí)行的 Java 應(yīng)用程式會(huì)使用分層編譯，其中包括速度更快但不太優(yōu)化的 C1，然後是速度較慢的 C2，但為長(zhǎng)時(shí)間執(zhí)行的 Java 應(yīng)用程式提供更優(yōu)化的效能。鑑於 Lambda 的壽命很短，C2 編譯的好處可以忽略不計(jì)。

此處提供了逐步完成為 AWS Lambda 配置 C1 編譯過(guò)程的指南。

當(dāng)然，我想知道與我現(xiàn)有的 GraalVM 總體規(guī)劃相比，該技術(shù)可以提供多少改進(jìn)，因此我也將其包含在下面的研究結(jié)果中。

有關(guān) JVM 分層編譯以及 GraalVM 全新 JIT 編譯器的更多詳細(xì)信息，請(qǐng)參閱這篇 Baeldung 文章。

“但是等等，AWS SnapStart 怎麼樣？”

諷刺的是，在我將更改交付到生產(chǎn)環(huán)境幾個(gè)月後，AWS 推出了他們最新的SnapStart 功能，該功能可以拍攝正在運(yùn)行的Lambda 的快照，而不是重新初始化它，而是使用快照影像作為一個(gè)承諾更快冷啟動(dòng)的恢復(fù)點(diǎn)。我必須嘗試一下，看看使用 GraalVM 是否是浪費(fèi)精力，並將其納入我的發(fā)現(xiàn)中。

值得注意的是，為了充分利用 SnapStart，需要進(jìn)行程式碼重構(gòu)才能利用 beforeCheckpoint 和 afterRestore 掛鉤（更多詳細(xì)資訊請(qǐng)參閱此處）。鑑於我想盡可能避免任何重大程式碼更改，我「按原樣」使用此功能，沒(méi)有實(shí)現(xiàn)這些方法並重新排列任何程式碼。

總體規(guī)劃

現(xiàn)在回到 GraalVM！令我驚訝的是，合併此解決方案後，除了添加和調(diào)整建置設(shè)定檔和一些必需的元資料之外，絕對(duì)不需要更改 Java 程式碼。

聽(tīng)起來(lái)好得令人難以置信？

也許有一點(diǎn)。鑑於我們使用的是 AOT 編譯，在 Java 世界中，如果涉及到使用許多函式庫(kù)所依賴的反射、代理、介面和服務(wù)註冊(cè)表等語(yǔ)言功能，這會(huì)帶來(lái)一定的挑戰(zhàn)。這就是為什麼 GraalVM 編譯器需要聲明額外的配置元資料來(lái)明確註冊(cè)某些類別和服務(wù)，以便它們可以包含在最終的工件中。 GraalVM 提供了一個(gè)所謂的代理，可用於與可執(zhí)行檔一起運(yùn)行，以自動(dòng)識(shí)別所需的配置，從而使此過(guò)程變得更容易。

Quarkus 為知名庫(kù)提供了幾個(gè)擴(kuò)展，使它們“原生圖像友好”，但考慮到我正在使用現(xiàn)有的程式碼庫(kù)，我的目標(biāo)是避免任何重大重構(gòu)（或與此相關(guān)的任何程式碼更改） ），我決定創(chuàng)建現(xiàn)有庫(kù)所需的配置文件，以便成功生成原生映像。

請(qǐng)注意，編譯 Native Images 是資源密集的，與針對(duì)標(biāo)準(zhǔn) JVM 執(zhí)行時(shí)期的字節(jié)碼編譯相比，它需要更長(zhǎng)的時(shí)間。您可能會(huì)發(fā)現(xiàn)自己必須為建立節(jié)點(diǎn)分配更多 RAM 以避免記憶體不足問(wèn)題，這不應(yīng)該是一個(gè)大問(wèn)題，但絕對(duì)是需要記住的事情。

現(xiàn)在我已經(jīng)編譯並打包了 Native Image Lambda，是時(shí)候?qū)⑺鼈儾渴鸬綔y(cè)試環(huán)境中了。通常，Java Lambda 使用AWS 的Java 運(yùn)行時(shí)來(lái)執(zhí)行；然而，考慮到我們正在嘗試使用原生映像，它是一個(gè)二進(jìn)位工件，其中包含封裝在Graal JVM 中的應(yīng)用程式程式碼，因此我們必須選擇AWS 提供的“自訂”Amazon Linux 環(huán)境之一。

測(cè)試方法

我使用 Postman API 集合向所有 9 個(gè) Lambda 發(fā)送請(qǐng)求，並測(cè)量上述每種技術(shù)的冷啟動(dòng)回應(yīng)時(shí)間。為了確保我總是遇到冷啟動(dòng)，我重新載入了目標(biāo) Lambda 的配置，以確保下一次呼叫不會(huì)使用可能已經(jīng)加熱的實(shí)例。所有 Lambda 均配置 1GB RAM。我還測(cè)量了每個(gè)配置的單次調(diào)用，因?yàn)樵撨^(guò)程非常耗時(shí)；然而，觀察到的響應(yīng)時(shí)間描繪了一幅非常清晰的圖景。

結(jié)果

所以有效果嗎？絕對(duì)地！結(jié)果如下：

明顯的贏家是：GraalVM Native Images - 平均而言，與未更改的Java Lambda 相比，它的速度提高了3 倍- 不再有超時(shí)，並且響應(yīng)時(shí)間更好，這正是我想要的實(shí)現(xiàn)。

如果不更改任何程式碼，SnapStart 的效能並不如我想像的那麼好。當(dāng)除了 SnapStart 功能之外還使用 C1 編譯器時(shí)，它進(jìn)一步降低了冷啟動(dòng)時(shí)間，但仍然沒(méi)有擊敗 GraalVM 的 Native Image。這並不是說(shuō)它不是一個(gè)可行的選擇，因?yàn)樗且环N快速且易於實(shí)施的改進(jìn)。然而，如果我們想盡可能地優(yōu)化 Lambda，並且我們有一些時(shí)間和資源來(lái)調(diào)整配置和建置流程，那麼 GraalVM 在效能和安全性方面絕對(duì)更勝一籌。

記憶體佔(zhàn)用

正如 GraalVM 所聲稱的那樣，與常規(guī) JVM 對(duì)應(yīng)物相比，本機(jī)映像需要更少的資源才能有效運(yùn)作。我想看看如果我要減少這些 Lambda 必須使用的 RAM 量，冷啟動(dòng)和熱啟動(dòng)效能將如何維持。這次我只選擇了一個(gè) Lambda 應(yīng)用程式來(lái)執(zhí)行此測(cè)試。結(jié)果如下：

他們兌現(xiàn)了他們的承諾！常規(guī) JVM Lambda 在嘗試配置 256 MB 或更低時(shí)會(huì)耗盡內(nèi)存，而本機(jī)映像似乎未分階段並繼續(xù)執(zhí)行。如果不是 128 MB 是最低的可用記憶體選項(xiàng)，我想知道我們還能低多少。原生映像不僅在冷啟動(dòng)時(shí)速度更快，而且在使用有限資源時(shí)提供一致的效能，這意味著更低的營(yíng)運(yùn)成本。

結(jié)論

Java 的生態(tài)系統(tǒng)豐富且龐大，每天都會(huì)出現(xiàn)許多新技術(shù)和增強(qiáng)功能，使 Java 在無(wú)伺服器應(yīng)用程式方面保持領(lǐng)先地位。 GraalVM 就是這樣一種新興技術(shù)。最初是一個(gè)研究項(xiàng)目，現(xiàn)在慢慢被採(cǎi)用，並成為標(biāo)準(zhǔn) JVM（例如 HotSpot）的可行替代方案。在這篇文章中，我僅僅觸及了 GraalVM 所提供功能的表面，我鼓勵(lì)讀者進(jìn)一步探索它。 Adyen（文章連結(jié)）或 Facebook（文章連結(jié)）等公司有多個(gè)成功案例，他們能夠利用 GraalVM 來(lái)節(jié)省時(shí)間和金錢。

因此，下次當(dāng)您打算將 Java 作為選項(xiàng)打折時(shí)，請(qǐng)嘗試 GraalVM?，F(xiàn)在，Spring Boot 3 開(kāi)箱即用地支援 GraalVM 本機(jī)映像，因此比以往任何時(shí)候都更容易將它們用於無(wú)伺服器工作負(fù)載，以充分利用 GraalVM 提供的效能、低資源消耗和更高的安全性。

以上是Java 也可以無(wú)伺服器：使用 GraalVM 實(shí)作快速冷啟動(dòng)的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！