Java曾經著名的座右銘："一次編寫并在任何地方運行"如今已經過時了，我們想要運行代碼的唯一地方是在容器內。 "及時"編譯器沒有任何意義。

由于這個原因，Java生態系統可能正處于其轉型之中，以便更好地適應云。 Oracle的GraalVm允許將字節代碼編譯為Linux可執行文件(ELF)和Rad Heat的Quarkus以及其他框架，以使其像引導一個反應應用程序一樣容易。 Quarkus還以Netty和Vertx.x為核心來構建非常有效的響應式Web服務。 

> quarkus official performance stats

Java編譯為可執行的二進制文件，可在毫秒內啟動，并且占用的內存很小。 這可以利用Java生態系統，甚至可以用其他JVM語言(例如Scala和Kotlin)編寫!

聽起來好得令人難以置信……

如果您不相信，可以使用在線項目生成器或通過使用maven插件在本地生成項目來玩Quarkus。

另一方面，Golang誕生于云中，當在容器中運行時，沒有留下任何負擔。 它被認為是云的編程語言。 從第一天開始，小型二進制文件，快速啟動程序，較小的內存占用量就可以了。 并且被廣泛采用。 對Java世界的嚴峻挑戰。

Java有機會嗎? 只有時間證明一切。 但是，出于好奇，我想將Java云原生服務與golang同類服務在性能和開發經驗方面進行比較。

在這篇文章中，我將強調兩項服務。 比較他們的CPU，RAM，延遲和正常運行時間。 這些服務將在具有相同資源分配的容器中啟動，并且Apache基準測試將使他們汗流sweat背。

對于我的案例研究來說，這是一個"足夠好"的基準，因為我不認為找到最佳/最差的基準結果，而是比較在相同環境下執行的兩個基準。

場景

兩種服務都將連接到在另一個容器中運行的MySQL數據庫，該容器具有一個表和三行。 

> the database

每個服務將獲取所有三行，將其轉換為域對象，然后編寫JSON數組響應。

Apache基準測試將運行10K請求，并發級別為100，這是quarkus JVM版本的兩倍(還用于測試"冷" /"熱" JVM)) 

> the apache benchmark command

Golang服務

使用稱為gin的流行的反應式Web框架，該框架具有出色的基準。

在尋找golang非阻塞MySQL驅動程序時，我一無所獲，互聯網上建議同時使用go-sql-driver，這就是我要使用的。

golang樣式非常明確。 一個在你臉上的態度。 主要功能啟動服務器，配置請求處理程序，并打開數據庫連接。

構建本機go可執行文件 

> Easy and fast build process. The only tool I had to use was the go compiler. No hustle at all.

Kotlin Cloud本機服務— Quarkus

這是一個Kotlin示例，大致遵循quarkus反應式MySql擴展指南。 

> datasource configuration

與go版本相比，存在一些隱式東西，CDI依賴注入，使用javax注釋的聲明性路由，自動配置解析以及數據源/連接創建/服務器引導程序。 但這是使用框架的代價，它為您帶來繁重的工作，并決定了它的工作方式。 但是，它比go版本要短得多，只要我不介意黑魔法就行!

底層有一個Netty反應式Web服務器，由Vert.x多事件循環包裝，而Vert.x反應式MySQL驅動程序可以通過一個線程處理多個數據庫連接。

另外，我可以使用Kotlin令人驚嘆的收藏庫來折疊一個列表，其中go版本還沒有泛型(但即將推出)，也沒有豐富的標準收藏庫，我不得不手動編寫或生成它。

構建Java本機可執行文件 

> It took 4 minutes, partly because Gradle executes the native image compilation inside a Linux Graa

基本上，我能夠弄清楚構建本機可執行文件的容器中發生的事情是SubstrateVM。 設計為可提前編譯的可嵌入虛擬機鏈接到我們的代碼，并作為一個單元進行編譯。 甲骨文表示，這是驚人的，但并非沒有代價，SubstrateVM的優化次數少于HotSpot Vm，并且垃圾回收器更簡單。

執行此操作的編譯器稱為" Graal"，它與語言無關，在使用Java字節碼之前，需要先將其翻譯為中間表示形式，即Truffle語言。 這非常有趣，可以在這篇文章中找到有關Graal和Truffle的詳盡解釋。

構建Java本機圖像看起來更加復雜，速度較慢，并且生成的二進制文件幾乎是文件的兩倍。 但這有效! 與一個Java Uber(胖)Jar相比，35M可執行二進制文件實際上是什么，它可以輕松地大十倍。 35MB甚至可以放在aws lambda中。

強調服務

我正在使用以下設置在本地計算機上運行所有測試： 

不適使用：

• MacBook Pro(15英寸，2017年)
• 2.9 GHz Intel Core i7(8核)
• 16 GB 2133 MHz LPDDR3

不適使用名為cAdvisor的工具來監視我的容器的狀態。

場景

• quarkus jvm熱點容器
• quarkus java本機容器
• golang容器

每個都分配了以下資源

• 100MB / 0.5 CPU | 200MB / 1個CPU | 300MB / 2個CPU

我對……感興趣

• cpu / ram利用率(多核的利用率)
• cpu / ram峰值
• cpu / ram空閑
• 引導時間
• 響應潛伏時間平均值/最大值
• 吞吐量(每秒請求數)

現在，我將運行許多基準測試，并為每個基準收集許多數據點。 如果有太多信息，請隨時跳至摘要結尾

github repo以及該實驗的所有代碼都可以在這里找到

quarkus jvm熱點— 100MB / 0.5 CPU

• 閑置CPU使用率0.25%
• 空閑ram使用情況66MB
• 自舉時間6s 

> CPU usage during bootstrap. ( a spike , probably jit + launching JVM )

第一輪壓力測試(Cold JVM)

令人驚訝的是，沒有失敗的請求。 

> CPU usage during stress.

> RAM launched from 60 to almost 100 MB (limit) and stayed there.

第2輪壓力測試(溫暖的JVM)

quarkus jvm熱點— 200MB / 1個CPU

• 閑置CPU使用率0.13%
• 空閑ram使用情況66MB
• 引導時間3s 

> CPU usage during bootstrap. ( a spike again )

第一輪壓力測試(Cold JVM) 

> CPU / RAM usage under stress

> Surprisingly the JVM did not eat all the allocated 200MB and 140MB was sufficient

第2輪壓力測試(溫暖的JVM)

quarkus jvm熱點— 300MB / 2 CPU

• 空閑cpu / ram與以前的方案相同
• 引導時間1.1s(NICE) 

> CPU usage during bootstrap, a spike again.

第一輪壓力測試(Cold JVM) 

> Good CPU utilzation

> 142 mb ram was sufficient

第2輪壓力測試(溫暖的JVM)

現在，讓我們看看本地圖像將如何執行。

quarkus Java Native — 100MB / 0.5 CPU

• 引導時間：0.125s。 (!!!)
• 啟動時沒有CPU高峰 

> cpu / ram during bootstrap

壓力測試結果 

> CPU reached 0.5 limit as expected

> Good ram usage, 19MB active memory. WOW

quarkus Java Native — 200MB / 1個CPU

• 即時引導(0.0125s)
• 4空閑ram用法
• 在壓力下使用19種內存
• 100%的CPU使用率
• 啟動時沒有CPU高峰

檢測結果

quarkus Java Native — 300MB / 2 CPU

沒提升。

golang — 100MB / 0.5 CPU

• 空閑CPU 0
• 閑置內存2.3MB(不錯)
• 引導時間：幾分之一秒
• 啟動時沒有CPU高峰

結果有點歪斜。 由于某種原因，一小部分請求需要大約7秒鐘才能完成。

當再次嘗試運行測試以查看偏斜結果是否能夠再現測試時，實際上是否已將其壓碎!

運行時錯誤：無效的內存地址或nil指針取消引用。 嗯…可能是我做錯了什么? 似乎go-sql庫中存在錯誤。 如文檔所述，從表中讀取的代碼是100%，并且99%的時間都可以工作。 這不應該發生。

golang — 200MB / 1個CPU

我不斷收到運行時錯誤。 可疑總是在測試結束時。 但是，go-mysql驅動程序的校正不是主要問題，因此在完成90%的請求后手動終止測試。

• 壓力下的CPU / RAM使用率 

> cpu utilization during stress

> RAM usage during stress. 12.27MB, very nice.

golang — 300MB / 2個CPU

沒有明顯的改善，所有統計數據幾乎相同。 CPU利用率低于1.0。 我不知道為什么go不能充分利用更多的內核，有趣的是……可能是因為該過程受IO約束，或者可能是杜松子酒需要手動配置才能更好地利用多個內核。

摘要 

> aggregated stats ( warm jvm/native image | golang )

似乎Quarkus已準備好投入生產，它允許簡單的JVM /本機發行版/開發模式，并允許在本地運行本機測試。 而且，只要您不使用反射或JNI，就可以安全地配置GraalVM。 否則，您將必須自己配置graal編譯器，并且也有針對此的現有解決方案。

延遲和吞吐量

golang和云原生Java均產生了相似的結果，盡管平均而言稍微偏愛golang服務。 但是，java本機結果更加穩定。 Golang服務有時會在1.25µs內做出響應，而很少在7s內做出響應。

"預熱"后的JVM產生了良好的結果，但比本機或go版本差。

CPU利用率

當給定的內核少于單核時，go和native-java在負載下均表現不佳，而在使用2個內核啟動時，它們并沒有表現出明顯的改進。 可能是因為工作負載受IO限制。 或者因為gin / Netty的默認配置沒有考慮多個內核。

另一方面，JVM利用了賦予它的所有內核，并在各個方面提高了性能。

RAM使用

壓力很大，java本機為40MB，golang服務為24MB。 兩種情況都不錯，盡管golang版本使用的ram幾乎少了兩倍。

JVM在壓力下使用了140MB。 完全是官方的quarkus統計信息。 對于JVM來說一點都不差，但是幾乎是golang版本的6倍。

引導時間

golang和云原生Java均會立即啟動，而JVM版本則需要幾秒鐘(取決于分配的CPU)，并在啟動時產生CPU峰值。

開發經驗

這更是一個宗教問題，而不是一個實際問題。如此病態，請謹慎回答。 Quarkus創建Java世界中非常熟悉的抽象(例如基于注釋的DI)。它為您啟動服務并創建連接池。可以使用豐富的收藏標準庫和泛型。但是，這種感覺有點像黑魔法，一旦停止工作，您會感到無助。此外，將Java代碼編譯為本地二進制文件并不是那么簡單，您必須意識到其中的局限性和注意事項，盡管Red Hat在擴展方面取得了很大的進步，但并非每個Java庫都將與本地編譯兼容。 。 (預先配置為本地編譯的Java庫)。使用與本機編譯不兼容的庫(例如Guice)將需要您手動配置Graal VM。這是可能的，但并非像使用廣口瓶那樣直接。 Quarkus和Graal VM也"相對"新。因此，有許多冒險等待著。但由于是雙模式(JVM或本機)。萬一本機版本停止工作，總會有一個退路，這是解決任何新出現問題的好方法。

另一方面，Golang僅在現在(存在10年后)才承認需要泛型。 當然，它不喜歡隱性事件的繼續。 從很多方面來說，這都是好事。 另外，盡管go社區在追趕方面確實做得很好，但是可用的工具和庫卻更少(例如，只有一個流行的阻塞MySQL驅動程序)。 另一方面，它的編譯和構建過程非常快速/簡單。 每個golang軟件包都將為您工作，而不受Java本地平臺引入的限制。

結論

Java成為云原生，Golang并沒有像JVM那樣過度地執行它，這是非常好的。 我相信它將來會被廣泛使用。 但是golang絕對可以打架。

因此，請謹慎選擇!

而且不要忘了給仙人掌澆水