介紹

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

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

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

相關(guān) Lambda 被放置在 API Gateway 后面，并通過(guò)調(diào)用相應(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í)行優(yōu)化和編譯。鑒于 JVM 優(yōu)化器不斷監(jiān)視程序的執(zhí)行并執(zhí)行微調(diào)，隨著時(shí)間的推移，可以轉(zhuǎn)化為更好的性能，因此長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序可以從中受益。

如果應(yīng)用程序?qū)嵗淮危⑶翌A(yù)計(jì)運(yùn)行幾個(gè)小時(shí)或更長(zhǎng)時(shí)間，那么這很好，但如果我們正在處理 Kubernetes、AWS Lambda 和希望快速啟動(dòng) Java 應(yīng)用程序的批處理作業(yè)，執(zhí)行對(duì)時(shí)間敏感的操作和規(guī)模取決于需求 - 對(duì)于汽車(chē)愛(ài)好者來(lái)說(shuō)就是渦輪遲滯。

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

結(jié)果呢？非常快的冷啟動(dòng)，這使得 Native Images 在應(yīng)用程序生命周期短暫且必須快速啟動(dòng)的無(wú)服務(wù)器領(lǐng)域中非常有能力。

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

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

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

夸庫(kù)斯

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

C1編譯器

在 Lambda 優(yōu)化之旅中，我還遇到了替代優(yōu)化技術(shù)。其中一項(xiàng)優(yōu)化是建議在 Lambda 執(zhí)行期間獨(dú)占使用 C1 編譯器，這有望提供更快的冷啟動(dòng)。通常，在 JVM 內(nèi)運(yùn)行的 Java 應(yīng)用程序使用分層編譯，其中包括速度更快但不太優(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 的快照，而不是重新初始化它，而是使用快照?qǐng)D像作為一個(gè)承諾更快冷啟動(dòng)的恢復(fù)點(diǎn)。我不得不嘗試一下，看看使用 GraalVM 是否是浪費(fèi)精力，并將其包含在我的發(fā)現(xiàn)中。

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

總體規(guī)劃

現(xiàn)在回到 GraalVM！令我驚訝的是，合并此解決方案后，除了添加和調(diào)整構(gòu)建配置文件和一些必需的元數(shù)據(jù)之外，絕對(duì)不需要更改 Java 代碼。

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

也許有一點(diǎn)。鑒于我們使用的是 AOT 編譯，在 Java 世界中，如果涉及到使用許多庫(kù)所依賴(lài)的反射、代理、接口和服務(wù)注冊(cè)表等語(yǔ)言功能，這會(huì)帶來(lái)一定的挑戰(zhàn)。這就是為什么 GraalVM 編譯器需要聲明額外的配置元數(shù)據(jù)來(lái)顯式注冊(cè)某些類(lèi)和服務(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 運(yùn)行時(shí)的字節(jié)碼編譯相比，它需要更長(zhǎng)的時(shí)間。您可能會(huì)發(fā)現(xiàn)自己必須為構(gòu)建節(jié)點(diǎn)分配更多 RAM 以避免內(nèi)存不足問(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 的配置，以確保下一次調(diào)用不會(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)整配置和構(gòu)建過(guò)程，那么 GraalVM 在性能和安全性方面絕對(duì)更勝一籌。

內(nèi)存占用

正如 GraalVM 所聲稱(chēng)的那樣，與常規(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 是最低的可用內(nèi)存選項(xiàng)，我想知道我們還能低多少。原生映像不僅在冷啟動(dòng)時(shí)速度更快，而且在使用有限資源時(shí)提供一致的性能，這意味著更低的運(yùn)營(yíng)成本。

結(jié)論

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

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

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