Quarkus是新的“超音速，亞原子” Java框架，目前引起了很多關注。 對于企業Java的未來而言，此構建和運行時工具背后的思想確實比我們感興趣。 使用Quarkus有什么好處和缺點？

擺脫動力

Quarkus認為，在容器化的世界中，企業Java運行時的大多數動態并不是真正需要的。 將應用程序構建到容器映像后，通常不應更改其功能。 企業容器所帶來的所有動態都允許進行功能強大且靈活的編程和部署模型，但是一旦我們的應用程序在容器內啟動后，它們通常將不再更改。

Quarkus采取的方法是定制僅包含應用程序所需內容的運行時，并簡化企業運行時的大部分動態。 企業Java代碼在很大程度上依賴于控制反轉（IoC），也就是“不給我們打電話，我們給您打電話”。 想依賴注入的ALA @Inject ，HTTP與資源@Path和@GET ，或與事件觀察家@Observes 。 我們的開發人員以聲明方式指定應該發生的情況，并確保實現。 這允許非常高效的編程模型，但在運行時也會帶來繁重的工作，因為有人必須將所有這些松散的末端放在一起。 現在，我們的想法是，如果我們的應用程序不應該在運行時發生變異，那么大多數這些動態因素都可以在構建時解決。 然后，生成的代碼主要可以包括直接調用。 所有的魔法都被燒掉了。

現在，這是否與過去（從今天看來）不支持IoC且需要直接調用代碼中功能的笨重的企業框架所實現的結果相同？ 從開發人員的角度來看，一點也不。 在我們的代碼中，我們仍然使用相同的有效聲明式方法，相同的注釋。 構建過程負責將動力帶回現實。

Quarkus還支持使用GraalVM構建本機可執行文件。 通過這種方法，我們使用提前（AOT）編譯來將應用程序預先構建和編譯為本地可執行文件，而無需動態掃描所有類并將其加載到JVM中。 與常規JVM相比，生成的可執行文件啟動速度非常快，并且具有較低的資源消耗。

標準的力量

看一下Quarkus，我發現最吸引人的是它基于已知的企業標準（例如CDI，JAX-RS等）構建。 我們可以通過本機可執行文件或Java運行時，在優化的運行時中運行應用程序，而不是使用成熟的應用程序服務器。

許多起義企業框架要求開發人員再次學習新的API，有時（有時甚至更少）重新發明方向，例如如何實現REST端點。 但是，從開發人員和項目的角度來看，當現有的API和解決方案足夠時，我看不到重新學習和重新編寫應用程序的好處。 使用Quarkus采用的方法，開發人員可以編寫和采用基于CDI，JAX-RS和JPA的應用程序，并通過將運行時更改為Quarkus對其進行優化。

企業Java擴展

除了Java Enterprise中包含的功能外，Quarkus還擴展了項目中可能需要的可用功能。 除了受支持的Java EE和MicroProfile規范外，還有用于響應消息傳遞的Quarkus擴展，Vert.x或Camel。 例如，可以通過@Inject EventBus Vert.x的EventBus類型。 這與我們在EE中習慣的開發人員經驗相符。

我喜歡從已知的企業API開始，然后通過保持相同的聲明性方法來擴展它們，以進一步滿足應用程序的需求。

無服務器企業Java

Quarkus獨特的賣點之一是在本地運行Java應用程序，它的啟動時間極短。 認真地說，幾毫秒內開始的一切都會改變需求，我們需要快速啟動和拆除我們的應用程序。

在幾乎適用于所有Java的世界中，這仍然是最大的限制之一。 從性能角度來看，JVM需要大量時間來啟動，更不用說預熱HotSpot引擎并達到其全部吞吐量了。 相當公平，這是有原因的，因為運行時已針對長時間運行的流程中的吞吐量進行了優化。 由于應用程序應該以快速啟動為目標，以便用戶可以等待它，因此，以常規方式啟動JVM根本不夠。

提到的AOT編譯方法使我們能夠在將Java應用程序作為本機映像執行時編寫它們。 通過這樣做，我們使Java工作負載能夠在“無服務器”環境中執行，在該環境中我們可以將工作負載擴展到零，并且能夠快速啟動，而不會以初始啟動時間來懲罰用戶。

但是，通常情況下，生活并不那么容易。 GraalVM不支持常規JVM的全部功能集，例如，它不以通常的方式支持Reflection，并且許多企業運行時都不會作為本機可執行文件開箱即用。

話雖如此，通過考慮到運行時的局限性來開發實現，在Red Hat的朋友們為Quarkus的開發付出了多少工作，這確實令人印象深刻。 只有這樣，我們才能結合這些部分并以本機方式運行Java Enterprise應用程序。 Quarkus應用程序在正常的JVM上也可以很好地運行，至少在我看來，啟動過程“足夠快”不到一秒鐘。

盡管對于Enterprise Java而言，這是個好消息，但從我的角度來看，要求將其縮放到零并Swift啟動，但啟動時間并不是全部。 盡管這一新舉動當然很有趣，但我們不應該忘記，絕大多數企業正在運行，并且很可能會繼續運行較長時間的工作量。 但是，在運行時消除大多數“動態”的方法也對總體資源消耗產生積極影響，并且肯定是有希望的。

但是，在我看來，原生啟動時間甚至不是最大的好處。

開發周轉時間：“令人欣喜的編碼”

Quarkus允許我們的開發人員以極快的熱重載來修改和測試我們的業務代碼。 Maven插件的quarkus:dev目標使我們能夠更改和保存文件，框架可以自動方式重新加載類并在運行的應用程序內部交換行為。 我們可以在幾毫秒后重新執行并測試更改后的功能，這相當于在人類反應時間內立即完成。 開發周期和反饋循環的周轉時間因此變得盡可能短。 正如我的朋友埃德森·柳永（Edson Yanaga）所說：“這是激發喜悅的編碼”。 我完全同意。

總的來說，我非常喜歡短延遲。 我認為，應對延遲的口頭禪是使許多Google服務使用起來令人愉悅。 通常，在編碼時，我們希望獲得并留在流程中。 開發人員的思考時間非常寶貴，我們不希望被這種流程打擾，而要等待幾秒鐘以上的時間； 否則，一個人會分心，拿另一杯咖啡，或更糟糕的是，他們在社交媒體上轉眼，便引起了您的注意。

在我看來，最短的周轉時間是Quarkus框架的最大優勢。 但是，即使沒有Quarkus，如果您使用現代的應用程序容器和某些工具，您也已經可以實現熱重新部署時間，從而實現了按需開發模式。 例如，Open Liberty可以在不到一秒鐘的時間內部署應用程序，并且與WAD之類的工具結合使用時，我們可以真正縮短周轉時間，如本視頻所述 。

有關集成測試的一些注意事項：很有幫助的是，整個Quarkus應用程序的快速啟動使測試實際上更適合于在部署級別（而不是代碼級別）進行集成測試。 即，使用應用程序的通信接口部署和端到端測試單個應用程序。 但是，構建時間緩慢的主要原因之一是測試階段的運行時間長，每個階段都會啟動應用程序或應用程序的一部分。 單。 測試運行。 即使Quarkus提供的啟動時間很短，一旦越來越多的測試場景成為管道的一部分，這種影響也會變得巨大。 通常，我們應該做的是在測試套件執行過程中定義一個或最多幾個部署，在這些部署中，我們對應用程序進行端到端測試，而無需在這之間重新啟動正在運行的被測應用程序。 無論我們使用Quarkus的功能進行測試還是使用專門的測試項目來完善已啟動的應用程序，這都無關緊要。

連續交貨周轉時間

GraalVM本機構建的缺點之一是該構建需要很長的時間。 視您的機器而定，三十秒或更長時間。 甚至比我們在Java世界中應該習慣的要更長的時間。 在我們的開發管道中，這意味著我們不想在每次代碼更改時都執行本機構建，而僅在持續交付管道中執行。 即使如此，我們仍然需要考慮到這會減慢整體管道執行時間，否則可能會更快地執行。 遵循只構建應用程序一次并在交付生產之前對完全構建的應用程序進行全面測試的口號，這意味著端到端/系統/驗收測試的周轉時間也會增加。

除了本地可執行文件之外，Quarkus還支持精簡部署工件，如精簡JAR，它僅包含由我們開發的實際業務邏輯類。 Quarkus可以使用這種方法，因為它將庫和我們自己的代碼分開。 看一下構建的*-runner.jar的大小和內容。 實現和所需的庫包含在lib/目錄下。 與常規Java Enterprise應用程序一樣，這使我們能夠通過優化寫時復制文件系統映像層來利用Docker的優勢。 如果您對這些圖像層有所了解，您會注意到在容器化的世界中這當然是有道理的。 容器映像的構建和傳輸時間也影響整個構建執行時間。 在這種情況下，精簡部署工件可提供最佳體驗。 根據我的經驗，總體圖像大小幾乎沒有關系； 重要的是，我們可以多快地重建并重新傳輸實際更改的層。 即使使用微小的本機映像，與精簡的部署工件相比，這些大小和時間仍要大幾個數量級。

在項目中，我們需要在管道執行時間和容器啟動時間之間進行權衡。 除了將規模縮減為零的方法外，部署方案還應使用某種形式的藍綠色部署，以免用戶無論如何都要停機。 考慮到這一點，生產啟動時間不再是問題，因為舊版本將始終保持活動狀態，直到新版本準備推出為止。 如果您參與的企業項目具有足夠的用戶，因此不必考慮將比例縮放到零，而是將新版本快速交付生產，則精簡部署工件的方法可能更合適。

當前限制

當前框架的限制之一是Quarkus還不支持某些EE標準的全部集合。 例如，不支持EJB。 但是，支持事務，并且某些其他功能可以用Quarkus自己的功能代替。 一個例子是調度，其中Quarkus附帶了自己的@Scheduled注釋。 從我的角度來看，這似乎是一種合理的方法，可以嘗試實現項目可能需要的功能并提供已經支持大多數必需功能的框架。

但是，Quarkus的發展非常Swift，所以讓我們看看如何縮小這些差距。 同樣，我相信這個框架看起來多么成熟和詳盡，令人印象深刻。

Maven插件聲明，尤其是如何在Quarkus文檔中進行廣告宣傳，還有其他可以改進的地方。 很多人似乎都喜歡將大量XML放入其pom.xml ，但是我并不是那么多。 我寧愿保持對Java應用程序關注點的清晰區分，而不是讓Maven“構建一切”。 如果我們允許項目使用Maven的默認值，我們將pom.xml內所需的LoC保持在最低限度，并由CI基礎結構來處理最頂層的所有內容。 例如，使用Quarkus，您至少可以擺脫其大部分pom.xml定義，而僅在CI管道中定義和構建本機映像。 然后有可能將pom.xml稍微簡化一下。

但是，該文檔承諾將有一個本機CLI“即將推出”，這在我看來是有希望的。

結論

Quarkus將云原生企業Java提升到一個新的水平，并實現了以前不可能實現的方案，尤其是在應用程序啟動時間方面。 如果您打算將規模縮小到零，那么這無疑是您想要研究的技術。

我非常喜歡Quarkus如何跟進一些技術以前采用的方法，將它們進一步發展，并提供一個單一的框架，包括所有的保護傘。 這使開發人員可以輕松上手，使用他們可能已經熟悉的企業標準，例如CDI或JAX-RS。 在我看來，這是一個很大的好處：不是試圖重塑企業世界，而是使用熟悉的技術，而是通過高度優化的實現。

作為開發人員，我發現AOT編譯和其他JVM優化通常非常有趣。 您還可以查看OpenJ9 JVM及其優化。 將運行時與Quarkus應用程序的JVM執行模式結合起來可能會很有趣。

要獲得“純” Java EE的快速開發人員體驗，您可以查看WAD以及如何將其集成到Docker中。

翻譯自: https://www.javacodegeeks.com/2019/04/thoughts-quarkus.html

總結

以上是生活随笔為你收集整理的关于夸克的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。