介紹

在使用無服務器代碼時，一種相當常見的方法是將其編寫為 Python、Node 或 Go 應用程序，因為它們以非?？斓睦鋯佣劽?/p>

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

不久前，我遇到過這樣的場景：9 個用 Java 編寫的 AWS Lambda 應用程序在冷啟動時會非常慢，甚至其中一些應用程序偶爾會超時。

相關 Lambda 被放置在 API Gateway 后面，并通過調用相應的 REST API 用于管理任務。此功能并未被廣泛使用，因此遇到冷啟動是不可避免的；然而，因為這不是一項關鍵服務，所以它是一個絕佳的實驗機會：弄清楚這些 Lambda 是否可以被挽救。

不久之后，我就遇到了其他幾篇關于開發(fā)人員成功使用 GraalVM 和 Quarkus 等框架來解決這個問題的博客文章。所以我決定親自嘗試一下。

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

GraalVM

簡而言之，GraalVM 是一個 Java 虛擬機，它附帶了一個工具集，能夠將 Java 編譯為本機映像并使用 Graal JVM 執(zhí)行它。

通常 Java 使用“即時”(JIT) 編譯器，顧名思義，它在代碼執(zhí)行期間執(zhí)行優(yōu)化和編譯。鑒于 JVM 優(yōu)化器不斷監(jiān)視程序的執(zhí)行并執(zhí)行微調，隨著時間的推移，可以轉化為更好的性能，因此長時間運行的應用程序可以從中受益。

如果應用程序實例化一次，并且預計運行幾個小時或更長時間，那么這很好，但如果我們正在處理 Kubernetes、AWS Lambda 和希望快速啟動 Java 應用程序的批處理作業(yè)，執(zhí)行對時間敏感的操作和規(guī)模取決于需求 - 對于汽車愛好者來說就是渦輪遲滯。

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

結果呢？非常快的冷啟動，這使得 Native Images 在應用程序生命周期短暫且必須快速啟動的無服務器領域中非常有能力。

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

但是等等，還有更多！由于 Native Image 僅包含已知執(zhí)行路徑上的代碼，因此我們會修剪多余的代碼，并且所有未顯式聲明保留的 Java 類將不可用。因為我們只保留預期執(zhí)行的位，所以我們提高了應用程序的安全性。

以臭名昭著的 Log4J 漏洞為例，該漏洞使用遠程代碼執(zhí)行作為危害主機的手段。對于本機映像，小工具鏈接不太可能成功，因為傳達攻擊所需的庫代碼片段甚至無法訪問。

夸庫斯

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

C1編譯器

在 Lambda 優(yōu)化之旅中，我還遇到了替代優(yōu)化技術。其中一項優(yōu)化是建議在 Lambda 執(zhí)行期間獨占使用 C1 編譯器，這有望提供更快的冷啟動。通常，在 JVM 內(nèi)運行的 Java 應用程序使用分層編譯，其中包括速度更快但不太優(yōu)化的 C1，然后是速度較慢的 C2，但為長時間執(zhí)行的 Java 應用程序提供更優(yōu)化的性能。鑒于 Lambda 的壽命很短，C2 編譯的好處可以忽略不計。

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

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

有關 JVM 分層編譯以及 GraalVM 全新 JIT 編譯器的更多詳細信息，請參閱這篇 Baeldung 文章。

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

具有諷刺意味的是，在我將更改交付到生產(chǎn)環(huán)境幾個月后，AWS 推出了他們最新的 SnapStart 功能，該功能可以拍攝正在運行的 Lambda 的快照，而不是重新初始化它，而是使用快照圖像作為一個承諾更快冷啟動的恢復點。我不得不嘗試一下，看看使用 GraalVM 是否是浪費精力，并將其包含在我的發(fā)現(xiàn)中。

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

總體規(guī)劃

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

聽起來好得令人難以置信？

也許有一點。鑒于我們使用的是 AOT 編譯，在 Java 世界中，如果涉及到使用許多庫所依賴的反射、代理、接口和服務注冊表等語言功能，這會帶來一定的挑戰(zhàn)。這就是為什么 GraalVM 編譯器需要聲明額外的配置元數(shù)據(jù)來顯式注冊某些類和服務，以便它們可以包含在最終的工件中。 GraalVM 提供了一個所謂的代理，可用于與可執(zhí)行文件一起運行，以自動識別所需的配置，從而使此過程變得更容易。

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

請注意，編譯 Native Images 是資源密集型的，與針對標準 JVM 運行時的字節(jié)碼編譯相比，它需要更長的時間。您可能會發(fā)現(xiàn)自己必須為構建節(jié)點分配更多 RAM 以避免內(nèi)存不足問題，這不應該是一個大問題，但絕對是需要記住的事情。

現(xiàn)在我已經(jīng)編譯并打包了 Native Image Lambda，是時候將它們部署到測試環(huán)境中了。通常，Java Lambda 使用 AWS 的 Java 運行時來執(zhí)行；然而，考慮到我們正在嘗試使用原生映像，它是一個二進制工件，其中包含封裝在 Graal JVM 中的應用程序代碼，因此我們必須選擇 AWS 提供的“自定義”Amazon Linux 環(huán)境之一。

測試方法

我使用 Postman API 集合向所有 9 個 Lambda 發(fā)送請求，并測量上述每種技術的冷啟動響應時間。為了確保我總是遇到冷啟動，我重新加載了目標 Lambda 的配置，以確保下一次調用不會使用可能已經(jīng)熱的實例。所有 Lambda 均配置有 1GB RAM。我還測量了每個配置的單次調用，因為該過程非常耗時；然而，觀察到的響應時間描繪了一幅非常清晰的圖景。

結果

所以有效果嗎？絕對地！結果如下：

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

如果不更改任何代碼，SnapStart 的性能并不如我想象的那么好。當除了 SnapStart 功能之外還使用 C1 編譯器時，它進一步降低了冷啟動時間，但仍然沒有擊敗 GraalVM 的 Native Image。這并不是說它不是一個可行的選擇，因為它是一種快速且易于實施的改進。然而，如果我們想盡可能地優(yōu)化 Lambda，并且我們有一些時間和資源來調整配置和構建過程，那么 GraalVM 在性能和安全性方面絕對更勝一籌。

內(nèi)存占用

正如 GraalVM 所聲稱的那樣，與常規(guī) JVM 對應物相比，本機映像需要更少的資源才能有效運行。我想看看如果我要減少這些 Lambda 必須使用的 RAM 量，冷啟動和熱啟動性能將如何保持。這次我只選擇了一個 Lambda 應用程序來執(zhí)行此測試。結果如下：

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

結論

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

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

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