許多承諾無服務器Java應用程序啟動速度超快的解決方案會迫使你在開發人員體驗、吞吐量性能或安全性方面做出妥協。我們將向你展示如何實現Java應用程序的超快速啟動，而不會有這些問題。

 

最近出現了幾種加快Java啟動的解決方案，從編譯的應用程序中刪除JVM的本機映像（Java應用程序中的啟動速度瓶頸）到在啟動后拍攝應用程序的快照，以便在恢復時無需完成啟動任務。但這些解決方案中的大多數都會對開發人員體驗、吞吐量性能或安全性造成一些損害。

 

大大縮短Java應用啟動時間的解決方案應該具有以下特征：

易于開發者在應用中實現。 

開發人員可以輕松使用現有的技能和API來編寫應用程序。 

開發人員可以輕松地在部署(恢復)時啟用動態配置。 

確保應用的峰值吞吐量性能不會下降。 

確保app的安全性不受損害。 

 

我們將簡要介紹其中的每一點，并描述我們是如何通過Liberty InstantOn實現這些目標的。

 

Liberty InstantOn檢查點/恢復解決方案

Liberty InstantOn是一個基于檢查點/恢復的解決方案，用于在無服務器環境中快速啟動Java應用程序。與其他解決方案不同，Liberty InstantOn從一開始就由開發JDK（IBM Semeru Runtimes，OpenJDK和Eclipse OpenJ9的免費發行版）和應用程序運行時（Open Liberty，開源Java應用程序運行庫）的開發團隊共同設計。這種協作反映了應用程序運行時和JDK之間必須協作完成的許多檢查點和恢復任務：對Liberty進行了幾項更改，要么將任務延遲到檢查點之后（例如，Liberty安全功能的初始化），要么在檢查點之前完成任務（例如，等待后臺任務完成，例如正在進行的JIT編譯和Liberty特定的初始化程序）。

 

我們測試了三種不同應用程序的性能，分別是不使用（基線）和使用Liberty InstantOn，測量了應用程序的啟動時間和服務第一個請求所需的時間。有關結果，請參閱下面的兩張圖，這三個應用程序的范圍從具有單個REST端點（pingperf）的非常簡單的應用程序到使用JPA和遠程數據庫（REST-Crud）的更復雜的應用程序，再到使用MicroProfile功能的完整應用程序（AcmeAir Microservice Main）。

協作式Liberty InstantOn檢查點/恢復方法不僅可以提供非常快的啟動和首次響應時間，還可以提供比完全移除JVM或僅在JDK級別實現檢查點/恢復解決方案，然后聲明許多任務不應在檢查點之前完成更好的開發人員體驗。 

 

易于在應用程序中實現

僅在JDK級別設計的檢查點/恢復解決方案迫使你作為應用程序開發人員思考底層操作系統工具CRIU的工作原理以及如何設置它。它們還要求你確定何時對應用程序進行檢查點檢查，如何確保應用程序在檢查點時處于安全狀態，如何確保應用程序運行時和JVM也處于安全狀態，而不控制任何一個，以及如何確保三者(應用程序、應用程序運行時和JVM)稍后都能正常恢復。雖然在JDK層提供檢查點/恢復支持至關重要(這樣Java應用程序就不需要直接與CRIU接口)，但是與更高級別的應用程序運行時(如Liberty)的良好集成可以大大減輕你的負擔，使你可以專注于應用程序的業務邏輯。 

 

有了Liberty InstantOn，你需要做的就是使用官方的Liberty container映像將它容器化，以使你的Java應用程序啟動更快。在你的構建配置中，你只需要選擇何時執行檢查點(在兩個“階段”中的一個，方便地命名為“beforeAppStart”和“afterAppStart”)，其余的由Liberty和Semeru的組合透明地處理。然后，你只需在官方的Open Liberty容器映像之上構建一個應用程序層，其中包括Semeru和你需要的所有其他內容。

 

使用現有技能和API編寫應用程序

從應用程序中刪除JVM的快速啟動解決方案迫使你改變對開發應用程序的想法。此外，大多數企業軟件都很復雜，需要大量的組件重用。對其他開源項目的任何依賴都意味著無限期地等待所有這些項目得到適當的更新，以符合可以在沒有JVM的情況下工作的標準Java特性的子集。 

 

Liberty InstantOn執行各種任務，允許你堅持使用熟悉的思維模型來理解Java應用程序應該如何工作。動態類加載、反射和動態JIT編譯都是你在應用程序中習慣使用的東西，也是你作為Java開發人員思考方式的一部分。Liberty InstantOn可以與Semeru云編譯器無縫協作，這實現了JIT編譯的好處，而無需為恢復的應用程序的每個實例加載內存和CPU。Liberty InstantOn還支持常用的API新舊規范，包括Jakarta EE、MicroProfile和Spring Boot（目前處于測試版）。因此，你的新應用程序和現有應用程序都可以被容器化，以更快地啟動。

 

在部署(恢復)時啟用動態配置

快速啟動的本機映像解決方案需要你重新編譯應用程序，并重新構建應用程序容器映像，以便調試某些需要進一步診斷信息的問題，或者禁用某些配置或優化。 

使用Liberty InstantOn，你的運營團隊已經為你收集了跟蹤信息，因為他們可以在打開方法跟蹤的情況下輕松地重新部署應用程序的實例，而無需重新編譯應用程序。Liberty和Semeru允許你在恢復時重新配置部署，并在隨后進行修改。這些可維護性的改變支持實際的用例，比如啟用方法跟蹤或者改變一些Liberty行為來解決部署(恢復)時的問題。重要的是，作為開發人員，你在構建應用程序容器映像時不需要考慮大部分的可服務性問題，因為它們都由Liberty InstantOn處理。 

 

該應用的峰值吞吐量性能不會下降

雖然零擴展和容器部署使啟動時間成為一個重要的性能指標，但應用程序吞吐量仍然是一個重要的考慮因素，因為它最終會影響服務的長期運營成本。如果你通過從應用程序中移除JVM來提高啟動速度，你將失去動態JIT編譯和Java的垃圾收集（GC）技術的好處。使用推測優化的動態JIT編譯是Java平臺的一個關鍵價值主張。

 

用Liberty InstantOn保留JVM意味著你的應用程序獲得了動態JIT編譯和GC技術的所有好處，這些技術已經在Semeru JDK磨礪了幾十年。恢復后的容器只是從執行檢查點之前停止的地方繼續執行，因此通常會達到與不使用InstantOn的傳統Liberty容器相同(或非常接近)的峰值吞吐量(正如你在下面的圖表中從前面描述的相同三個應用程序的測試中看到的)。 

應用程序的安全性沒有受到影響

快速啟動的檢查點/恢復解決方案可能會損害企業部署中最重要的考慮因素之一:安全性。 

首先，Liberty InstantOn不要求應用程序以root身份運行或使用特權容器。Liberty和Semeru開發團隊與CRIU項目合作，將恢復所需的Linux功能集減少到一個足夠小的集，從而在生產中不存在安全問題（請參閱我們如何開發Eclipse OpenJ9 CRIU支持快速Java啟動）。團隊打包了Liberty和Semeru容器映像，這樣你就不需要自己管理Linux功能。

第二，如果容器映像中包含敏感信息(如密鑰),并且該映像隨后被發布到容器儲存庫，則該敏感信息可能會被泄露；此類敏感信息必須僅保留在部署環境中。JDK不允許在檢查點之前使用大多數加密算法。基于Liberty構建的應用程序只在恢復時打開網絡連接，這通常是需要密鑰和其他秘密的地方。對于檢查點端仍然允許的有限的一組加密操作，Semeru確保清除所有敏感信息，以便檢查點中沒有安全風險。 

 

不折不扣的快速啟動和流暢的開發者體驗

 雖然有一系列方法可以縮短無服務器計算的Java啟動時間，但是開發人員的體驗必須盡可能的流暢，這樣才不會給應用程序開發人員帶來不必要的額外責任、學習和工作。我們重申，解決方案必須:：

l 易于開發者在應用中實現。 

l 開發人員可以輕松使用現有的技能和API來編寫應用程序。 

l 開發人員可以輕松地在部署(恢復)時啟用動態配置。 

l 確保應用的峰值吞吐量性能不會下降。 

l 確保app的安全性不受損害。 

 

我們努力在基于檢查點/恢復的解決方案中解決所有這些需求，不僅針對新應用程序，也針對現有應用程序。Liberty InstantOn旨在提供出色的開發人員體驗，同時不影響產品性能。Liberty InstantOn仍有一些局限性，在團隊繼續努力解決這些局限性的同時，這些局限性會得到明確和公開的記錄。