Java微服務(wù)可以和Go一樣快嗎？

作者：聞數(shù)起舞 2020-11-12 08:30:38

業(yè)界普遍認(rèn)為Java是"老的"，"慢的"和"無聊的"。 Go是"快速"，"新"和"酷"。但是我們想知道這些特性是否得到實(shí)際性能數(shù)據(jù)的保證或支持。

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

[[351764]]

我們想要一個(gè)公平的測試，所以我們創(chuàng)建了一個(gè)非常簡單的微服務(wù)，沒有外部依賴項(xiàng)(例如數(shù)據(jù)庫)，并且代碼路徑非常短(僅處理字符串)。我們確實(shí)包含了指標(biāo)和日志記錄，因?yàn)樗鼈兯坪蹩偸前谌魏螌?shí)際的微服務(wù)中。我們使用了小型輕量級(jí)的框架(Helidon for Java和Go-Kit for Go)，并且還嘗試了Java的純JAX-RS。我們嘗試了不同版本的Java和不同的JVM。我們對(duì)堆大小和垃圾收集器進(jìn)行了一些基本調(diào)整。我們?cè)跍y試運(yùn)行之前對(duì)微服務(wù)進(jìn)行了預(yù)熱。

Java的歷史

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

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

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

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

Go的歷史

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

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

在我們演講時(shí)，StackOverflow有27,872個(gè)被" Go"標(biāo)記的問題，而Java則為1,702,730。

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

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

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

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

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

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

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

負(fù)載測試方法

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

在許多測試中，我們將JMeter與被測應(yīng)用程序在同一臺(tái)計(jì)算機(jī)上運(yùn)行。如果我們?cè)诹硪慌_(tái)機(jī)器上運(yùn)行JMeter，結(jié)果似乎沒有任何干擾或差異，因此可以簡化設(shè)置。當(dāng)我們以后將應(yīng)用程序部署到Kubernetes中時(shí)，JMeter在集群外部的遠(yuǎn)程計(jì)算機(jī)上運(yùn)行。

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

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

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

第一輪測試

在第一輪中，我們?cè)?quot;小型"計(jì)算機(jī)上進(jìn)行了測試，在這種情況下，該計(jì)算機(jī)是2.5GHz雙核Intel Core i7筆記本電腦，具有16GB RAM，運(yùn)行macOS。

結(jié)果如下：

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

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

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

GraalVM本機(jī)映像

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

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

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

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