前提介紹

本系列文章主要講解如何基于Quarkus技術(shù)搭建和開發(fā)"專為Kubernetes而優(yōu)化的Java微服務(wù)框架"的入門和實(shí)踐，你將會(huì)學(xué)習(xí)到如何搭建Quarkus微服務(wù)腳環(huán)境及腳手架，開發(fā)Quarkus的端點(diǎn)服務(wù)，系統(tǒng)和應(yīng)用層級的配置介紹與Quarkus的編程模型分析，創(chuàng)建Quarkus的應(yīng)用Uber-jar文件以及集成到Kubernetes的環(huán)境中。

1. 學(xué)習(xí)Quarkus的云原生微服務(wù)的零基礎(chǔ)搭建和開發(fā)實(shí)踐
2. 分析Quarkus的編程模型以及與Kubernetes環(huán)境進(jìn)行集成

面向的人群

Java軟件開發(fā)人員、系統(tǒng)架構(gòu)師、微服務(wù)開發(fā)愛好者、運(yùn)維部署人員等。

目前的狀況

近幾年由于云原生技術(shù)的普及，越來越多的用戶開始使用容器來運(yùn)行微服務(wù)應(yīng)用，隨著微服務(wù)的快速發(fā)展，spring全家桶已然成為了java框架的事實(shí)標(biāo)準(zhǔn)，包括單體應(yīng)用使用的spring Framework和springboot，微服務(wù)間服務(wù)治理框架spring cloud，生態(tài)系統(tǒng)完善，各種組件層出不窮。

Java云原生化痛點(diǎn)

• 輕量化容器技術(shù)的誕生促使JVM服務(wù)變得更加臃腫
  • 微服務(wù)架構(gòu)的引入，使我們的服務(wù)顆粒度變得越來越小，輕量且能快速啟動(dòng)的應(yīng)用能夠更好的適應(yīng)容器化環(huán)境。 以我們目前常規(guī)的Spring Boot應(yīng)用來說，一般Restful服務(wù)的jar包大概是30M左右，如果我們將JDK以及相關(guān)應(yīng)用打包成docker鏡像文件大概是140M左右。
  • 常規(guī)的Go語言的可執(zhí)行程序生成鏡像包一般不會(huì)超過50M。如何讓臃腫的Java應(yīng)用瘦身使他易于容器化，成為Java應(yīng)用云原生化需要解決的問題。
• 輕量化容器技術(shù)的誕生促使JVM服務(wù)內(nèi)容使用量變得過大
  • JVM對于內(nèi)存的使用量變的越來越大，會(huì)促使FullGC的過多甚至OOM。
• SpringBoot的微服務(wù)應(yīng)用啟動(dòng)的速度越來越慢（JVM啟動(dòng)速度）
  • 從JVM啟動(dòng)到真的應(yīng)用程序執(zhí)行需要經(jīng)歷VM加載，字節(jié)碼文件加載，以及JVM為了提升效率，借助JIT(just in time)及時(shí)編譯技術(shù)對解釋執(zhí)行的字節(jié)碼進(jìn)行局部優(yōu)化，通過編譯器生成本地執(zhí)行代碼的過程，同時(shí)還需要加上了JVM內(nèi)部垃圾回收所耗費(fèi)的時(shí)間。

典型的Java應(yīng)用加載時(shí)間一般都是秒級起步，如果遇到比較大的應(yīng)用初始花費(fèi)幾分鐘都是正常的。 以往由于我們很少重新啟動(dòng)Java應(yīng)用，Java應(yīng)用啟動(dòng)時(shí)間長的問題一般很少暴露出來。

• 但是在云原生應(yīng)用場景下，隨著粒度變的非常細(xì)，所以導(dǎo)致部署頻率過于頻繁
  • 我們會(huì)經(jīng)常不斷重啟應(yīng)用來實(shí)現(xiàn)滾動(dòng)升級或者無服務(wù)應(yīng)用場景。 Java應(yīng)用啟動(dòng)時(shí)間長的問題就變成了Java應(yīng)用云原生化亟待解決的問題。

Quarkus的介紹

• Quarkus定位為GraalVM和OpenJDK HotSpot量身定制的Kubernetes Native Java框架。
• Quarkus是紅帽開源的項(xiàng)目，借助開源社區(qū)的力量，通過對業(yè)界廣泛使用的框架進(jìn)行了適配，并結(jié)合云原生應(yīng)用的特點(diǎn)，提供了一套端到端的Java云原生應(yīng)用解決方案。
• 雖然開源時(shí)間較短，但是生態(tài)方面也已經(jīng)達(dá)到可用的狀態(tài)，自身包含擴(kuò)展框架，已經(jīng)支持像Netty、Undertow、Hibernate、JWT等框架，足以用于開發(fā)企業(yè)級應(yīng)用，用戶也可以基于擴(kuò)展框架自行擴(kuò)展。

向原生邁進(jìn)

對需要長時(shí)間運(yùn)行的應(yīng)用來說，由于經(jīng)過充分預(yù)熱，熱點(diǎn)代碼會(huì)被HotSpot的探測機(jī)制準(zhǔn)確定位捕獲，并將其編譯為物理硬件可直接執(zhí)行的機(jī)器碼，在這類應(yīng)用中Java的運(yùn)行效率很大程度上是取決于即時(shí)編譯器所輸出的代碼質(zhì)量。

HotSpot虛擬機(jī)中包含有兩個(gè)即時(shí)編譯器，分別是編譯時(shí)間較短但輸出代碼優(yōu)化程度較低的客戶端編譯器（簡稱為C1）以及編譯耗時(shí)長但輸出代碼優(yōu)化質(zhì)量也更高的服務(wù)端編譯器（簡稱為C2），通常它們會(huì)在分層編譯機(jī)制下與解釋器互相配合來共同構(gòu)成HotSpot虛擬機(jī)的執(zhí)行子系統(tǒng)的。

新一代即時(shí)編譯器（Graal VM）

自JDK 10起，HotSpot中又加入了一個(gè)全新的即時(shí)編譯器：Graal編譯器，看名字就可以聯(lián)想到它是來自于前一節(jié)提到的Graal VM，Graal編譯器是作為C2編譯器替代者的角色登場的。

C2編譯器的問題

C2的歷史已經(jīng)非常長了，可以追溯到Cliff Click大神讀博士期間的作品，這個(gè)由C++寫成的編譯器盡管目前依然效果拔群，但已經(jīng)復(fù)雜到連Cliff Click本人都不愿意繼續(xù)維護(hù)的程度。

Graal編譯器本身就是由Java語言寫成，實(shí)現(xiàn)時(shí)又刻意與C2采用了同一種名為"Sea-of-Nodes"的高級中間表示（High IR）形式，使其能夠更容易借鑒C2的優(yōu)點(diǎn)。

Graal編譯器比C2編譯器晚了足足二十年面世，有著極其充沛的后發(fā)優(yōu)勢，在保持能輸出相近質(zhì)量的編譯代碼的同時(shí)，開發(fā)效率和擴(kuò)展性上都要顯著優(yōu)于C2編譯器，這決定了C2編譯器中優(yōu)秀的代碼優(yōu)化技術(shù)可以輕易地移植到Graal編譯器上，但是反過來Graal編譯器中行之有效的優(yōu)化在C2編譯器里實(shí)現(xiàn)起來則異常艱難。

Graal編譯器

Graal的編譯效果短短幾年間迅速追平了C2，甚至某些測試項(xiàng)中開始逐漸反超C2編譯器。

Graal能夠做比C2更加復(fù)雜的優(yōu)化，如"部分逃逸分析"（Partial Escape Analysis），也擁有比C2更容易使用"激進(jìn)預(yù)測性優(yōu)化"（Aggressive Speculative Optimization）的策略，支持自定義的預(yù)測性假設(shè)等等。

Graal編譯器尚且年幼，還未經(jīng)過足夠多的實(shí)踐驗(yàn)證，所以仍然帶著"實(shí)驗(yàn)狀態(tài)"的標(biāo)簽，需要用開關(guān)參數(shù)去激活，這讓筆者不禁聯(lián)想起JDK 1.3時(shí)代，HotSpot虛擬機(jī)剛剛橫空出世時(shí)的場景，同樣也是需要用開關(guān)激活，也是作為Classic虛擬機(jī)的替代品的一段歷史。

Graal編譯器未來的前途可期，作為Java虛擬機(jī)執(zhí)行代碼的最新引擎，它的持續(xù)改進(jìn)，會(huì)同時(shí)為HotSpot與Graal VM注入更快更強(qiáng)的驅(qū)動(dòng)力。

GraalVM的總結(jié)分析

GraalVM：JVM為了提升效率，借助JIT及時(shí)編譯技術(shù)對解釋執(zhí)行的字節(jié)碼進(jìn)行局部優(yōu)化，通過編譯器生成本地執(zhí)行代碼提升應(yīng)用執(zhí)行效率。

GraalVM是Oracle實(shí)驗(yàn)室開發(fā)的新一代的面向多種語言的JVM即時(shí)編譯器，在性能以及多語言互操作性上有比較好的表現(xiàn)。與Java HotSpot VM相比，Graal借助內(nèi)聯(lián)，逃逸分析以及推出優(yōu)化技術(shù)可以提升2至5倍的性能提升。

GraalVM提供的靜態(tài)編譯功能，只能針對其編譯時(shí)能夠看得的封閉世界進(jìn)行優(yōu)化，對于那些使用了反射、動(dòng)態(tài)加載、以及動(dòng)態(tài)代理的代碼是無能為力的。

• 為了能讓我們?nèi)粘５腏ava應(yīng)用能夠正常運(yùn)行起來，需要我們對應(yīng)用所使用到的框架和類庫進(jìn)行相關(guān)修改適配。
• 由于Java代碼所使用的類庫很多，這部分的工作量還是相當(dāng)巨大的，雖然GraalVM已經(jīng)推出超過一年多的時(shí)間，但是還是很少見到大規(guī)模Java應(yīng)用轉(zhuǎn)移到這個(gè)平臺之上。

分享資源

獲取以上資源請?jiān)L問開源項(xiàng)目 點(diǎn)擊跳轉(zhuǎn)文章來源地址http://www.zghlxwxcb.cn/news/detail-646270.html

到了這里，關(guān)于【Quarkus技術(shù)系列】打造基于Quarkus的云原生微服務(wù)框架實(shí)踐（1）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！