當(dāng)前位置:聯(lián)升科技 > 技術(shù)資訊 >

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

2020-11-17    作者:Mark Nelson    來源:架構(gòu)頭條    閱讀:
Peter Nagy 和我在 2020 年 8 月的甲骨文 Groundbreakers Tour 2020 LATAM 大會上發(fā)表一篇論文,題為《Go Java, Go!》。我們在本文中提出一個問題:“Java 微服務(wù)能像 Go 一樣快嗎?”為此,我們創(chuàng)建了一系列微服務(wù)并進(jìn)行了基準(zhǔn)測試,并在會議上展示了我們的成果。但其中還有不少可以探索的空間,因此我們決定將在本文中進(jìn)一步探討。
 1. 背景介紹
我們希望通過實驗了解 Java 微服務(wù)在運行速度上能否達(dá)到 Go 微服務(wù)的水平。目前,軟件行業(yè)普遍認(rèn)為 Java 已經(jīng)過于陳舊、緩慢且無聊。而 Go 則成了快速、嶄新以及酷炫的代名詞。真是這樣嗎?我們想從數(shù)據(jù)的角度看看這樣的印象是否站得住腳。
我們希望建立一個公平的測試,因此創(chuàng)建了一項非常簡單的微服務(wù),其中不含外部依賴項(例如數(shù)據(jù)庫),而且代碼路徑非常短(僅處理字符串)。我們在其中包含有指標(biāo)及日志記錄,因為似乎一切微服務(wù)都或多或少包含這些內(nèi)容。另外,我們使用了小型、輕量化的框架(Helidon for Java 以及 Go-Kit for Go),兩袖清風(fēng)嘗試了 Java 的純 JAX-RS。我們也嘗試了不同版本的 Java 與不同 JVM。我們對堆大小及垃圾收集機制做出基本調(diào)整,并在測試運行前對微服務(wù)進(jìn)行了預(yù)熱。
 2. Java 的發(fā)展歷史
Java 由 Sun Microsystems 公司開發(fā),后被甲骨文所收購。其 1.0 版本發(fā)布于 1996 年,目前的最新版本是 2020 年的 Java 15。Java 當(dāng)前的主要設(shè)計目標(biāo),在于實現(xiàn) Java 虛擬機及字節(jié)碼的可移植性,外加帶有垃圾回收的內(nèi)存管理機制。時至今日,Java 作為一種開源語言仍是全球最受歡迎的語言選項之一(根據(jù) StackOverflow 及 TIOBE 等來源)。
下面來聊聊“Java 問題”。人們對于它速度緩慢的印象其實更多是種固有觀念,而不再適應(yīng)當(dāng)下的事實。如今的 Java 甚至擁有不少性能敏感區(qū),包括存儲對象數(shù)據(jù)堆、用于管理堆的垃圾收集器,外加準(zhǔn)時化(JIT)編譯器。
多年以來,Java 曾先后使用多種不同的垃圾收集算法,包括串行、并行、并發(fā)標(biāo)記 / 清除、G1 以及最新的 ZGC 垃圾收集器?,F(xiàn)代垃圾收集器旨在盡可能減少垃圾收集造成的暫停時長。
甲骨文實驗室開發(fā)出一款名為 GraalVM 的 Java 虛擬機,其使用 Java 編寫而成,具有新的編譯器外加一系列令人興奮的新功能,包括可以將 Java 字節(jié)碼轉(zhuǎn)換為無需 Java 虛擬機即可運行的原生鏡像等。
 3. Go 的發(fā)展歷史
Go 語言由谷歌的 Robert Griesemer、Rob Pike 以及 Ken Thomson 開發(fā)而成。他們幾位也是 UNIX、B、C、Plan9 以及 UNIX 視窗系統(tǒ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ā)布主題演講時,StackOverflow 上共有 27872 個帶有“Go”標(biāo)簽的問題,Java 則為 1702730 個。
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 項目的首選語言,例如 Kubernetes、Istio、Prometheus 以及 Grafana 等皆是由 Go 語言編寫而成(或者大部分是)。
Go 語言在設(shè)計上強調(diào)快速構(gòu)建與快速執(zhí)行。到底是兩個空格還是四個空格?Go 語言表示不用麻煩,無所謂。
與 Java 相比,我將個人體會到的 Go 語言優(yōu)勢整理如下:
更易于實現(xiàn)函數(shù)模式,例如復(fù)合、純函數(shù)、不可變狀態(tài)等。
樣板代碼少得多(但客觀上仍然太多)。
Go 語言仍處于生命周期早期,因此沒什么向下兼容壓力——改進(jìn)道路較為平坦。
Go 代碼可編譯為原生靜態(tài)鏈接的二進(jìn)制文件——無虛擬機層——二進(jìn)制文件中包含程序運行所需要的一切,因此更適合“從零開始”的容器。
體積更小、啟動速度快、執(zhí)行速度快。
無 OOP、繼承、泛型、斷言、指針?biāo)阈g(shù)。
括號較少,例如可以實現(xiàn)為 if x > 3 { whatever }
強制執(zhí)行,沒有循環(huán)依賴性,不存在未使用的變量或?qū)?,沒有隱式類型轉(zhuǎn)換。
但 Go 當(dāng)然也不完美。與 Java 相比,我認(rèn)為 Go 存在以下問題:
工具生態(tài)系統(tǒng)還不成熟,特別是依賴項管理方面雖有多種選擇,但還都不完美。在非開源開發(fā)方面,Go 模塊在依賴項管理上優(yōu)勢明顯,但由于存在某些兼容性問題,其采用率仍不算特別高。
構(gòu)建具有新的 / 更新依賴項的代碼時非常緩慢(例如 Maven 著稱的「下載互聯(lián)網(wǎng)」問題)。
導(dǎo)入會將代碼綁定至 repo,導(dǎo)致代碼移動非常困難。
IDE 非常適合編程、文檔查找與自動補全等功能,但卻難以進(jìn)行調(diào)試及概要分析等。
指針!我以為二十一世紀(jì)之前就可以告別這東西了,但 Go 里面還有!好在至少已經(jīng)沒有指針?biāo)惴恕?/div>
沒有 Java 那樣的 try/catch 異常(最終總是要用到 if err != nil),也沒有列表、映射函數(shù)等函數(shù)風(fēng)格的原語。
某些基本算法仍然缺失,所以用戶往往只能自行編寫。最近我就編寫了一些代碼,用 sloe 對兩個字符串(列表)進(jìn)行比較以及轉(zhuǎn)換。在函數(shù)語言中,我們完全可以使用 map 等內(nèi)置算法完成。
沒有動態(tài)鏈接!如果要在靜態(tài)鏈接代碼當(dāng)中使用 GPL 等許可,就會很不方便。
用于調(diào)整執(zhí)行、垃圾收集、概要分析或者優(yōu)化算法的選項很少。Java 擁有數(shù)百種垃圾收集調(diào)整選項,相比之下,Go 只有一項。
 4. 負(fù)載測試方法
我們使用 JMeter 進(jìn)行負(fù)載測試。測試多次調(diào)用服務(wù),并收集關(guān)于響應(yīng)時間、吞吐量(每秒事務(wù))以及內(nèi)存使用情況的數(shù)據(jù)。在 Go 方面,我們主要收集常駐集大小,Java 方面則主要跟蹤原生內(nèi)存。
在多項測試中,我們都將 JMeter 與被測應(yīng)用程序放置在同一臺計算機上運行。經(jīng)過對比,我們發(fā)現(xiàn)在其他機器上運行 JMeter 幾乎不會對結(jié)果造成任何影響。后續(xù)在將應(yīng)用程序部署到 Kubernetes 中時,我們會考慮將 JMeter 運行在集群之外的遠(yuǎn)程計算機之上。
在進(jìn)行測試之前,我們使用 1000 項服務(wù)調(diào)用對應(yīng)用程序進(jìn)行了預(yù)熱。
應(yīng)用程序本體的源代碼以及負(fù)載測試定義請參見 GitHub repo:
https://github.com/markxnelson/go-java-go
 5. 首輪測試
在第一輪測試中,我們在小型機器上運行測試,搭載了 2.5 GHz 雙核英特爾酷睿 i7 的筆記本電腦,具有 16 GB 內(nèi)存并運行 MacOS。我們運行了 100 個線程,每個線程 10000 個循環(huán),再額外加個 10 秒的啟動時間。Java 應(yīng)用程序運行在 JDK 11 與 Helidon 2.0.1 之上。Go 應(yīng)用程序則使用 Go 1.13.3 進(jìn)行編譯。
測試結(jié)果如下:
應(yīng)用程序 日志記錄 預(yù)熱 平均響應(yīng)時間(毫秒) 事務(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 在運行過程中會進(jìn)行優(yōu)化,因此預(yù)熱對 Java 應(yīng)用程序特別重要。
在此測試中,我們還比較了不同的執(zhí)行模型——Go 應(yīng)用程序被編譯為原生可執(zhí)行二進(jìn)制文件,而 Java 應(yīng)用程序被編譯為字節(jié)碼,而后虛擬機上運行。我們還決定引入 GraalVM 原生鏡像,保證 Java 應(yīng)用程序的執(zhí)行環(huán)境更接近 Go 應(yīng)用程序。
 6. GraalVM 原生鏡像
GraalVM 提供原生鏡像功能,使您能夠使用 Java 應(yīng)用程序并在實質(zhì)上將其編譯為原生可執(zhí)行代碼。根據(jù) GraalVM 項目網(wǎng)站的介紹:
該可執(zhí)行文件包含應(yīng)用程序類、依賴項中的類、運行時庫類以及 JDK 中的靜態(tài)鏈接原生代碼。其并非運行在 Java 虛擬機之上,而是包含必要組件,例如來自不同運行時系統(tǒng)(也被稱為「基層虛擬機」)的內(nèi)存管理、線程調(diào)度等功能?;鶎犹摂M機代表的是各運行時組件(例如反優(yōu)化器、垃圾收集器、線程調(diào)度等)。
在添加 GraalVM 原生鏡像(原生鏡像由 GraalVM EE 20.1.1——JDK 11 構(gòu)建而成)之后,首輪測試結(jié)果如下:
應(yīng)用程序 日志記錄 預(yù)熱 平均響應(yīng)時間(毫秒) 事務(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
在這種情況下,與運行在 JVM 上的應(yīng)用程序相比,我們發(fā)現(xiàn)使用 GraalVM 原生鏡像并不會在吞吐量或者響應(yīng)時間等層面帶來任何實質(zhì)性的改善,但內(nèi)存占用量確實有所減少。
以下是測試期間的響應(yīng)時間圖表:

響應(yīng)時間圖
請注意,在所有三種 Java 變體當(dāng)中,第一批請求的響應(yīng)時間要長得多(藍(lán)線相較于左軸的高度)而且在各項測試中,我們還看到一些峰值,其可能是由垃圾收集或優(yōu)化所引起。
 7. 第二輪測試
接下來,我們決定在更大的計算機上運行測試。在本輪中,我們使用臺具有 36 個核心(每核心雙線程)、256 GB 內(nèi)存的計算機,并配合 Oracle Linux 7.8 操作系統(tǒng)。
與第一輪一樣,我們?nèi)匀皇褂?100 個線程、每線程 10000 個循環(huán),10 秒啟動時間以及相同版本的 Go、Java、Helidon 以及 GraalVM。
下面來看結(jié)果:
應(yīng)用程序 日志記錄 預(yù)熱 平均響應(yīng)時間(毫秒) 事務(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)時間圖:

日志記錄,但未經(jīng)預(yù)熱的測試運行響應(yīng)時間

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

預(yù)熱,但未使用日志記錄的測試運行響應(yīng)時間
第二輪的觀察結(jié)果:
Java 變體在本輪測試中的性能表現(xiàn)大幅提升,而且在不使用日志記錄的情況下性能遠(yuǎn)優(yōu)于 Go。
與 Go 相比,Java 似乎更擅長使用硬件上的多個核心與執(zhí)行線程——這是因為 Go 本身主要作為系統(tǒng)及網(wǎng)絡(luò)編程語言存在,而且發(fā)展周期相對較短,因此在成熟度及優(yōu)化水平上不及 Java 也很正常。
有趣的是,Java 誕生之時多核心處理器并不常見,而 Go 誕生時多核處理器已經(jīng)成為行業(yè)標(biāo)準(zhǔn)。
具體來看,Java 似乎成功將日志記錄移交給其他線程 / 核心,因此極大減弱了其對性能的影響。
本輪最佳性能來自 GraalVM 原生鏡像,其平均響應(yīng)時間為 0.25 毫秒,每秒可執(zhí)行 82426 項事務(wù);Go 的最佳結(jié)果為 1.59 毫秒外加每秒 39227 項事務(wù),而其內(nèi)存占用量比前者高出兩個數(shù)量級!
GraalVM 原生鏡像變體的速度要比運行在 JVM 上的同一應(yīng)用程序快 30% 到 40%。
Java 變體的響應(yīng)時間更為穩(wěn)定,但出現(xiàn)的峰值更多——我們猜測這是因為 Go 會把垃圾回收分成更多更小的批次來執(zhí)行。
 8. 第三輪測試:Kubernetes
在第三輪中,我們決定在 Kubernetes 集群上運行應(yīng)用程序,借此模擬更為自然的微服務(wù)運行時環(huán)境。
在本輪中,我們使用包含三個工作節(jié)點的 Kubernets 1.16.8 集群,每個工作節(jié)點中包含兩個核心(各對應(yīng)兩個線程)、14 GB 內(nèi)存以及 Oracle Linux 7.8。在某些測試中,我們在變體上運行一個 Pod;在其他一些測試中,我們則運行一百個 Pod。
應(yīng)用程序訪問通過 Traefik 入口控制器實現(xiàn),其中 JMeter 運行在 Kubernetes 集群之外。在某些測試中,我們也會嘗試使用 ClusterIP 并在集群內(nèi)運行 JMeter。
與之前的測試一樣,我們使用 100 個線程、每線程 10000 個循環(huán),外加 10 秒啟動時間。
以下是各個變體的容器大?。?/div>
Go 11.6MB
Java/Helidon 1.41GB
Java/Helidon JLinked 150MB
原生鏡像 25.2MB
以下為本輪測試結(jié)果:
響應(yīng)時間圖表:

Kubernetes 測試中的響應(yīng)時間
在本輪中,可以看到 Go 有時更快,而 GraalVM 原生鏡像也經(jīng)常取得領(lǐng)先,但二者的差異很?。ㄒ话愕陀?5%)。
 9. 測試結(jié)論
縱觀幾輪測試與結(jié)果,我們得出了以下結(jié)論:
6
Kubernetes 似乎沒有快速橫向擴(kuò)展。
Java 似乎比 Go 更關(guān)于利用全部可用核心 / 線程,我們發(fā)現(xiàn) Java 測試期間 CPU 的利用率更高。
在核心及內(nèi)存容量更高的計算機上,Java 性能更好;在較小 / 性能較弱的計算機上,Go 性能更好。
Go 的性能總體上更加一致,這可能是由于 Java 中的垃圾回收機制所致。
在“生產(chǎn)規(guī)模”計算機上,Java 的運行速度與 Go 基本相當(dāng)、甚至更快一點。
日志記錄似乎成為 Go 及 Java 中的主要性能瓶頸。
Java 的現(xiàn)代版本以及 Helidon 等新型框架在消除 / 減輕 Java 長期存在的某些重大問題(例如冗長、GC 性能、啟動時間等)擁有良好的表現(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í)行的實際指令,看看能否在代碼路徑中做出進(jìn)一步優(yōu)化。
我們希望了解 JMeter 能否在不成為瓶頸的同時產(chǎn)生足夠多的負(fù)載,但此次測試結(jié)果表明 JMeter 并不構(gòu)成影響,而是能夠輕松跟上 Go 與 Java 實現(xiàn)的運行步伐。
我們打算對容器啟動時間、內(nèi)存占用量等指標(biāo)做出更詳細(xì)的測量。


相關(guān)文章

我們很樂意傾聽您的聲音!
即刻與我們?nèi)〉寐?lián)絡(luò)
成為日后肩并肩合作的伙伴。

聯(lián)系我們

13387904606

地址:新余市仙女湖區(qū)仙女湖大道萬商紅A2棟

手機:13755589003
QQ:122322500
微信號:13755589003

江西新余網(wǎng)站設(shè)計_小程序制作_OA系統(tǒng)開發(fā)_企業(yè)ERP管理系統(tǒng)_app開發(fā)-新余聯(lián)升網(wǎng)絡(luò)科技有限公司 贛ICP備19013599號-1   贛公網(wǎng)安備 36050202000267號   

微信二維碼