Quarkus框架介紹

Quarkus 是一個為 Java 虛擬機（JVM）和原生編譯而設計的全堆棧 Kubernetes 原生 Java 框架乒疏，用于專門針對容器優(yōu)化 Java，并使其成為無服務器钦勘、云和 Kubernetes 環(huán)境的高效平臺淀散。

Quarkus可與常用 Java 標準、框架和庫協(xié)同工作桃笙，例如 Eclipse MicroProfile氏堤、Spring（作為 2020 年紅帽峰會追蹤的一個環(huán)節(jié)一起演示）、Apache Kafka、RESTEasy (JAX-RS)鼠锈、Hibernate ORM (JPA)闪檬、Spring、Infinispan购笆、Camel 等粗悯。

Quarkus 的依賴注入解決方案基于 CDI（上下文和依賴注入），且包含一個擴展框架來擴展功能并將其配置同欠、引導并集成到您的應用中样傍。添加擴展就像添加依賴項一樣容易；或者铺遂，您可以使用 Quarkus 工具衫哥。

此外，它還向 GraalVM（一種通用虛擬機襟锐，用于運行以多種語言（包括 Java 和 JavaScript）編寫的應用）提供正確信息撤逢，以便對應用進行原生編譯。

借助GraalVM可以快速提升微服務的啟動速度和減少內存占用捌斧。和spring boot相比簡直“真香”笛质，現(xiàn)在已發(fā)布1.0.RC1版本。它同oracle開源的Helidon相比較如何捞蚂？

專為開發(fā)人員而設計

Quarkus的設計從一開始就立足于簡單易用妇押，其功能幾乎不需要配置即可正常使用。

開發(fā)人員可以為其應用選擇所需的 Java 框架姓迅，而這些應用可以在 JVM 模式下運行敲霍，也可以在原生模式下進行編譯和運行。

為了方便開發(fā)人員的工作丁存，Quarkus 還包含以下功能：

• 實時編碼肩杈，旨在讓開發(fā)人員能夠即時檢查代碼更改的影響并快速進行故障排除
• 帶有嵌入式托管事件總線的統(tǒng)一命令式和響應式編程
• 統(tǒng)一配置
• 簡單的原生可執(zhí)行文件生成

容器優(yōu)先

無論是將應用托管在公共云上還是內部托管的 Kubernetes 集群中，快速啟動和低內存消耗等特性對于降低總體主機成本來說都至關重要解寝。

Quarkus 的開發(fā)遵從了容器優(yōu)先的原則扩然，這意味著它已通過以下方式針對降低內存使用和加快啟動時間進行了優(yōu)化：

• 鼎力支持 Graal/SubstrateVM
• 構建時元數(shù)據(jù)處理
• 減少反射的使用
• 本機映像預啟動

因此，Quarkus 構建的應用其內存消耗只有傳統(tǒng) Java 的 1/10聋伦，而且啟動時間更快（快了 3 倍）夫偶，這些都大大降低了云資源的成本。

命令式和響應式代碼

在設計上觉增，Quarkus 能夠在開發(fā)應用時無縫地結合熟悉的命令式代碼和非阻塞兵拢、響應式樣式。

這對于習慣使用命令式模型而不想切換風格的 Java 開發(fā)人員以及使用云原生/響應式方法的開發(fā)人員都非常有用逾礁。

Quarkus 開發(fā)模型可以適應您正在開發(fā)的任何應用说铃。

對于在新的無服務器架構、微服務、容器腻扇、Kubernetes债热、功能即服務（FaaS）和云環(huán)境中運行 Java 而言，Quarkus 堪稱是一個有效的解決方案衙解，因為在創(chuàng)建它時就充分考慮了所有這些因素阳柔。

四大理由告訴您為何要試試 Quarkus

Java? 仍然是許多開發(fā)人員選擇的編程語言焰枢，但 Kubernetes 和無服務器等云原生技術的發(fā)展卻對此發(fā)起了挑戰(zhàn)蚓峦。了解為什么說 Quarkus 是開發(fā)人員使用 Knative 和無服務器架構的必備 Java 框架。

擺脫動態(tài)

Quarkus認為济锄，在容器化的世界中暑椰，企業(yè)Java運行時的大部分動態(tài)特性并不是真正需要的。將應用程序構建到容器鏡像后荐绝，通常不會更改功能一汽。企業(yè)容器帶來的所有動態(tài)都允許非常強大和靈活的編程和部署模型，但是一旦我們的應用程序在容器內啟動低滩，它們通常就不再發(fā)生變化召夹。

Quarkus采用的方法是定制一個僅包含應用程序所需內容的運行時，并簡化企業(yè)運行時的大部分動態(tài)恕沫。企業(yè)Java代碼嚴重依賴于控制反轉（IoC）监憎，又名“不要調用給我們，我們會調用你”婶溯。想一想依賴注入 @Inject鲸阔，HTTP資源的@Path和@GET，或者事件觀察者@Observes迄委。我們開發(fā)人員聲明性地指定應該發(fā)生什么褐筛，并且實現(xiàn)確保它發(fā)生。這能夠有一個非常高效的編程模型叙身，但在運行時也會帶來繁重的工作渔扎，因為有人必須將所有這些松散的末端組合在一起。現(xiàn)在信轿，我們的想法是晃痴，如果我們的應用程序不應該在運行時發(fā)生變異，那么大多數(shù)動態(tài)都可以在構建時解決虏两。結果代碼可以主要包括直接調用; 所有的魔力都被摧毀了愧旦。

Quarkus還支持使用GraalVM構建本機可執(zhí)行文件。通過這種方法定罢，我們使用提前（AOT）編譯來預構建和編譯我們的應用程序到本機可執(zhí)行文件笤虫，這些可執(zhí)行文件不需要動態(tài)掃描并將所有類加載到JVM中。與常規(guī)JVM相比，生成的可執(zhí)行文件啟動速度非城眚牵快酬凳，并且資源消耗較低。

標準的力量

看看Quarkus遭庶，我發(fā)現(xiàn)最吸引人的是它建立在已知的企業(yè)標準之上宁仔，例如CDI，JAX-RS等等峦睡。我們不是使用成熟的應用程序服務器翎苫，而是通過本機可執(zhí)行文件或使用Java運行時在優(yōu)化的運行時中運行應用程序。

許多企業(yè)開發(fā)框架要求開發(fā)人員再次學習新的API榨了，有時更少煎谍，或重新發(fā)明輪子，例如如何實現(xiàn)REST端點龙屉。但是呐粘，從開發(fā)人員和項目的角度來看，當現(xiàn)有的API和解決方案足夠時转捕，我看不到重新學習和重寫應用程序的好處作岖。通過Quarkus采用的方法，開發(fā)人員可以編寫并獲取基于CDI五芝，JAX-RS和JPA的應用程序痘儡，并通過將運行時更改為Quarkus來優(yōu)化它。

企業(yè)Java的擴展

除了Java Enterprise中包含的內容之外与柑，Quarkus還擴展了項目中可能需要的可用功能谤辜。除了受支持的Java EE和MicroProfile規(guī)范之外，還有用于響應式消息傳遞的Quarkus擴展价捧，Vert.x或Camel丑念。EventBus例如，Vert.x的類型是可注入的@Inject结蟋。這符合我們在EE中習慣的開發(fā)人員體驗脯倚。

我喜歡從已知的企業(yè)API開始的方法，并通過保持相同的聲明性方法來擴展它們與應用程序所需的內容嵌屎。

無服務器企業(yè)Java

Quarkus的獨特賣點之一推正，本機運行Java應用程序是極短的啟動時間。同樣嚴肅地說宝惰，在幾毫秒內開始的一切都是需求的游戲轉換器植榕，我們需要快速啟動和拆除我們的應用程序。

這仍然是其他適合幾乎所有Java世界的最大限制之一尼夺。在性能方面尊残，JVM需要大量的時間來啟動炒瘸，更不用說預熱HotSpot引擎并達到它的全部吞吐量。很公平寝衫，這是有原因的顷扩，因為運行時主要針對長時間運行的流程中的吞吐量進行了優(yōu)化。隨著應用程序應該快速啟動的需求慰毅，以及快速啟動以便用戶可以等待它隘截，僅僅以正常方式啟動JVM是不夠的。

上面提到的AOT編譯方法使我們能夠在將Java應用程序作為本機映像執(zhí)行時編寫它們汹胃。通過這樣做婶芭，我們使我們的Java工作負載能夠在“無服務器”環(huán)境中執(zhí)行，我們可以將工作負載擴展到零统台，并且能夠快速啟動而不會在初始啟動時間內懲罰用戶雕擂。

然而，通常情況下贱勃，在實踐中生活并不那么容易。GraalVM不支持常規(guī)JVM的整個功能集谤逼，例如贵扰，它不以通常的方式支持Reflection，并且許多企業(yè)運行時不會作為本機可執(zhí)行文件運行流部。

話雖如此戚绕，通過開發(fā)具有此運行時限制的實現(xiàn)，Red Hat的朋友們?yōu)镼uarkus的開發(fā)投入了多少工作枝冀，這令人印象深刻舞丛。只有這樣我們才能組合這些部分并以本機方式運行我們的Java Enterprise應用程序。Quarkus應用程序在普通JVM上運行良好果漾，啟動速度“足夠快”球切，至少在我看來，不到一秒绒障。

盡管對于Enterprise Java來說都是好消息吨凑，并且要求縮小到零并因此快速啟動，從我的角度來看户辱，啟動時間并不是一切鸵钝。雖然這個新的運動當然很有趣，但我們不應忘記庐镐，絕大多數(shù)企業(yè)正在運行恩商，并且可能會繼續(xù)運行他們的工作量更長的時間。然而必逆，在運行時擺脫大多數(shù)“動態(tài)”的方法也對整體資源消耗產生積極影響怠堪，并且肯定是有希望的韧献。

但是，在我看來研叫，本機啟動時間甚至不是最大的好處锤窑。

最小的周轉時間

Quarkus允許我們的開發(fā)人員通過極快的熱重新加載來修改和測試我們的業(yè)務代碼。quarkus:devMaven插件的目標使我們能夠更改和保存文件嚷炉，框架重新加載類并以自動方式交換正在運行的應用程序內的行為渊啰。我們可以在幾毫秒之后，即在人類反應時間內申屹，立即重新執(zhí)行并測試已更改的功能绘证。因此，開發(fā)周期和反饋環(huán)路的周轉時間變得越來越短哗讥。正如我的朋友埃德森·亞納加所說的那樣：“這才是編碼嚷那，激發(fā)了喜悅”。我完全同意杆煞。

總的來說魏宽，我是短暫延遲的忠實粉絲。戰(zhàn)斗延遲的咒語是我認為使很多Google服務使用的樂趣决乎。一般來說队询，在編碼時，我們希望得到并留在流程中构诚。開發(fā)人員的思考時間非常寶貴蚌斩，我們不希望被這個流程中斷并等待超過幾秒鐘; 否則一個人會分心，拿起另一杯咖啡范嘱，或者更糟糕的是送膳，在社交媒體上看，并引起你的注意丑蛤。

在我看來叠聋，這個最小的周轉時間是Quarkus框架的最大優(yōu)勢。但是盏阶，即使沒有Quarkus晒奕，如果使用現(xiàn)代應用程序容器和一些工具，您也可以實現(xiàn)熱重新部署時間名斟，從而實現(xiàn)保持流式開發(fā)模式脑慧。例如，Open Liberty可以在不到一秒的時間內部署應用程序砰盐，當與WAD等工具結合使用時闷袒，我們可以真正改善周轉時間，如本視頻所述岩梳。

關于集成測試的一些注意事項：還有一點非常有用的是囊骤，整個Quarkus應用程序的快速啟動使得測試實際上更適合于部署級別的集成測試晃择，而不是代碼級別。也就是說也物，使用應用程序的通信接口部署單個應用程序并進行端到端測試宫屠。但是，構建時間較慢的主要原因之一是長時間運行的測試階段滑蚯，即啟動應用程序或部分應用程序浪蹂。單。測試運行告材。即使Quarkus提供的啟動時間很短坤次，這種影響也會變得巨大，一旦越來越多的測試場景成為管道的一部分斥赋。我們應該做什么缰猴，一般來說，是在我們的測試套件執(zhí)行期間定義單個或最多幾個部署疤剑，我們對應用程序進行端到端測試滑绒，而無需重新啟動正在運行的測試應用程序。無論我們是使用Quarkus的測試功能骚露，還是使用專門的測試項目來破壞啟動的應用程序蹬挤。

持續(xù)交付周轉時間

本機構建alàGraalVM的缺點之一是這個構建需要花費很多時間。取決于你的機器三十秒甚至更長時間棘幸。甚至比我們在Java世界中應該習慣的更長。在我們的開發(fā)流程中倦零，這意味著我們不希望僅在Continuous Delivery管道內執(zhí)行每次代碼更改的本機構建误续。即使如此，我們還需要考慮到這將減慢我們的整體管道執(zhí)行時間扫茅，否則可以更快地執(zhí)行蹋嵌。遵循建立我們的應用程序只需一次并在我們投入生產之前對其進行全面測試的咒語，這意味著端到端/系統(tǒng)/驗收測試周轉時間也會增加葫隙。

除了本機可執(zhí)行文件之外栽烂，Quarkus還支持精簡部署工件，作為瘦JAR恋脚，它只包含由我們開發(fā)的實際業(yè)務邏輯類腺办。Quarkus可以采用這種方法，因為它分離了庫和我們自己的代碼的關注點糟描』澈恚看看內置的大小和內容*-runner.jar。實現(xiàn)和所需的庫包含在lib/目錄船响。與常規(guī)Java Enterprise應用程序一樣躬拢，這使我們可以通過優(yōu)化寫時復制文件系統(tǒng)鏡像層來利用Docker的優(yōu)勢躲履。

如果您對這些鏡像層有所了解，您會發(fā)現(xiàn)這在Docker化世界中確實有意義聊闯。容器鏡像的構建和傳輸時間也會影響整個構建執(zhí)行時間工猜。在這種情況下，精簡部署工件可提供最佳體驗菱蔬。根據(jù)我的經(jīng)驗篷帅，整體鏡像尺寸很少重要; 重要的是我們能夠多快地重新構建和重新傳輸實際變化的層。即使使用微小的原生圖像汗销，與薄的部署工件相比犹褒，這些尺寸和時間仍然要大幾個數(shù)量級。

在項目中弛针，我們需要在管道執(zhí)行時間和容器啟動時間之間進行權衡叠骑。除了擴展到零的方法之外，部署方案應該使用某種形式的藍綠色部署削茁，以避免用戶的停機時間宙枷。考慮到這一點茧跋，生產啟動時間變得不那么成問題慰丛，因為舊版本將始終保持活動狀態(tài)，直到新版本準備好滾動瘾杭。如果您參與具有足夠用戶的企業(yè)項目诅病，以便無需考慮擴展到零，但是快速將新版本發(fā)布到生產中粥烁，那么精簡部署工件的方法可能更合適贤笆。

目前的局限

目前的框架限制之一是Quarkus還不支持一些EE標準的全套。例如讨阻，不支持EJB芥永。但是，支持事務钝吮，其他一些功能可以用Quarkus自己的功能代替埋涧。一個例子是調度Quarkus發(fā)布自己的@Scheduled注釋。這似乎是一種合理的方法奇瘦，試圖實現(xiàn)項目可能需要的功能涂臣，并從我的角度提供已經(jīng)支持大部分所需功能的框架演痒。

然而甫题，Quarkus的行動非常迅速晴叨，所以讓我們看看這些差距是如何關閉的。再一次麻捻，我相信這個框架已經(jīng)成熟和詳盡纲仍，這是非常令人印象深刻的呀袱。

Maven插件聲明，特別是它如何在Quarkus文檔中做廣告是可以改進的其他東西郑叠。很多人似乎都喜歡將大量的XML放入其中pom.xml夜赵，但是，我并沒有那么多乡革。我更喜歡保持Java應用程序關注點的清晰分離寇僧，而不是讓Maven“構建所有東西”。如果我們允許項目使用Maven的默認值沸版，我們將所需的LoC保持在pom.xml最低限度內嘁傀，并且讓所有內容都由CI基礎結構處理。使用Quarkus视粮，您至少可以擺脫其大部分pom.xml定義细办，并且僅在CI管道中定義和構建本機映像。然后可以pom.xml稍微歸結一下蕾殴。

但是笑撞，文檔承諾有一個本地CLI“即將推出”，這聽起來很有希望钓觉。

結論

Quarkus將云原生Enterprise Java提升到了一個新的水平茴肥，并支持以前無法實現(xiàn)的方案，特別是在應用程序啟動時間方面荡灾。如果您計劃將規(guī)模擴展為零瓤狐，那么這肯定是您想要了解的技術。

我非常喜歡Quarkus如何跟進一些技術之前采用的方法批幌，更進一步芬首，并提供一個單一的框架，一個傘逼裆。這使開發(fā)人員可以輕松入門，使用他們可能已經(jīng)熟悉的企業(yè)標準赦政，例如CDI或JAX-RS胜宇。在我看來，這是一個很大的好處：不是試圖重塑企業(yè)世界恢着，使用熟悉的技術桐愉，而是通過高度優(yōu)化的實施。

作為開發(fā)人員掰派，我發(fā)現(xiàn)AOT編譯和其他JVM優(yōu)化一般非常有趣从诲。您可能還會看一下OpenJ9 JVM及其優(yōu)化; 將運行時與Quarkus應用程序的JVM執(zhí)行模式相結合可能會很有趣。

參考文檔

https://www.redhat.com/zh/topics/cloud-native-apps/what-is-quarkus