Peter Nagy 和我在 2020 年 8 月的甲骨文 Groundbreakers Tour 2020 LATAM 大會上發(fā)表一篇論文，題為《Go Java, Go！》。我們在本文中提出一個(gè)問題：“Java 微服務(wù)能像 Go 一樣快嗎？”為此，我們創(chuàng)建了一系列微服務(wù)并進(jìn)行了基準(zhǔn)測試，并在會議上展示了我們的成果。但其中還有不少可以探索的空間，因此我們決定將在本文中進(jìn)一步探討。

成都創(chuàng)新互聯(lián)專注于企業(yè)成都全網(wǎng)營銷、網(wǎng)站重做改版、陵城網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場景定制、電子商務(wù)商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為陵城等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

 1. 背景介紹

我們希望通過實(shí)驗(yàn)了解 Java 微服務(wù)在運(yùn)行速度上能否達(dá)到 Go 微服務(wù)的水平。目前，軟件行業(yè)普遍認(rèn)為 Java 已經(jīng)過于陳舊、緩慢且無聊。而 Go 則成了快速、嶄新以及酷炫的代名詞。真是這樣嗎？我們想從數(shù)據(jù)的角度看看這樣的印象是否站得住腳。

我們希望建立一個(gè)公平的測試，因此創(chuàng)建了一項(xiàng)非常簡單的微服務(wù)，其中不含外部依賴項(xiàng)（例如數(shù)據(jù)庫），而且代碼路徑非常短（僅處理字符串）。我們在其中包含有指標(biāo)及日志記錄，因?yàn)樗坪跻磺形⒎?wù)都或多或少包含這些內(nèi)容。另外，我們使用了小型、輕量化的框架（Helidon for Java 以及 Go-Kit for Go），兩袖清風(fēng)嘗試了 Java 的純 JAX-RS。我們也嘗試了不同版本的 Java 與不同 JVM。我們對堆大小及垃圾收集機(jī)制做出基本調(diào)整，并在測試運(yùn)行前對微服務(wù)進(jìn)行了預(yù)熱。

 2. Java 的發(fā)展歷史

Java 由 Sun Microsystems 公司開發(fā)，后被甲骨文所收購。其 1.0 版本發(fā)布于 1996 年，目前的最新版本是 2020 年的 Java 15。Java 當(dāng)前的主要設(shè)計(jì)目標(biāo)，在于實(shí)現(xiàn) Java 虛擬機(jī)及字節(jié)碼的可移植性，外加帶有垃圾回收的內(nèi)存管理機(jī)制。時(shí)至今日，Java 作為一種開源語言仍是全球最受歡迎的語言選項(xiàng)之一（根據(jù) StackOverflow 及 TIOBE 等來源）。

下面來聊聊“Java 問題”。人們對于它速度緩慢的印象其實(shí)更多是種固有觀念，而不再適應(yīng)當(dāng)下的事實(shí)。如今的 Java 甚至擁有不少性能敏感區(qū)，包括存儲對象數(shù)據(jù)堆、用于管理堆的垃圾收集器，外加準(zhǔn)時(shí)化（JIT）編譯器。

多年以來，Java 曾先后使用多種不同的垃圾收集算法，包括串行、并行、并發(fā)標(biāo)記 / 清除、G1 以及最新的 ZGC 垃圾收集器。現(xiàn)代垃圾收集器旨在盡可能減少垃圾收集造成的暫停時(shí)長。

甲骨文實(shí)驗(yàn)室開發(fā)出一款名為 GraalVM 的 Java 虛擬機(jī)，其使用 Java 編寫而成，具有新的編譯器外加一系列令人興奮的新功能，包括可以將 Java 字節(jié)碼轉(zhuǎn)換為無需 Java 虛擬機(jī)即可運(yùn)行的原生鏡像等。

 3. Go 的發(fā)展歷史

Go 語言由谷歌的 Robert Griesemer、Rob Pike 以及 Ken Thomson 開發(fā)而成。他們幾位也是 UNIX、B、C、Plan9 以及 UNIX 視窗系統(tǒng)等項(xiàng)目的主要貢獻(xiàn)者。作為一種開源語言，Go 的 1.0 版本發(fā)布于 2012 年，2020 年最新版本為 1.15。Go 語言的本體、采用速度以及工具生態(tài)系統(tǒng)的發(fā)展都相當(dāng)迅猛。

Go 語言受到 C、Python、JavaScript 以及 C++ 的影響，已經(jīng)成為一種理想的高性能網(wǎng)絡(luò)與多處理語言。

截至我們發(fā)布主題演講時(shí)，StackOverflow 上共有 27872 個(gè)帶有“Go”標(biāo)簽的問題，Java 則為 1702730 個(gè)。

Go 是一種靜態(tài)類型的編譯語言，其語法類似于 C，且擁有內(nèi)存安全、垃圾回收、結(jié)構(gòu)化類型以及 CSP 樣式并發(fā)（通信順序過程）等功能特性。Go 還使用名為 goroutine 的輕量級進(jìn)程（并非操作系統(tǒng)線程），外加各進(jìn)程間用于通信的通道（類型化，F(xiàn)IFO）。Go 語言不提供競態(tài)條件保護(hù)。

Go 是眾多 CNCF 項(xiàng)目的首選語言，例如 Kubernetes、Istio、Prometheus 以及 Grafana 等皆是由 Go 語言編寫而成（或者大部分是）。

Go 語言在設(shè)計(jì)上強(qiáng)調(diào)快速構(gòu)建與快速執(zhí)行。到底是兩個(gè)空格還是四個(gè)空格？Go 語言表示不用麻煩，無所謂。

與 Java 相比，我將個(gè)人體會到的 Go 語言優(yōu)勢整理如下：

• 更易于實(shí)現(xiàn)函數(shù)模式，例如復(fù)合、純函數(shù)、不可變狀態(tài)等。
• 樣板代碼少得多（但客觀上仍然太多）。
• Go 語言仍處于生命周期早期，因此沒什么向下兼容壓力——改進(jìn)道路較為平坦。
• Go 代碼可編譯為原生靜態(tài)鏈接的二進(jìn)制文件——無虛擬機(jī)層——二進(jìn)制文件中包含程序運(yùn)行所需要的一切，因此更適合“從零開始”的容器。
• 體積更小、啟動速度快、執(zhí)行速度快。
• 無 OOP、繼承、泛型、斷言、指針?biāo)阈g(shù)。
• 括號較少，例如可以實(shí)現(xiàn)為 if x > 3 { whatever }
• 強(qiáng)制執(zhí)行，沒有循環(huán)依賴性，不存在未使用的變量或?qū)?，沒有隱式類型轉(zhuǎn)換。

但 Go 當(dāng)然也不完美。與 Java 相比，我認(rèn)為 Go 存在以下問題：

• 工具生態(tài)系統(tǒng)還不成熟，特別是依賴項(xiàng)管理方面雖有多種選擇，但還都不完美。在非開源開發(fā)方面，Go 模塊在依賴項(xiàng)管理上優(yōu)勢明顯，但由于存在某些兼容性問題，其采用率仍不算特別高。
• 構(gòu)建具有新的 / 更新依賴項(xiàng)的代碼時(shí)非常緩慢（例如 Maven 著稱的「下載互聯(lián)網(wǎng)」問題）。
• 導(dǎo)入會將代碼綁定至 repo，導(dǎo)致代碼移動非常困難。
• IDE 非常適合編程、文檔查找與自動補(bǔ)全等功能，但卻難以進(jìn)行調(diào)試及概要分析等。
• 指針！我以為二十一世紀(jì)之前就可以告別這東西了，但 Go 里面還有！好在至少已經(jīng)沒有指針?biāo)惴恕?/li>
• 沒有 Java 那樣的 try/catch 異常（最終總是要用到 if err != nil），也沒有列表、映射函數(shù)等函數(shù)風(fēng)格的原語。
• 某些基本算法仍然缺失，所以用戶往往只能自行編寫。最近我就編寫了一些代碼，用 sloe 對兩個(gè)字符串（列表）進(jìn)行比較以及轉(zhuǎn)換。在函數(shù)語言中，我們完全可以使用 map 等內(nèi)置算法完成。
• 沒有動態(tài)鏈接！如果要在靜態(tài)鏈接代碼當(dāng)中使用 GPL 等許可，就會很不方便。
• 用于調(diào)整執(zhí)行、垃圾收集、概要分析或者優(yōu)化算法的選項(xiàng)很少。Java 擁有數(shù)百種垃圾收集調(diào)整選項(xiàng)，相比之下，Go 只有一項(xiàng)。

 4. 負(fù)載測試方法

我們使用 JMeter 進(jìn)行負(fù)載測試。測試多次調(diào)用服務(wù)，并收集關(guān)于響應(yīng)時(shí)間、吞吐量（每秒事務(wù)）以及內(nèi)存使用情況的數(shù)據(jù)。在 Go 方面，我們主要收集常駐集大小，Java 方面則主要跟蹤原生內(nèi)存。

在多項(xiàng)測試中，我們都將 JMeter 與被測應(yīng)用程序放置在同一臺計(jì)算機(jī)上運(yùn)行。經(jīng)過對比，我們發(fā)現(xiàn)在其他機(jī)器上運(yùn)行 JMeter 幾乎不會對結(jié)果造成任何影響。后續(xù)在將應(yīng)用程序部署到 Kubernetes 中時(shí)，我們會考慮將 JMeter 運(yùn)行在集群之外的遠(yuǎn)程計(jì)算機(jī)之上。

在進(jìn)行測試之前，我們使用 1000 項(xiàng)服務(wù)調(diào)用對應(yīng)用程序進(jìn)行了預(yù)熱。

應(yīng)用程序本體的源代碼以及負(fù)載測試定義請參見 GitHub repo：

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

 5. 首輪測試

 在第一輪測試中，我們在小型機(jī)器上運(yùn)行測試，搭載了 2.5 GHz 雙核英特爾酷睿 i7 的筆記本電腦，具有 16 GB 內(nèi)存并運(yùn)行 MacOS。我們運(yùn)行了 100 個(gè)線程，每個(gè)線程 10000 個(gè)循環(huán)，再額外加個(gè) 10 秒的啟動時(shí)間。Java 應(yīng)用程序運(yùn)行在 JDK 11 與 Helidon 2.0.1 之上。Go 應(yīng)用程序則使用 Go 1.13.3 進(jìn)行編譯。

測試結(jié)果如下：

應(yīng)用程序	日志記錄	預(yù)熱	平均響應(yīng)時(shí)間（毫秒）	事務(wù) /秒	內(nèi)存（RSS）（開始/結(jié)束）
Golang	是	否	5.79	15330.60	5160KB / 15188KB
Golang	否	否	4.18	20364.11	5164KB / 15144KB
Golang	否	是	3.97	21333.33	10120KB / 15216KB
Java (Helidon)	是	否	12.13	8168.15	296376KB / 427064KB; 提交 = 169629KB +15976KB (NMT); 保留 =1445329KB +5148KB (NMT)
Java (Helidon)	否	否	5.13	17332.82	282228KB / 430264KB; 保留 =1444264KB +6280KB; 提交 =166632KB +15884KB
Java (Helidon)	否	是	4.84	18273.18	401228KB / 444556KB

我們宣布，Go 成為首輪測試的獲勝者！

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

• 日志記錄似乎是影響性能的主要問題，特別是 java.util.logging。因此，我們在啟用與禁用日志記錄兩種條件下進(jìn)行了測試。我們還注意到，Go 應(yīng)用程序性能主要受到日志記錄的影響。
• 即使對于如此簡單的小型應(yīng)用程序，Java 版本的內(nèi)存占用量也明顯更大。
• 預(yù)熱對 JVM 產(chǎn)生了很大影響——我們知道 JVM 在運(yùn)行過程中會進(jìn)行優(yōu)化，因此預(yù)熱對 Java 應(yīng)用程序特別重要。
• 在此測試中，我們還比較了不同的執(zhí)行模型——Go 應(yīng)用程序被編譯為原生可執(zhí)行二進(jìn)制文件，而 Java 應(yīng)用程序被編譯為字節(jié)碼，而后虛擬機(jī)上運(yùn)行。我們還決定引入 GraalVM 原生鏡像，保證 Java 應(yīng)用程序的執(zhí)行環(huán)境更接近 Go 應(yīng)用程序。

 6. GraalVM 原生鏡像

GraalVM 提供原生鏡像功能，使您能夠使用 Java 應(yīng)用程序并在實(shí)質(zhì)上將其編譯為原生可執(zhí)行代碼。根據(jù) GraalVM 項(xiàng)目網(wǎng)站的介紹：

該可執(zhí)行文件包含應(yīng)用程序類、依賴項(xiàng)中的類、運(yùn)行時(shí)庫類以及 JDK 中的靜態(tài)鏈接原生代碼。其并非運(yùn)行在 Java 虛擬機(jī)之上，而是包含必要組件，例如來自不同運(yùn)行時(shí)系統(tǒng)（也被稱為「基層虛擬機(jī)」）的內(nèi)存管理、線程調(diào)度等功能?；鶎犹摂M機(jī)代表的是各運(yùn)行時(shí)組件（例如反優(yōu)化器、垃圾收集器、線程調(diào)度等）。

在添加 GraalVM 原生鏡像（原生鏡像由 GraalVM EE 20.1.1——JDK 11 構(gòu)建而成）之后，首輪測試結(jié)果如下：

應(yīng)用程序	日志記錄	預(yù)熱	平均響應(yīng)時(shí)間（毫秒）	事務(wù) /秒	內(nèi)存（RSS）（開始/結(jié)束）
Golang	是	否	5.79	15330.60	5160KB / 15188KB
Golang	否	否	4.18	20364.11	5164KB / 15144KB
Golang	否	是	3.97	21333.33	10120KB / 15216KB
Java (Helidon)	是	否	12.13	8168.15	296376KB / 427064KB; 提交 = 169629KB +15976KB (NMT); 保留 =1445329KB +5148KB (NMT)
Java (Helidon)	否	否	5.13	17332.82	282228KB / 430264KB; 保留 =1444264KB +6280KB; 提交 =166632KB +15884KB
Java (Helidon)	否	是	4.84	18273.18	401228KB / 444556KB
Native Image	是	否	12.01	7748.27	18256KB / 347204KB
Native Image	否	否	5.59	15753.24	169765KB / 347100KB
Native Image	否	是	5.22	17837.19	127436KB / 347132KB

在這種情況下，與運(yùn)行在 JVM 上的應(yīng)用程序相比，我們發(fā)現(xiàn)使用 GraalVM 原生鏡像并不會在吞吐量或者響應(yīng)時(shí)間等層面帶來任何實(shí)質(zhì)性的改善，但內(nèi)存占用量確實(shí)有所減少。

以下是測試期間的響應(yīng)時(shí)間圖表：

首輪響應(yīng)時(shí)間圖

請注意，在所有三種 Java 變體當(dāng)中，第一批請求的響應(yīng)時(shí)間要長得多（藍(lán)線相較于左軸的高度）而且在各項(xiàng)測試中，我們還看到一些峰值，其可能是由垃圾收集或優(yōu)化所引起。

 7. 第二輪測試

接下來，我們決定在更大的計(jì)算機(jī)上運(yùn)行測試。在本輪中，我們使用臺具有 36 個(gè)核心（每核心雙線程）、256 GB 內(nèi)存的計(jì)算機(jī)，并配合 Oracle Linux 7.8 操作系統(tǒng)。

與第一輪一樣，我們?nèi)匀皇褂?100 個(gè)線程、每線程 10000 個(gè)循環(huán)，10 秒啟動時(shí)間以及相同版本的 Go、Java、Helidon 以及 GraalVM。

下面來看結(jié)果：

應(yīng)用程序	日志記錄	預(yù)熱	平均響應(yīng)時(shí)間（毫秒）	事務(wù) /秒	內(nèi)存（RSS）（開始/結(jié)束）
原生鏡像	是	否	5.61	14273.48	28256KB / 1508600KB
原生鏡像	否	否	0.25	82047.92	29368KB / 1506428KB
原生鏡像	否	是	0.25	82426.64	1293216KB / 1502724KB
Golang	是	否	4.72	18540.49	132334KB / 72433KB
Golang	否	否	1.69	37949.22	12864KB / 70716KB
Golang	否	是	1.59	39227.99	16764KB / 76996KB
Java (Helidon)	是	否	7.38	11216.42	318545KB / 529848KB
Java (Helidon)	否	否	0.40	74827.90	307672KB / 489568KB
Java (Helidon)	否	是	0.38	76306.75	398156KB / 480460KB

我們宣布，GraalVM 原生鏡像成為第二輪測試的贏家！

下面來看本輪測試的響應(yīng)時(shí)間圖：

啟用日志記錄，但未經(jīng)預(yù)熱的測試運(yùn)行響應(yīng)時(shí)間。

不使用日志記錄也未經(jīng)預(yù)熱的測試運(yùn)行響應(yīng)時(shí)間。

經(jīng)過預(yù)熱，但未使用日志記錄的測試運(yùn)行響應(yīng)時(shí)間

第二輪的觀察結(jié)果：

• Java 變體在本輪測試中的性能表現(xiàn)大幅提升，而且在不使用日志記錄的情況下性能遠(yuǎn)優(yōu)于 Go。
• 與 Go 相比，Java 似乎更擅長使用硬件上的多個(gè)核心與執(zhí)行線程——這是因?yàn)?Go 本身主要作為系統(tǒng)及網(wǎng)絡(luò)編程語言存在，而且發(fā)展周期相對較短，因此在成熟度及優(yōu)化水平上不及 Java 也很正常。
• 有趣的是，Java 誕生之時(shí)多核心處理器并不常見，而 Go 誕生時(shí)多核處理器已經(jīng)成為行業(yè)標(biāo)準(zhǔn)。
• 具體來看，Java 似乎成功將日志記錄移交給其他線程 / 核心，因此極大減弱了其對性能的影響。
• 本輪最佳性能來自 GraalVM 原生鏡像，其平均響應(yīng)時(shí)間為 0.25 毫秒，每秒可執(zhí)行 82426 項(xiàng)事務(wù)；Go 的最佳結(jié)果為 1.59 毫秒外加每秒 39227 項(xiàng)事務(wù)，而其內(nèi)存占用量比前者高出兩個(gè)數(shù)量級！
• GraalVM 原生鏡像變體的速度要比運(yùn)行在 JVM 上的同一應(yīng)用程序快 30% 到 40%。
• Java 變體的響應(yīng)時(shí)間更為穩(wěn)定，但出現(xiàn)的峰值更多——我們猜測這是因?yàn)?Go 會把垃圾回收分成更多更小的批次來執(zhí)行。

 8. 第三輪測試：Kubernetes

在第三輪中，我們決定在 Kubernetes 集群上運(yùn)行應(yīng)用程序，借此模擬更為自然的微服務(wù)運(yùn)行時(shí)環(huán)境。

在本輪中，我們使用包含三個(gè)工作節(jié)點(diǎn)的 Kubernets 1.16.8 集群，每個(gè)工作節(jié)點(diǎn)中包含兩個(gè)核心（各對應(yīng)兩個(gè)線程）、14 GB 內(nèi)存以及 Oracle Linux 7.8。在某些測試中，我們在變體上運(yùn)行一個(gè) Pod；在其他一些測試中，我們則運(yùn)行一百個(gè) Pod。

應(yīng)用程序訪問通過 Traefik 入口控制器實(shí)現(xiàn)，其中 JMeter 運(yùn)行在 Kubernetes 集群之外。在某些測試中，我們也會嘗試使用 ClusterIP 并在集群內(nèi)運(yùn)行 JMeter。

與之前的測試一樣，我們使用 100 個(gè)線程、每線程 10000 個(gè)循環(huán)，外加 10 秒啟動時(shí)間。

以下是各個(gè)變體的容器大小：

• Go 11.6MB
• Java/Helidon 1.41GB
• Java/Helidon JLinked 150MB
• 原生鏡像 25.2MB

以下為本輪測試結(jié)果：

響應(yīng)時(shí)間圖表：

Kubernetes 測試中的響應(yīng)時(shí)間

在本輪中，可以看到 Go 有時(shí)更快，而 GraalVM 原生鏡像也經(jīng)常取得領(lǐng)先，但二者的差異很?。ㄒ话愕陀?5%）。

 9. 測試結(jié)論

縱觀幾輪測試與結(jié)果，我們得出了以下結(jié)論：

• Kubernetes 似乎沒有快速橫向擴(kuò)展。
• Java 似乎比 Go 更關(guān)于利用全部可用核心 / 線程，我們發(fā)現(xiàn) Java 測試期間 CPU 的利用率更高。
• 在核心及內(nèi)存容量更高的計(jì)算機(jī)上，Java 性能更好；在較小 / 性能較弱的計(jì)算機(jī)上，Go 性能更好。
• Go 的性能總體上更加一致，這可能是由于 Java 中的垃圾回收機(jī)制所致。
• 在“生產(chǎn)規(guī)?！庇?jì)算機(jī)上，Java 的運(yùn)行速度與 Go 基本相當(dāng)、甚至更快一點(diǎn)。
• 日志記錄似乎成為 Go 及 Java 中的主要性能瓶頸。
• Java 的現(xiàn)代版本以及 Helidon 等新型框架在消除 / 減輕 Java 長期存在的某些重大問題（例如冗長、GC 性能、啟動時(shí)間等）擁有良好的表現(xiàn)。

 10. 未來展望

• 經(jīng)過這輪有趣的測試，我們打算繼續(xù)探索，特別是：
• 我們打算通過 Kubernetes 自動擴(kuò)展做更多工作，包括引入更復(fù)雜的微服務(wù)或更高的負(fù)載以凸顯出性能上的差異。
• 我們希望研究更復(fù)雜的微服務(wù)、多種服務(wù)類型以及模式，觀察網(wǎng)絡(luò)如何影響性能，以及應(yīng)如何對微服務(wù)網(wǎng)絡(luò)進(jìn)行調(diào)優(yōu)。
• 我們還打算深挖日志記錄問題，了解解決此瓶頸的方法。
• 我們希望查看目標(biāo)代碼并比較當(dāng)前正在執(zhí)行的實(shí)際指令，看看能否在代碼路徑中做出進(jìn)一步優(yōu)化。
• 我們希望了解 JMeter 能否在不成為瓶頸的同時(shí)產(chǎn)生足夠多的負(fù)載，但此次測試結(jié)果表明 JMeter 并不構(gòu)成影響，而是能夠輕松跟上 Go 與 Java 實(shí)現(xiàn)的運(yùn)行步伐。
• 我們打算對容器啟動時(shí)間、內(nèi)存占用量等指標(biāo)做出更詳細(xì)的測量。

網(wǎng)站題目：基準(zhǔn)測試：Java微服務(wù)能像Go一樣快嗎？
URL網(wǎng)址：http://uogjgqi.cn/article/cdedoss.html