前言
截至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映像，我也比較了它們的性能，
我在以下幾個方面對比了它們的性能：
- 把上述的示例應用程式開發出來要多久？要實作這些框架，我必須查看框架官方檔案以及在諸如Stack Overflow之類的平臺上搜索資訊，
- ** 編譯應用程式需要多長時間？**我已經測驗了執行干凈構建所需的時間，包括生成Docker映像，對于GraalVM，這包括生成本機映像的時間，
- 啟動應用程式需要多長時間？在這里，我測驗了從運行docker up到應用程式正確回應第一個HTTP請求之間的時間，另外，我還比較了啟動后測驗的空閑應用程式的記憶體占用量，
- 應用程式支持請求負載情況如何？我使用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
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/16279.html
標籤：架構設計
上一篇：分布式協調與同步之分布式共識
下一篇：微信搶紅包過期失效實戰案例