99re66热这里只有精品6,强伦姧中文字幕在线观看,国产美女作爱免费观看,国产亚洲精品观看91在线蝌蚪窝,婷婷丁香六月激情五月综合,国内黄色一级无码视频,午夜精品中文av资源站在线观看

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

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

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

響應(yīng)時(shí)間圖
請(qǐng)注意,在所有三種 Java 變體當(dāng)中,第一批請(qǐng)求的響應(yīng)時(shí)間要長(zhǎng)得多(藍(lán)線相較于左軸的高度)而且在各項(xiàng)測(cè)試中,我們還看到一些峰值,其可能是由垃圾收集或優(yōu)化所引起。
 7. 第二輪測(cè)試
接下來,我們決定在更大的計(jì)算機(jī)上運(yùn)行測(cè)試。在本輪中,我們使用臺(tái)具有 36 個(gè)核心(每核心雙線程)、256 GB 內(nèi)存的計(jì)算機(jī),并配合 Oracle Linux 7.8 操作系統(tǒng)。
與第一輪一樣,我們?nèi)匀皇褂?100 個(gè)線程、每線程 10000 個(gè)循環(huán),10 秒啟動(dòng)時(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 原生鏡像成為第二輪測(cè)試的贏家!
下面來看本輪測(cè)試的響應(yīng)時(shí)間圖:

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

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

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

Kubernetes 測(cè)試中的響應(yīng)時(shí)間
在本輪中,可以看到 Go 有時(shí)更快,而 GraalVM 原生鏡像也經(jīng)常取得領(lǐng)先,但二者的差異很小(一般低于 5%)。
 9. 測(cè)試結(jié)論
縱觀幾輪測(cè)試與結(jié)果,我們得出了以下結(jié)論:
6
Kubernetes 似乎沒有快速橫向擴(kuò)展。
Java 似乎比 Go 更關(guān)于利用全部可用核心 / 線程,我們發(fā)現(xiàn) Java 測(cè)試期間 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 長(zhǎng)期存在的某些重大問題(例如冗長(zhǎng)、GC 性能、啟動(dòng)時(shí)間等)擁有良好的表現(xiàn)。
 10. 未來展望
經(jīng)過這輪有趣的測(cè)試,我們打算繼續(xù)探索,特別是:
我們打算通過 Kubernetes 自動(dòng)擴(kuò)展做更多工作,包括引入更復(fù)雜的微服務(wù)或更高的負(fù)載以凸顯出性能上的差異。
我們希望研究更復(fù)雜的微服務(wù)、多種服務(wù)類型以及模式,觀察網(wǎng)絡(luò)如何影響性能,以及應(yīng)如何對(duì)微服務(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ù)載,但此次測(cè)試結(jié)果表明 JMeter 并不構(gòu)成影響,而是能夠輕松跟上 Go 與 Java 實(shí)現(xiàn)的運(yùn)行步伐。
我們打算對(duì)容器啟動(dòng)時(shí)間、內(nèi)存占用量等指標(biāo)做出更詳細(xì)的測(cè)量。


相關(guān)文章

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

行業(yè)資訊

聯(lián)系我們

13387904606

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

手機(jī):13755589003
QQ:122322500
微信號(hào):13755589003

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

微信二維碼