我們想進行實驗，看看Java微服務(wù)是否可以像Go微服務(wù)一樣快速運行。 業(yè)界普遍認為Java是"老的"，"慢的"和"無聊的"。 Go是"快速"，"新"和"酷"。 但是我們想知道這些特性是否得到實際性能數(shù)據(jù)的保證或支持。

[[351764]]

我們想要一個公平的測試，所以我們創(chuàng)建了一個非常簡單的微服務(wù)，沒有外部依賴項(例如數(shù)據(jù)庫)，并且代碼路徑非常短(僅處理字符串)。 我們確實包含了指標和日志記錄，因為它們似乎總是包含在任何實際的微服務(wù)中。 我們使用了小型輕量級的框架(Helidon for Java和Go-Kit for Go)，并且還嘗試了Java的純JAX-RS。 我們嘗試了不同版本的Java和不同的JVM。 我們對堆大小和垃圾收集器進行了一些基本調(diào)整。 我們在測試運行之前對微服務(wù)進行了預(yù)熱。

Java的歷史

Java由Sun Microsystems開發(fā)，后來被Oracle收購。 其1.0版本于1996年發(fā)布，最新版本是2020年的Java15。主要設(shè)計目標是Java虛擬機和字節(jié)碼的可移植性以及帶有垃圾回收的內(nèi)存管理。 它仍然是最流行的語言之一(根據(jù)StackOverflow和TIOBE之類的來源)，它是在開源中開發(fā)的。

讓我們談?wù)?quot; Java問題"。

多年來，Java有許多不同的垃圾收集算法，包括串行，并行，并發(fā)標記/清除，G1和新的ZGC垃圾收集器。 現(xiàn)代垃圾收集器旨在最大程度地減少垃圾收集"停止世界"暫停的時間。

Oracle實驗室開發(fā)了一種新的名為GraalVM的Java虛擬機，該Java虛擬機用Java編寫，具有新的編譯器和一些令人興奮的新功能，例如能夠?qū)ava字節(jié)碼轉(zhuǎn)換為無需Java VM即可運行的本機映像。

Go的歷史

Go由Google的Robert Griesemer，Rob Pike和Ken Thomson創(chuàng)建。

Go受C，Python，Javascript和C的影響。 它被設(shè)計為用于高性能網(wǎng)絡(luò)和多處理的最佳語言。

在我們演講時，StackOverflow有27,872個被" Go"標記的問題，而Java則為1,702,730。

Go是一種靜態(tài)類型的編譯語言。

Go是許多CNCF項目的首選語言，例如Kubernetes，Istio，Prometheus和Grafana都(大部分)用Go編寫。

它旨在具有快速的構(gòu)建時間和快速的執(zhí)行。

Go(與Java相比)有什么好處-根據(jù)我的經(jīng)驗，這是我的個人看法：

• 容易實現(xiàn)功能模式，例如合成，純函數(shù)，不可變狀態(tài)。
• 樣板代碼少得多(但仍然太多)。
• 它仍然處于生命周期的早期，因此它不具有向后兼容的沉重負擔-他們?nèi)匀豢梢源蚱片F(xiàn)狀來改進它。
• 它可以編譯成本地靜態(tài)鏈接的二進制文件-無虛擬機層-二進制文件具有運行程序所需的一切，這對于" FROM scratch"容器非常有用。
• 它具有體積小，啟動快和執(zhí)行快的特點。
• 沒有OOP，繼承，泛型，斷言，指針算術(shù)。
• 括號較少，例如
• 沒有循環(huán)依賴性，沒有未使用的變量或?qū)耄瑳]有隱式類型轉(zhuǎn)換的強制。

那么，Go的"問題"是什么?

• 工具生態(tài)系統(tǒng)還不成熟，尤其是依賴管理-有多種選擇，沒有一個是完美的，特別是對于非開源開發(fā)而言;
• 建立具有新/更新依賴關(guān)系的代碼非常慢(例如Maven著名的"下載Internet"問題。
• 導入會將代碼綁定到存儲庫，這使代碼在噩夢中移動。
• IDE非常適合編程，文檔查找，自動完成等。
• 指針!
• 沒有Java風格的try / catch異常(如果err!= nil的使用頻率太高，您最終會寫出來)，沒有功能風格的原語，例如列表，映射函數(shù)等。
• 由于它尚不可用，您通常會最終實現(xiàn)一些基本算法。 最近，我寫了一些代碼，由sloe進行了兩個字符串(列表)的比較，并進行了轉(zhuǎn)換。 用一種功能語言，我本可以使用諸如map這樣的內(nèi)置函數(shù)來做到這一點。
• 沒有動態(tài)鏈接! (您問"誰在乎?"。)如果您要使用帶有"感染"靜態(tài)鏈接代碼的GPL許可證的代碼，這可能是一個真正的問題。
• 調(diào)節(jié)執(zhí)行或垃圾收集，配置文件執(zhí)行或優(yōu)化算法的旋鈕并不多-Java具有數(shù)百種垃圾收集調(diào)整選項，而Go具有一個-啟用或禁用。

負載測試方法

我們使用JMeter進行負載測試。 測試多次調(diào)用服務(wù)，并收集有關(guān)響應(yīng)時間，吞吐量(每秒事務(wù))和內(nèi)存使用情況的數(shù)據(jù)。 對于Go，我們收集常駐集大小;對于Java，我們跟蹤本機內(nèi)存。

在許多測試中，我們將JMeter與被測應(yīng)用程序在同一臺計算機上運行。 如果我們在另一臺機器上運行JMeter，結(jié)果似乎沒有任何干擾或差異，因此可以簡化設(shè)置。 當我們以后將應(yīng)用程序部署到Kubernetes中時，JMeter在集群外部的遠程計算機上運行。

在進行測量之前，我們使用了1,000次服務(wù)調(diào)用來預(yù)熱了應(yīng)用程序。

應(yīng)用程序本身的源代碼以及負載測試的定義都在以下GitHub存儲庫中：

https://github.com/markxnelson/go-java-go

第一輪測試

在第一輪中，我們在"小型"計算機上進行了測試，在這種情況下，該計算機是2.5GHz雙核Intel Core i7筆記本電腦，具有16GB RAM，運行macOS。

結(jié)果如下：

我們宣布Go成為第一輪的獲勝者!

以下是我們根據(jù)這些結(jié)果得出的觀察結(jié)果：

• 日志記錄似乎是主要的性能問題，尤其是java.util.logging。 因此，我們在進行日志記錄和不進行日志記錄的情況下都進行了測試。 我們還注意到，日志記錄是Go應(yīng)用程序性能好的重要因素。
• Java版本具有顯著的更大的內(nèi)存占用空間，即使對于如此小的簡單應(yīng)用程序也是如此
• 預(yù)熱對JVM產(chǎn)生了很大的影響-我們知道JVM在運行時會進行優(yōu)化，因此這很有意義
• 在此測試中，我們正在比較不同的執(zhí)行模型-Go應(yīng)用程序被編譯為本地可執(zhí)行二進制文件，而Java應(yīng)用程序被編譯為字節(jié)代碼，然后在虛擬機上運行。

GraalVM本機映像

GraalVM具有本機映像功能，可讓您采用Java應(yīng)用程序并將其本質(zhì)上編譯為本機可執(zhí)行代碼。

該可執(zhí)行文件包括應(yīng)用程序類，其依賴項中的類，運行時庫類以及JDK中的靜態(tài)鏈接本機代碼。

這是再次添加GraalVM本機圖像測試(使用GraalVM EE 20.1.1-JDK 11構(gòu)建的本地圖像)的第一輪結(jié)果：

在這種情況下，與在JVM上運行應(yīng)用程序相比，使用GraalVM本機映像沒有看到吞吐量或響應(yīng)時間的任何顯著改善，但是內(nèi)存占用空間較小。

以下是一些測試的響應(yīng)時間的圖表：

> Response time graphs for round one

請注意，在所有這三種Java變體中，第一個請求的響應(yīng)時間要長得多(請在與左軸相對的右上方尋找那條藍線)。

第二輪

接下來，我們決定在更大的計算機上運行測試。

與第一輪一樣，我們使用了100個線程，每個線程10,000個循環(huán)，10秒的啟動時間以及相同版本的Go，Java，Helidon和GraalVM。

結(jié)果如下：

我們宣布GraalVM本機映像是第二輪的贏家!

以下是這些測試的響應(yīng)時間圖：

> Response times for test runs with logging enabled but no warmup

> Response times for test runs with no logging and no warmup

> Response times for test runs with warmup but no logging

第二輪的一些觀察：

• 在此測試中，Java變體的性能要好得多，并且在不使用日志記錄的情況下，其性能要比Go好很多
• Java似乎更有能力使用硬件提供的多個內(nèi)核和執(zhí)行線程(與Go相比)–這是有一定道理的，因為Go旨在作為一種系統(tǒng)和網(wǎng)絡(luò)編程語言，并且它是一種較年輕的語言，因此
• 有趣的是，Java是在多核處理器不常見的時候設(shè)計的，而Go是在多核處理器不是通用的時候設(shè)計的。
• 特別是，似乎Java日志記錄已成功卸載到其他線程/內(nèi)核，并且對性能的影響要小得多。
• 這一輪的最佳性能來自GraalVM本機映像，平均響應(yīng)時間為0.25毫秒，每秒處理82,426個事務(wù)，而Go的最佳結(jié)果為1.59毫秒和39,227 tps，但這是以增加兩個數(shù)量級的內(nèi)存為代價的用法!
• Java變體的響應(yīng)時間似乎更加一致，但是出現(xiàn)了更多的峰值-我們認為這意味著Go在做更多，更小的垃圾回收

第三輪-Kubernetes

在第三輪中，我們決定在Kubernetes集群中運行應(yīng)用程序—您可能會說，這是微服務(wù)的更自然的運行時環(huán)境。

在這一輪中，我們使用了具有三個工作節(jié)點的Kubernetes 1.16.8集群，每個工作節(jié)點都有兩個內(nèi)核(每個都有兩個執(zhí)行線程)，14GB的RAM和Oracle Linux 7.8。 在某些測試中，我們?yōu)槊總€變體運行了一個Pod，在其他測試中運行了100個Pod。

應(yīng)用程序訪問是通過Traefik入口控制器進行的，其中JMeter在Kubernetes集群外部運行，以進行某些測試，對于其他測試，我們使用ClusterIP并在集群中運行JMeter。

與之前的測試一樣，我們使用了100個線程，每個線程10,000個循環(huán)，以及10秒的啟動時間。

以下是每個變體的容器大小：

• 繼續(xù)11.6MB
• Java / Helidon 1.41GB
• Java / Helidon JLinked 150MB
• 本機圖像25.2MB

結(jié)果如下：

以下是一些響應(yīng)時間表：

> Response times from Kubernetes tests

在這一輪中，我們觀察到Go有時會更快，而GraalVM本地映像有時會更快，但是兩者之間的差異很小(通常小于5%)

那我們學到了什么?

我們對所有這些測試和結(jié)果進行了反思，以下是一些結(jié)論：

• Kubernetes似乎沒有迅速擴展
• Java似乎比Go更擅長使用所有可用的內(nèi)核/線程-我們發(fā)現(xiàn)Java測試期間CPU利用率更高
• 在具有更多內(nèi)核和內(nèi)存的機器上，Java性能更好;在較小/功能較弱的機器上，Go性能更好。
• Go的性能總體上更加一致-可能是由于Java的垃圾回收
• 在"生產(chǎn)規(guī)模"的計算機上，Java的運行速度與Go一樣快，甚至更快
• 日志記錄似乎是我們在Go和Java中遇到的主要瓶頸
• Java的現(xiàn)代版本以及諸如Helidon之類的新框架在消除/減少Java的一些眾所周知且長期存在的問題(例如冗長程度，GC性能，啟動時間等)的痛苦方面取得了長足的進步。

接下來是什么?

這是一個非常有趣的練習，我們打算繼續(xù)努力，特別是：

• 我們想通過Kubernetes自動擴展做更多的工作-我們可能需要更復雜的微服務(wù)或更高的負載才能看到性能上的差異
• 我們希望研究更復雜的微服務(wù)，多種服務(wù)以及電路中斷等模式，并觀察網(wǎng)絡(luò)如何影響性能以及如何調(diào)整微服務(wù)網(wǎng)絡(luò)
• 還想看一下日志記錄問題，看看該怎么做才能消除瓶頸
• 我們想看一下目標代碼并比較正在執(zhí)行的實際指令，看看是否可以在代碼路徑中做一些進一步的優(yōu)化。
• 我們想知道JMeter是否可以在不成為瓶頸的情況下產(chǎn)生足夠的負載，但是我們的測試表明這根本不是一個因素，它可以輕松跟上Go和Java實現(xiàn)。
• 想要對容器啟動時間，內(nèi)存占用量等進行更詳細的測量。