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

 1. 背景介紹

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

我們希望建立一個公平的測試，因此創建了一項非常簡單的微服務，其中不含外部依賴項（例如數據庫），而且代碼路徑非常短（僅處理字符串）。我們在其中包含有指標及日志記錄，因為似乎一切微服務都或多或少包含這些內容。另外，我們使用了小型、輕量化的框架（Helidon for Java 以及 Go-Kit for Go），兩袖清風嘗試了 Java 的純 JAX-RS。我們也嘗試了不同版本的 Java 與不同 JVM。我們對堆大小及垃圾收集機制做出基本調整，并在測試運行前對微服務進行了預熱。

 2. Java 的發展歷史

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

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

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

甲骨文實驗室開發出一款名為 GraalVM 的 Java 虛擬機，其使用 Java 編寫而成，具有新的編譯器外加一系列令人興奮的新功能，包括可以將 Java 字節碼轉換為無需 Java 虛擬機即可運行的原生鏡像等。

 3. Go 的發展歷史

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

Go 語言受到 C、Python、JavaScript 以及 C++ 的影響，已經成為一種理想的高性能網絡與多處理語言。

截至我們發布主題演講時，StackOverflow 上共有 27872 個帶有“Go”標簽的問題，Java 則為 1702730 個。

Go 是一種靜態類型的編譯語言，其語法類似于 C，且擁有內存安全、垃圾回收、結構化類型以及 CSP 樣式并發（通信順序過程）等功能特性。Go 還使用名為 goroutine 的輕量級進程（并非操作系統線程），外加各進程間用于通信的通道（類型化，FIFO）。Go 語言不提供競態條件保護。

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

Go 語言在設計上強調快速構建與快速執行。到底是兩個空格還是四個空格？Go 語言表示不用麻煩，無所謂。

與 Java 相比，我將個人體會到的 Go 語言優勢整理如下：

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

但 Go 當然也不完美。與 Java 相比，我認為 Go 存在以下問題：

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

 4. 負載測試方法

我們使用 JMeter 進行負載測試。測試多次調用服務，并收集關于響應時間、吞吐量（每秒事務）以及內存使用情況的數據。在 Go 方面，我們主要收集常駐集大小，Java 方面則主要跟蹤原生內存。

在多項測試中，我們都將 JMeter 與被測應用程序放置在同一臺計算機上運行。經過對比，我們發現在其他機器上運行 JMeter 幾乎不會對結果造成任何影響。后續在將應用程序部署到 Kubernetes 中時，我們會考慮將 JMeter 運行在集群之外的遠程計算機之上。

在進行測試之前，我們使用 1000 項服務調用對應用程序進行了預熱。

應用程序本體的源代碼以及負載測試定義請參見 GitHub repo：

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

 5. 首輪測試 

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

測試結果如下：

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

以下為根據這些結果得出的觀察結論：

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

 6. GraalVM 原生鏡像

GraalVM 提供原生鏡像功能，使您能夠使用 Java 應用程序并在實質上將其編譯為原生可執行代碼。根據 GraalVM 項目網站的介紹：

該可執行文件包含應用程序類、依賴項中的類、運行時庫類以及 JDK 中的靜態鏈接原生代碼。其并非運行在 Java 虛擬機之上，而是包含必要組件，例如來自不同運行時系統（也被稱為「基層虛擬機」）的內存管理、線程調度等功能。基層虛擬機代表的是各運行時組件（例如反優化器、垃圾收集器、線程調度等）。

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

在這種情況下，與運行在 JVM 上的應用程序相比，我們發現使用 GraalVM 原生鏡像并不會在吞吐量或者響應時間等層面帶來任何實質性的改善，但內存占用量確實有所減少。

以下是測試期間的響應時間圖表：

首輪響應時間圖

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

 7. 第二輪測試

接下來，我們決定在更大的計算機上運行測試。在本輪中，我們使用臺具有 36 個核心（每核心雙線程）、256 GB 內存的計算機，并配合 Oracle Linux 7.8 操作系統。

與第一輪一樣，我們仍然使用 100 個線程、每線程 10000 個循環，10 秒啟動時間以及相同版本的 Go、Java、Helidon 以及 GraalVM。

下面來看結果：

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

下面來看本輪測試的響應時間圖：

啟用日志記錄，但未經預熱的測試運行響應時間。

不使用日志記錄也未經預熱的測試運行響應時間。

經過預熱，但未使用日志記錄的測試運行響應時間

第二輪的觀察結果：

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

 8. 第三輪測試：Kubernetes

在第三輪中，我們決定在 Kubernetes 集群上運行應用程序，借此模擬更為自然的微服務運行時環境。

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

應用程序訪問通過 Traefik 入口控制器實現，其中 JMeter 運行在 Kubernetes 集群之外。在某些測試中，我們也會嘗試使用 ClusterIP 并在集群內運行 JMeter。

與之前的測試一樣，我們使用 100 個線程、每線程 10000 個循環，外加 10 秒啟動時間。

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

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

以下為本輪測試結果：

響應時間圖表：

Kubernetes 測試中的響應時間

在本輪中，可以看到 Go 有時更快，而 GraalVM 原生鏡像也經常取得領先，但二者的差異很小（一般低于 5%）。

 9. 測試結論

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

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

 10. 未來展望

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