本篇內(nèi)容主要講解“Java微服務(wù)的優(yōu)點(diǎn)有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Java微服務(wù)的優(yōu)點(diǎn)有哪些”吧!
作為一家“創(chuàng)意+整合+營(yíng)銷(xiāo)”的成都網(wǎng)站建設(shè)機(jī)構(gòu)，我們?cè)跇I(yè)內(nèi)良好的客戶口碑。成都創(chuàng)新互聯(lián)公司提供從前期的網(wǎng)站品牌分析策劃、網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、創(chuàng)意表現(xiàn)、網(wǎng)頁(yè)制作、系統(tǒng)開(kāi)發(fā)以及后續(xù)網(wǎng)站營(yíng)銷(xiāo)運(yùn)營(yíng)等一系列服務(wù)，幫助企業(yè)打造創(chuàng)新的互聯(lián)網(wǎng)品牌經(jīng)營(yíng)模式與有效的網(wǎng)絡(luò)營(yíng)銷(xiāo)方法,創(chuàng)造更大的價(jià)值。
我們希望通過(guò)實(shí)驗(yàn)了解 Java 微服務(wù)在運(yùn)行速度上能否達(dá)到 Go 微服務(wù)的水平。目前，軟件行業(yè)普遍認(rèn)為 Java 已經(jīng)過(guò)于陳舊、緩慢且無(wú)聊。而 Go 則成了快速、嶄新以及酷炫的代名詞。真是這樣嗎？我們想從數(shù)據(jù)的角度看看這樣的印象是否站得住腳。
我們希望建立一個(gè)公平的測(cè)試，因此創(chuàng)建了一項(xiàng)非常簡(jiǎn)單的微服務(wù)，其中不含外部依賴項(xiàng)（例如數(shù)據(jù)庫(kù)），而且代碼路徑非常短（僅處理字符串）。我們?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ù)熱。
Java 由 Sun Microsystems 公司開(kāi)發(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 作為一種開(kāi)源語(yǔ)言仍是全球最受歡迎的語(yǔ)言選項(xiàng)之一（根據(jù) StackOverflow 及 TIOBE 等來(lái)源）。
下面來(lái)聊聊“Java 問(wèn)題”。人們對(duì)于它速度緩慢的印象其實(shí)更多是種固有觀念，而不再適應(yīng)當(dāng)下的事實(shí)。如今的 Java 甚至擁有不少性能敏感區(qū)，包括存儲(chǔ)對(duì)象數(shù)據(jù)堆、用于管理堆的垃圾收集器，外加準(zhǔn)時(shí)化（JIT）編譯器。
多年以來(lái)，Java 曾先后使用多種不同的垃圾收集算法，包括串行、并行、并發(fā)標(biāo)記 / 清除、G1 以及最新的 ZGC 垃圾收集器?，F(xiàn)代垃圾收集器旨在盡可能減少垃圾收集造成的暫停時(shí)長(zhǎng)。
甲骨文實(shí)驗(yàn)室開(kāi)發(fā)出一款名為 GraalVM 的 Java 虛擬機(jī)，其使用 Java 編寫(xiě)而成，具有新的編譯器外加一系列令人興奮的新功能，包括可以將 Java 字節(jié)碼轉(zhuǎn)換為無(wú)需 Java 虛擬機(jī)即可運(yùn)行的原生鏡像等。
Go 語(yǔ)言由谷歌的 Robert Griesemer、Rob Pike 以及 Ken Thomson 開(kāi)發(fā)而成。他們幾位也是 UNIX、B、C、Plan9 以及 UNIX 視窗系統(tǒng)等項(xiàng)目的主要貢獻(xiàn)者。作為一種開(kāi)源語(yǔ)言，Go 的 1.0 版本發(fā)布于 2012 年，2020 年最新版本為 1.15。Go 語(yǔ)言的本體、采用速度以及工具生態(tài)系統(tǒng)的發(fā)展都相當(dāng)迅猛。
Go 語(yǔ)言受到 C、Python、JavaScript 以及 C++ 的影響，已經(jīng)成為一種理想的高性能網(wǎng)絡(luò)與多處理語(yǔ)言。
截至我們發(fā)布主題演講時(shí)，StackOverflow 上共有 27872 個(gè)帶有“Go”標(biāo)簽的問(wèn)題，Java 則為 1702730 個(gè)。
Go 是一種靜態(tài)類型的編譯語(yǔ)言，其語(yǔ)法類似于 C，且擁有內(nèi)存安全、垃圾回收、結(jié)構(gòu)化類型以及 CSP 樣式并發(fā)（通信順序過(guò)程）等功能特性。Go 還使用名為 goroutine 的輕量級(jí)進(jìn)程（并非操作系統(tǒng)線程），外加各進(jìn)程間用于通信的通道（類型化，F(xiàn)IFO）。Go 語(yǔ)言不提供競(jìng)態(tài)條件保護(hù)。
Go 是眾多 CNCF 項(xiàng)目的首選語(yǔ)言，例如 Kubernetes、Istio、Prometheus 以及 Grafana 等皆是由 Go 語(yǔ)言編寫(xiě)而成（或者大部分是）。
Go 語(yǔ)言在設(shè)計(jì)上強(qiáng)調(diào)快速構(gòu)建與快速執(zhí)行。到底是兩個(gè)空格還是四個(gè)空格？Go 語(yǔ)言表示不用麻煩，無(wú)所謂。
與 Java 相比，我將個(gè)人體會(huì)到的 Go 語(yǔ)言優(yōu)勢(shì)整理如下：
更易于實(shí)現(xiàn)函數(shù)模式，例如復(fù)合、純函數(shù)、不可變狀態(tài)等。
樣板代碼少得多（但客觀上仍然太多）。
Go 語(yǔ)言仍處于生命周期早期，因此沒(méi)什么向下兼容壓力——改進(jìn)道路較為平坦。
Go 代碼可編譯為原生靜態(tài)鏈接的二進(jìn)制文件——無(wú)虛擬機(jī)層——二進(jìn)制文件中包含程序運(yùn)行所需要的一切，因此更適合“從零開(kāi)始”的容器。
體積更小、啟動(dòng)速度快、執(zhí)行速度快。
無(wú) OOP、繼承、泛型、斷言、指針?biāo)阈g(shù)。
括號(hào)較少，例如可以實(shí)現(xiàn)為 if x > 3 { whatever }
強(qiáng)制執(zhí)行，沒(méi)有循環(huán)依賴性，不存在未使用的變量或?qū)?，沒(méi)有隱式類型轉(zhuǎn)換。
但 Go 當(dāng)然也不完美。與 Java 相比，我認(rèn)為 Go 存在以下問(wèn)題：
工具生態(tài)系統(tǒng)還不成熟，特別是依賴項(xiàng)管理方面雖有多種選擇，但還都不完美。在非開(kāi)源開(kāi)發(fā)方面，Go 模塊在依賴項(xiàng)管理上優(yōu)勢(shì)明顯，但由于存在某些兼容性問(wèn)題，其采用率仍不算特別高。
構(gòu)建具有新的 / 更新依賴項(xiàng)的代碼時(shí)非常緩慢（例如 Maven 著稱的「下載互聯(lián)網(wǎng)」問(wèn)題）。
導(dǎo)入會(huì)將代碼綁定至 repo，導(dǎo)致代碼移動(dòng)非常困難。
IDE 非常適合編程、文檔查找與自動(dòng)補(bǔ)全等功能，但卻難以進(jìn)行調(diào)試及概要分析等。指針！我以為二十一世紀(jì)之前就可以告別這東西了，但 Go 里面還有！好在至少已經(jīng)沒(méi)有指針?biāo)惴恕?/p>
沒(méi)有 Java 那樣的 try/catch 異常（最終總是要用到 if err != nil），也沒(méi)有列表、映射函數(shù)等函數(shù)風(fēng)格的原語(yǔ)。
某些基本算法仍然缺失，所以用戶往往只能自行編寫(xiě)。最近我就編寫(xiě)了一些代碼，用 sloe 對(duì)兩個(gè)字符串（列表）進(jìn)行比較以及轉(zhuǎn)換。在函數(shù)語(yǔ)言中，我們完全可以使用 map 等內(nèi)置算法完成。
沒(mé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)。
我們使用 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)過(guò)對(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)參見(jiàn) GitHub repo：https://github.com/markxnelson/go-java-go
在第一輪測(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é)果如下：
我們宣布，Go 成為首輪測(cè)試的獲勝者！
以下為根據(jù)這些結(jié)果得出的觀察結(jié)論：
日志記錄似乎是影響性能的主要問(wèn)題，特別是 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)行過(guò)程中會(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)用程序。
GraalVM 提供原生鏡像功能，使您能夠使用 Java 應(yīng)用程序并在實(shí)質(zhì)上將其編譯為原生可執(zhí)行代碼。根據(jù) GraalVM 項(xiàng)目網(wǎng)站的介紹：
該可執(zhí)行文件包含應(yīng)用程序類、依賴項(xiàng)中的類、運(yùn)行時(shí)庫(kù)類以及 JDK 中的靜態(tài)鏈接原生代碼。其并非運(yùn)行在 Java 虛擬機(jī)之上，而是包含必要組件，例如來(lái)自不同運(yùn)行時(shí)系統(tǒng)（也被稱為「基層虛擬機(jī)」）的內(nèi)存管理、線程調(diào)度等功能。基層虛擬機(jī)代表的是各運(yùn)行時(shí)組件（例如反優(yōu)化器、垃圾收集器、線程調(diào)度等）。
在添加 GraalVM 原生鏡像（原生鏡像由 GraalVM EE 20.1.1——JDK 11 構(gòu)建而成）之后，首輪測(cè)試結(jié)果如下：
在這種情況下，與運(yùn)行在 JVM 上的應(yīng)用程序相比，我們發(fā)現(xiàn)使用 GraalVM 原生鏡像并不會(huì)在吞吐量或者響應(yīng)時(shí)間等層面帶來(lái)任何實(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)化所引起。
接下來(lái)，我們決定在更大的計(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。
下面來(lái)看結(jié)果：
我們宣布，GraalVM 原生鏡像成為第二輪測(cè)試的贏家！
下面來(lái)看本輪測(cè)試的響應(yīng)時(shí)間圖：
啟用日志記錄，但未經(jīng)預(yù)熱的測(cè)試運(yùn)行響應(yīng)時(shí)間
不使用日志記錄也未經(jīng)預(yù)熱的測(cè)試運(yùn)行響應(yīng)時(shí)間
經(jīng)過(guò)預(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ò)編程語(yǔ)言存在，而且發(fā)展周期相對(duì)較短，因此在成熟度及優(yōu)化水平上不及 Java 也很正常。
有趣的是，Java 誕生之時(shí)多核心處理器并不常見(jiàn)，而 Go 誕生時(shí)多核處理器已經(jīng)成為行業(yè)標(biāo)準(zhǔn)。
具體來(lái)看，Java 似乎成功將日志記錄移交給其他線程 / 核心，因此極大減弱了其對(duì)性能的影響。
本輪最佳性能來(lái)自 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ì)把垃圾回收分成更多更小的批次來(lái)執(zhí)行。
在第三輪中，我們決定在 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)用程序訪問(wèn)通過(guò) 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è)變體的容器大?。?/p>
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%）。
縱觀幾輪測(cè)試與結(jié)果，我們得出了以下結(jié)論：
Kubernetes 似乎沒(méi)有快速橫向擴(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)期存在的某些重大問(wèn)題（例如冗長(zhǎng)、GC 性能、啟動(dòng)時(shí)間等）擁有良好的表現(xiàn)。
經(jīng)過(guò)這輪有趣的測(cè)試，我們打算繼續(xù)探索，特別是：
我們打算通過(guò) 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)。
我們還打算深挖日志記錄問(wèn)題，了解解決此瓶頸的方法。
我們希望查看目標(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è)量。
到此，相信大家對(duì)“Java微服務(wù)的優(yōu)點(diǎn)有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
重慶分公司
重慶分公司
