2020年你將會選擇哪個微服務框架？

前言

截至2020年，Java仍然是構建Web應用程式的最流行的編程語言之一，儘管它必須面對來自Go，Python和TypeScript等新型語言的激烈競爭。

在Java世界內部，Spring框架已成為微服務開發的事實上的標準，通過諸如Spring Boot和Spring Data之類的庫，該框架易於使用，並且可以進行高效且大部分情況下輕鬆進行開發。

但是，近年來，已經引入了新的框架，聲稱可以縮短Java應用程式的啟動時間並減少其記憶體占用。由於我目前正在使用Java開發基於微服務的大型應用程式，因此我想測試哪種Java框架最適合這種架構。

因此，我的主要重點是開發的易用性以及微服務的資源消耗兩個方面。

對於資源消耗方面，Spring一直都被人詬病，尤其是在涉及單個流程所需的資源開銷。在應用程式伺服器時代，由於實例數量很少，因此這並不是主要問題。但是，隨著微服務架構及其大量小型實例的興起，這個問題變得越來越明顯。正如Christian Lusardi最近所說的那樣：

“我發現使用Spring Boot運行的基本Java應用程式至少需要1GB的RAM，開發中間件應用程式沒關係，但是在微服務體繫結構中，這非常糟糕！”

微服務框架介紹

1 Spring

為瞭解決早期Java Enterprise的複雜性，Spring於2003年應運而生。Spring核心是依賴註入（DI）和麵向切麵編程（AOP），後來衍生出易於使用的Spring MVC等Web應用框架。通過其良好的文檔，全面的各方面整合類庫，Spring使開發人員可以有效地創建和維護應用程式，並提供平坦的學習曲線。

Spring在運行時使用反射執行DI。因此，當啟動spring應用程式時，將在類路徑中掃描帶註解的類。基於此，實例化並鏈接到具體對象。這種做法非常靈活且對開發人員很友好，但它可能使得啟動過程緩慢並占用大量記憶體。另外，將這種機制遷移到GraalVM非常困難，因為GraalVM不支持反射。

2 Micronaut

Micronaut是比較新的全棧微服務框架，由Grails框架的創建者於2018年引入。

Micronaut提供了構建功能全面的微服務應用程式所需的所有工具。同時，它旨在提供快速啟動並減少記憶體占用。通過使用Java註解處理器執行DI，創建面向切麵的代理（而不是運行時）配置應用程式，可以實現此目標。

Micronaut中的許多API均受Spring和Grails的啟發。這無可厚非，畢竟這樣有助於快速吸引Spring及Grails的開發人員。Micronaut提供了諸如Micronaut HTTP，數據，安全性和各種其他技術的連接器之類的模塊。但是，這些庫的成熟度仍落後於Spring的同類庫。

3 Quarkus

Quarkus是Red Hat在2019年引入的Kubernetes原生Java框架。它基於MicroProfile，Vert.x，Netty和Hibernate等標準構建。

Quarkus的目標是通過在容器編排平臺中允許更快的啟動，較低的記憶體消耗和近乎即時的擴展來使Java成為Kubernetes中的領先平臺。Quarkus通過使用自定義的Maven插件在編譯時而不是在構建時執行儘可能多的工作來達到此目的（在Quarkus中，這也稱為編譯時啟動）。

Quarkus使用了大多數現有的標準技術，而且還支持擴展。但是，由於該項目僅在一年之前才開始，所以這些擴展的成熟度和相容性並不總是很清楚。隨著平臺的發展，這種情況將來可能會改變。

4 Helidon MicroProfile

MicroProfile項目立項於2016年，與其前身JEE一樣，MicroProfile是可以由各種供應商實施的規範。到目前為止，MicroProfile規範已經提出了多種實現方式，最著名的是Payara Micro和Helidon MP。

Payara是從GlassFish派生的Jakarte EE伺服器，而Payara Micro是其MicroProfile實現。Helidon是Oracle在2018年啟動的運行時，提供了自己的MicroProfile規範實現。

由於它們是從JEE派生的，因此MicroProfile規範已經很成熟並且有據可查。但是，缺少用於現代技術的連接器或替代諸如Spring Data和Spring Security之類的庫的方法。

此外，由於同時開始了Jakarta EE（也在Eclipse Foundation中）的開發，MicroProfile的未來尚不清楚。因此，似乎兩個項目將來可能會合併。

微服務框架全方位大PK！

為了比較上述4個微服務框架，我已經使用它們實現了一個簡單的應用程式。該示例應用程式包括一個用於創建，讀取，更新和刪除對象的REST介面，以及將這些對象存儲到表中的介面。我使用OpenJDK Docker映像運行了所有應用程式。如果該框架支持生成本機GraalVM映像，我也比較了它們的性能。

我在以下幾個方面對比了它們的性能：

1. 把上述的示例應用程式開發出來要多久？要實現這些框架，我必須查看框架官方文檔以及在諸如Stack Overflow之類的平臺上搜索信息。
2. ** 編譯應用程式需要多長時間？**我已經測試了執行乾凈構建所需的時間，包括生成Docker映像。對於GraalVM，這包括生成本機映像的時間。
3. 啟動應用程式需要多長時間？在這裡，我測試了從運行docker up到應用程式正確響應第一個HTTP請求之間的時間。另外，我還比較了啟動後測試的空閑應用程式的記憶體占用量。
4. 應用程式支持請求負載情況如何？我使用JMeter進行負載測試，並對應用程式進行了測試，其中25％的請求執行資料庫寫入，而75％的請求僅執行資料庫讀取。然後，我再次根據其峰值性能來測量應用程式的記憶體占用量。

我在具有四個Intel Haswell CPU和15 GB記憶體且運行Ubuntu 19.01的Google Cloud Platform虛擬機上執行了所有測試。所有測量均已重覆多次，以避免干擾因素。您可以在GitHub上找到使用的腳本以及原始數據。

https://github.com/lizzyTheLizard/medium-java-framework-compare/tree/master/compare

測試結果

1 上手難度

由於我以前就有Spring Boot的知識，所以這是一個不公平的比較。但是，在查詢文檔以及可用的信息和示例時，Spring確實是迄今為止使用起來最簡單的框架。

Micronaut的文檔做得很好，並且具有與Spring和Grail類似的API。因此，Spring開發人員很容易開始使用它。

我認為，Quarkus的學習曲線較為陡峭，因為與Spring和Micronaut相比，庫和API的成熟度較低。我特別缺少簡單的資料庫訪問許可權。

在我看來，Helidon顯然是最後一名，因為我為應用程式運行付出了很大的努力。

2 編譯時間

所有框架，使用OpenJDK時的編譯時間都非常相似，並且在6.98秒（使用JDBC的Spring）和10.7秒（Quarkus）之間。

但是，原始GraalVM映像的生成非常耗時，花費了231.2秒（使用JDBC的Micronaut）和351.7秒（使用JPA的Micronaut）之間。這使得本機映像對於開發基本上毫無用處，因為等待四分鐘來編譯一個簡單的應用程式實在太多了。

3 啟動運行時間

使用Spring Data的Spring Boot應用程式平均花了8.16秒來啟動。刪除JPA和Spring Data可以將其減少到5.8秒。

正如官方所說，Micronaut（使用JPA的時間為5.08秒，使用JDBC的時間為3.8秒）和Quarkus（5.7秒）都保證了縮短啟動時間的承諾。

Helidon MP甚至比Spring慢-平均耗時為8.27秒。

但是，真正的贏家是GraalVM。本機映像的啟動時間在1.39秒（Quarkus）和1.46秒（使用JDBC的Micronaut）之間，比OpenJDK實現要快得多。

所有框架運行時使用的記憶體使用情況非常相似。Spring分配了420 MB記憶體（使用Spring Data）和261 MB（使用JDBC）。使用JPA時Micronaut的記憶體為262 MB，使用JDBC時為178 MB。197 MB的Quarkus表現更好。Helidon MP耗時414 MB，與Spring Boot類似。

同樣，僅使用7 MB（Quarkus）和27 MB（Micronaut使用JPA）的記憶體，原生GraalVM映像的表現大大優於OpenJDK。

4 峰值負載性能

在負載下，Spring Boot表現出色，能夠處理每秒342（使用Spring Data）和216（JDBC）請求（r/s），並使用581 MB（Spring Data）和484 MB（JDBC）記憶體。Helidon顯然是最後一名，只能提供175 r/s的速度，同時分配超過1 GB的記憶體。

其他框架能夠在400 r/s（Quarkus作為本機映像運行）和197 r/s（OpenJDK上的Quarkus）之間提供服務。各種Micronaut實現介於兩者之間，與JDBC相比，JPA和本機映像比OpenJDK略有優勢。

在記憶體使用方面，OpenJDK上的Quarkus表現出色，僅消耗255 MB記憶體。這甚至比同一個應用程式作為本機映像運行要少得多，該應用程式平均花費368 MB的記憶體。

但是，Micronaut卻非常浪費。在OpenJDK中運行的JPA實現平均使用880 MB，比Spring的記憶體使用量高50％以上。但是，使用JDBC和本機映像有助於Micronaut將其記憶體占用空間減少到367.8 MB。

結論

與Spring和MicroProfile之類的現有框架相比，新的Java框架Micronaut和Quarkus保證了更快的啟動時間和更低的記憶體占用。

他們的確兌現了這一諾言-但只有在閑置或負載很小的情況下才可以。在這裡，它們的性能優於Spring，特別是將它們與本地GraalVM圖像結合使用時。但是，在高負載下，它們即使在作為本機映像運行時也無法提供太多優勢。

到目前為止，Spring在開發上給Java開發者最佳體驗，而且我認為它也仍然是最適合微服務應用程式的Java框架（即使啟動時的性能比較差）。

讓我感到驚訝的是，使用Hibernate / JPA / Spring Data的成本非常高。即使對於這個非常簡單的應用程式，在記憶體（以及r/s）方面的開銷也是巨大的。在這裡，我特別喜歡Micronaut Data的解決方案，該解決方案無需JPA即可自動生成Dao代碼。我認為Micronaut Data以後可以添加到Spring Data方案中。

事實證明，本機GraalVM映像在啟動時具有令人難以置信的快速性和記憶體效率，但是在負載下，它們並沒有明顯的優勢。由於本機GraalVM的生成會帶來一些額外的困難，並且編譯時間會急劇增加，因此該技術目前僅在需要快速啟動時才有用。例如在Serviceless架構中。

歡迎關註我的公眾號：：一點教程。獲得獨家整理的學習資源和日常乾貨推送。
如果您對我的系列教程感興趣，也可以關註我的網站：yiidian.com