Java微服務(wù)能像Go微服務(wù)一樣快嗎？

這是我最近一直在思索地一個(gè)問題。

去年8月份的the Oracle Groundbreakers Tour 2020 LATAM大會(huì)上，Mark Nelson和Peter Nagy就對(duì)此做過一系列基礎(chǔ)的的測(cè)試用以比較。接下來就給大家介紹下。

在程序員圈子里，普遍的看法是Java 老、慢、無聊 ，而Go是 快、新、酷

為了盡可能的進(jìn)行一個(gè)相對(duì)公平的測(cè)試，他們使用了一個(gè)非常簡(jiǎn)單的微服務(wù)，沒有外部依賴關(guān)系（比如數(shù)據(jù)庫），代碼路徑非常短（只是操縱字符串），使用了小型的、輕量級(jí)的框架（Helidon for Java和Go工具包for Go），試驗(yàn)了不同版本的Java和不同的jvm。

對(duì)決雙雄

我們先來看下擂臺(tái)兩邊的選手：

• 身穿深色戰(zhàn)服的選手是 JAVA

Java是由被甲骨文收購的Sun Microsystems開發(fā)的。它的1.0版本是1996年發(fā)布的，最新的版本是2020年的Java15。主要的設(shè)計(jì)目標(biāo)是Java虛擬機(jī)和字節(jié)碼的可移植性，以及帶有垃圾收集的內(nèi)存管理。它是全世界最流行的語言之一，在開源環(huán)境下開發(fā)。

我們先看下JAVA的問題，大家普遍認(rèn)為它最大的問題就是速度慢，已經(jīng)慢到讓人覺得不再是合理的，而是更具歷史意義的。不過這么多年來，Java誕生了很多不同的垃圾收集算法用來加快它運(yùn)行的速度。

Oracle實(shí)驗(yàn)室最近已經(jīng)開發(fā)了一個(gè)新的Java虛擬機(jī)GraalVM，它有一個(gè)新的編譯器和一些令人興奮的新特性，比如能夠?qū)ava字節(jié)碼轉(zhuǎn)換成一個(gè)本機(jī)映像，可以在沒有javavm的情況下運(yùn)行等。

• 而它的對(duì)手就是年輕充滿活力的 GO

GO是由谷歌的羅伯特·格里默、羅伯·派克和肯·湯姆森創(chuàng)建的。他們對(duì)UNIX、B、C、Plan9、UNIX窗口系統(tǒng)等做出了重大貢獻(xiàn)。GO是開源的，在2012年發(fā)布了1.0版本（比JAVA晚了16年），在2020年發(fā)布了1.15版本。無論是在采用方面，還是在語言和工具生態(tài)系統(tǒng)本身方面，它都在快速增長。

GO受C、Python、JavaScript和C++等多種語言的影響。被設(shè)計(jì)成高性能網(wǎng)絡(luò)和多處理的最佳語言。

StackOverflow有27872個(gè)帶“Go”的問題，而Java只有1702730個(gè)。足見長江后浪推前浪。

Go是一種靜態(tài)類型的編譯語言。它有稱為goroutines的輕量級(jí)進(jìn)程（這些不是OS線程），它們之間有獨(dú)特的通信通道（類型化的，F(xiàn)IFO）。Go是許多CNCF項(xiàng)目的首選語言，例如Kubernetes、Istio、Prometheus和Grafana。

賽前對(duì)比

從個(gè)人感覺來說，Go相比JAVA來說，優(yōu)點(diǎn)在于：

• Go更容易實(shí)現(xiàn)復(fù)合、純函數(shù)、不變狀態(tài)等功能模式。
• Go處于生命周期的早期，因此它沒有向后兼容性的沉重負(fù)擔(dān)—Go仍然可以輕易打破某些限制來改進(jìn)。
• Go編譯成一個(gè)本機(jī)靜態(tài)鏈接的二進(jìn)制文件-沒有虛擬機(jī)層-二進(jìn)制文件擁有運(yùn)行程序所需的一切，這對(duì)于“從頭開始”的容器來說非常好。
• Go體積小、啟動(dòng)快、執(zhí)行快（目前是的）。
• Go沒有OOP，繼承，泛型，斷言，指針?biāo)惴ā?/li>
• Go寫法上較少的括號(hào)。
• Go沒有循環(huán)依賴、沒有未使用的變量或?qū)搿]有隱式類型轉(zhuǎn)換的強(qiáng)制。
• Go樣板代碼少得多。

缺點(diǎn)是：

• Go工具生態(tài)系統(tǒng)還不成熟，尤其是依賴關(guān)系管理——有幾個(gè)選項(xiàng)，沒有一個(gè)是完美的，特別是對(duì)于非開源開發(fā)；仍然存在兼容性挑戰(zhàn)。
• 構(gòu)建具有新的/更新的依賴項(xiàng)的代碼非常慢（比如Maven著名的“下載Internet”問題）。
• 導(dǎo)入將代碼綁定到存儲(chǔ)庫，這使得在存儲(chǔ)庫中移動(dòng)代碼成為一場(chǎng)噩夢(mèng)。
• 調(diào)試、評(píng)測(cè)等仍然是一個(gè)挑戰(zhàn)。
• 用到了指針。
• 需要實(shí)現(xiàn)一些基本的算法。
• 沒有動(dòng)態(tài)鏈接。
• 沒有太多旋鈕來調(diào)優(yōu)執(zhí)行或垃圾收集、概要文件執(zhí)行或優(yōu)化算法。

比賽開始

使用JMeter來運(yùn)行負(fù)載測(cè)試。這些測(cè)試多次調(diào)用這些服務(wù)，并收集有關(guān)響應(yīng)時(shí)間、吞吐量（每秒事務(wù)數(shù)）和內(nèi)存使用情況的數(shù)據(jù)。對(duì)于Go，收集駐留集大??；對(duì)于Java，跟蹤本機(jī)內(nèi)存。

在測(cè)量之前，使用1000次服務(wù)調(diào)用對(duì)應(yīng)用程序進(jìn)行預(yù)熱。

應(yīng)用程序本身的源代碼以及負(fù)載測(cè)試的定義都在這個(gè)GitHub存儲(chǔ)庫中： https://github.com/markxnelson/go-java-go

第一回合

在第一輪測(cè)試中，在一臺(tái)“小型”機(jī)器上進(jìn)行了測(cè)試，是一臺(tái)2.5GHz雙核Intel core i7筆記本電腦，16GB內(nèi)存運(yùn)行macOS。測(cè)試運(yùn)行了100個(gè)線程，每個(gè)線程有10000個(gè)循環(huán)，上升時(shí)間為10秒。Java應(yīng)用程序運(yùn)行在JDK11和Helidon2.0.1上。使用Go 1.13.3編譯的Go應(yīng)用程序。

結(jié)果如下:

可以看出，第一回合是Go贏了！

JAVA占的內(nèi)存太多了；預(yù)熱對(duì)JVM有很大的影響—我們知道JVM在運(yùn)行時(shí)會(huì)進(jìn)行優(yōu)化，所以這是有意義的。

在第一回合的基礎(chǔ)上，意猶未盡的又引入GraalVM映像以使 Java 應(yīng)用程序的執(zhí)行環(huán)境更接近于 Go 應(yīng)用程序的環(huán)境，添加了 GraalVM 映像測(cè)試(用 GraalVM EE 20.1.1ー JDK 11構(gòu)建的本機(jī)映像)的結(jié)果是：

通過使用 GraalVM 映像在 JVM 上運(yùn)行應(yīng)用程序，我們沒有看到吞吐量或響應(yīng)時(shí)間方面的任何實(shí)質(zhì)性改進(jìn)，但是內(nèi)存占用的確變小了。

下面是一些測(cè)試的響應(yīng)時(shí)間圖:

第二回合

在第二輪測(cè)試中，使用一臺(tái)更大的機(jī)器上運(yùn)行測(cè)試。36核（每個(gè)核兩個(gè)線程）、256GB內(nèi)存、運(yùn)行oraclelinux7.8的機(jī)器。

和第一輪類似，使用了100個(gè)線程，每個(gè)線程使用了10,000個(gè)循環(huán)，10秒的加速時(shí)間，以及相同版本的 Go，Java，Helidon 和 GraalVM。

結(jié)果如下：

這一回合是GraalVM 映像贏了！

下面是一些測(cè)試的響應(yīng)時(shí)間圖：

在這個(gè)測(cè)試中，Java變體的表現(xiàn)要好得多，并且在沒有使用Java日志記錄的情況下，它的性能大大超過了Go。Java似乎更能使用硬件提供的多核和執(zhí)行線程（與Go相比）。

這一輪的最佳表現(xiàn)來自GraalVM native image，平均響應(yīng)時(shí)間為0.25毫秒，每秒事務(wù)數(shù)為82426個(gè)，而Go的最佳結(jié)果為1.59毫秒和39227個(gè)tps，然而這是以多占用兩個(gè)數(shù)量級(jí)的內(nèi)存為代價(jià)的！

GraalVM映像比在jvm上運(yùn)行的同一應(yīng)用程序快大約30–40%！

第三回合

這次，比賽在Kubernetes集群中運(yùn)行這些應(yīng)用程序，這是一個(gè)更自然的微服務(wù)運(yùn)行時(shí)環(huán)境。

這次使用了一個(gè)Kubernetes 1.16.8集群，它有三個(gè)工作節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)有兩個(gè)內(nèi)核（每個(gè)內(nèi)核有兩個(gè)執(zhí)行線程）、14GB的RAM和oraclelinux7.8。

應(yīng)用程序訪問是通過Traefik入口控制器進(jìn)行的，JMeter在Kubernetes集群外運(yùn)行，用于一些測(cè)試，而對(duì)于其他測(cè)試，使用ClusterIP并在集群中運(yùn)行JMeter。

與前面的測(cè)試一樣，我們使用了100個(gè)線程，每個(gè)線程使用了10,000個(gè)循環(huán)，以及10秒的加速時(shí)間。

下面是各種不同容器的大?。?/p>

• Go 11.6MB 11.6 MB
• Java/Helidon 1.41GB 1.41 GB
• Java/Helidon JLinked 150MB 150mb
• Native image 25.2MB 25.2 MB

結(jié)果如下：

下面是一些測(cè)試的響應(yīng)時(shí)間圖：

在這一輪中，我們觀察到 Go 有時(shí)更快，GraalVM 映像有時(shí)更快，但這兩者之間的差別很小(通常小于5%)。

Java似乎比Go更善于使用所有可用的內(nèi)核/線程—我們?cè)贘ava測(cè)試中看到了更好的CPU利用率。Java性能在擁有更多內(nèi)核和內(nèi)存的機(jī)器上更好，Go性能在較小/功能較弱的機(jī)器上更好。在一臺(tái)“生產(chǎn)規(guī)模”的機(jī)器上，Java很容易就和Go一樣快，或者更快。