可能是國內(nèi)第一篇全面解讀 Java 現(xiàn)狀及趨勢的文章

作者 | 張曉楠

導(dǎo)讀：InfoQ 發(fā)布《2019 中國 Java 發(fā)展趨勢報告》，反映 Java 在中國發(fā)展的獨特性，同時也希望大家對 Java 有一個正確的認識。

2 個月前，InfoQ 英文站發(fā)布了一份《2019 Java 發(fā)展趨勢報告》，從技術(shù)采用生命周期的角度，分析了 Java 這門 20 多年歷史語言的發(fā)展現(xiàn)狀。這份報告發(fā)布后，發(fā)生了幾個我們沒想到的問題：一是有些開發(fā)者對 Java 產(chǎn)生了深深的懷疑，有人表示“現(xiàn)在還值得深入研究 Java 嗎？”，有人表示“Java 已經(jīng)落后別的語言好多年”；二是有人覺得這份報告不接地氣，沒有呈現(xiàn)出 Java 在中國的發(fā)展情況。

基于以上兩個原因，我們決定策劃和撰寫這份《2019 中國 Java 發(fā)展趨勢報告》，要把 Java 在中國發(fā)展的獨特性反映出來，同時也希望大家對 Java 有一個正確的認識：既不捧殺，也不要妖魔化。

毫不慚愧的說，這份中國區(qū)的 Java 發(fā)展趨勢報告無論是參與專家，還是呈現(xiàn)角度，都要優(yōu)于英文站的報告。專家來自阿里、騰訊、華為、美團、今日頭條、小米、紅帽... 多家技術(shù)實踐前沿企業(yè)，報告范疇不僅包括 Java、JVM、Java EE 主流框架，還包括了各企業(yè)的 Java 應(yīng)用實踐訪談以及對 Java 趨勢的點評。除此以外，我們還在 InfoQ 社區(qū)發(fā)起了 Java 開發(fā)者調(diào)查，把開發(fā)者的 Java 使用情況也如實呈現(xiàn)在本次趨勢報告中。好了，話不多說，切入正題。

參與本次趨勢報告的專家

楊曉峰，Java 技術(shù)專家，OpenJDK Committer
李三紅，阿里 / 螞蟻 Java 技術(shù)負責(zé)人，阿里云智能資深技術(shù)專家
小馬哥，阿里巴巴 Apache Dubbo PMC 和 Spring-Cloud-Alibaba Architect
田曉亮，華為云 ServiceStage 首席工程師和 Apache ServiceComb PMC
單致豪，騰訊 TARS 開源項目負責(zé)人
吳革，美團點評高級技術(shù)專家
陳楚暉，紅帽 AppDev 首席架構(gòu)師，開源技術(shù)專家
王石沖，字節(jié)跳動大數(shù)據(jù)工程師、Scala 程序員
張濤，Kotlin 專家，Android 技術(shù)專家，開源實驗室博主
黃飛，小米互聯(lián)網(wǎng)商業(yè)部技術(shù)主管

Java 技術(shù)采用生命周期概覽

這張中國 Java 技術(shù)采用生命周期概覽圖是本次趨勢報告的精華，結(jié)論來自于各位專家的判斷。某些方面專家們觀點出奇的一致，當(dāng)然也有很多部分專家觀點并不相同?？芍^是金句頻現(xiàn)、火花四濺。

技術(shù)采用生命周期劃分方式

創(chuàng)新者
早期采用者
早期大眾
晚期大眾

技術(shù)采用生命周期是美國高科技營銷大師杰弗里·摩爾在自己的書《跨越鴻溝》里提出的概念。技術(shù)采用生命周期是一個用來衡量用戶對某項新技術(shù)接受程度的模型，它認為一個新的技術(shù)，從一開始出現(xiàn)到最后走向成熟，必然會經(jīng)歷創(chuàng)新者、早期采用者、早期大眾、晚期大眾的階段。

雖然每個人群間都會有裂縫，但是早期采用者和早期大眾之間的那條裂縫最大，這條裂縫就是傳說中的“鴻溝”，只有跨越過這條鴻溝，滲透到早期大眾這個人群，產(chǎn)品才等于是進入了主流市場。

重要結(jié)論

1. Java 13 處于創(chuàng)新者階段，Java 11 處于早期采用者階段，Java 8 處于晚期大眾階段。

Java 11 將是未來 Java 用戶的最可能選項；
如果一個公司對大堆棧 GC 能力、延遲 SLA 等方面要求沒有那么高，就沒有足夠動力去做相關(guān)升級，也未必有技術(shù)力量解決版本評估、兼容性修正等現(xiàn)實問題；
Java 新版本升級在中國的宣傳還是不夠，如果很多企業(yè)看不到技術(shù)升級的紅利，勢必也影響升級的積極性。

2. OpenJDK 處于創(chuàng)新者階段。

雖然國內(nèi)很多頭部廠商都在定制 OpenJDK，但是目前定制 OpenJDK 被采用范圍還都有限，主體使用還是 Oracle JDK（根據(jù)《JVM 生態(tài)系統(tǒng)報告 2018》調(diào)查顯示，70% 的開發(fā)者選擇使用 Oracle JDK，21% 的開發(fā)者選擇使用 OpenJDK）；
廠商是否轉(zhuǎn)向 OpenJDK，還有一個重要考量因素就是看他們是否愿意付費使用 OracleJDK，如果不是的話，未來 OpenJDK 可能會逐漸取代 Oracle JDK，目前國內(nèi)頭部廠商都在 OpenJDK 上有所動作；（對于參與 OpenJDK 的國內(nèi)頭部廠商來說，可能他們的看法更加積極，他們把 OpenJDK 定義在早期大眾階段）
大家在公有云、私有云等方面的競爭格局，深刻影響著在 OpenJDK 上的競爭格局；
OpenJDK 很可能被認為是一種退?求其次的選擇。

3. 非 Hotspot JDK 生產(chǎn)實踐——Graal VM、IBM OpenJ9 處于早期采用者階段。

Graal VM 目前還尚不可知其兼容性情況以及明確的商業(yè)化條款；
Graal VM 的部分技術(shù)，例如，基于 Java 語言開發(fā)的 JIT 引擎，可能會成為未來 OpenJDK 的基礎(chǔ)技術(shù)；
在國內(nèi)，懷疑 Graal VM、IBM OpenJ9 進入普遍生產(chǎn)實踐的可能性會比較低。

4. Lambda /Stream 處于晚期大眾階段、Vector API 處于創(chuàng)新者階段。

Lambda 語法以及 Stream API 也在開發(fā)人員的?常?作中?泛地運用，并且沒有看到語法回退的趨勢；
Vector API 等前沿特性，有能力的公司有限，抑制了對其有需求的公司或者場景。

5. Kotlin 處于早期大眾階段，Scala 和 Groovy 處于晚期大眾階段。

Groovy 已快成為明日黃花，往昔的光芒逐漸地被后起之秀 Kotlin 替代；
Scala 在適合的領(lǐng)域做王者就夠了，主流不主流沒那么重要；
Kotlin 被谷歌強推，谷歌支持的基本上都成功了，但是對 Kotlin 未來發(fā)展空間還是表示懷疑；
網(wǎng)上很多文章都在鼓吹，說 Kotlin 最終會取代 Java 成為新一代 JVM 主流語言，但是從誕生到現(xiàn)在，好像依然沒有語言能取代 Java。

6. 微服務(wù)框架：Spring Boot 和 Spring Cloud 進入晚期大眾階段；ServiceComb 處于早期采用者階段；Apache Dubbo 處于晚期大眾階段；Tars 處于早期大眾階段。

微服務(wù)技術(shù)處于早期大眾與晚期大眾之間，新的微服務(wù)開發(fā)框架需要技術(shù)突破和創(chuàng)新，不然已經(jīng)難有一席之地；
Java 不再是微服務(wù)唯一的選擇；
在技術(shù)多元化的今天，支持多語言的微服務(wù)開發(fā)框架是個必須品。

技術(shù)采用生命周期解讀

在上一章節(jié)我們已經(jīng)先把各位專家的觀點和結(jié)論拋了出來，但是結(jié)論背后還需要很關(guān)鍵的原因解讀，所以這一章節(jié)就按照 Java/JVM、不同層次的主流框架、微服務(wù)這三個部分，來逐一呈現(xiàn)。

Java/JVM

其實在 Java 版本方面，各位專家的觀點完全一致：Java 13 處于創(chuàng)新者階段，Java 11 處于早期采用者階段，Java 8 處于晚期大眾階段。

在 InfoQ 面向開發(fā)者的 Java 使用版本調(diào)查中，毫無懸念，在參與問卷調(diào)研的開發(fā)者中，88.7% 正在使用 Java8 版本，這些人當(dāng)中只有 35% 有升級計劃，剩余 65% 并沒有升級計劃。

楊曉峰認為這一情況也正常：Java8 在可預(yù)見的將來依然會是生產(chǎn)的主體，放在晚期大眾階段是合理的。但是對于很多頭部廠商來說，Java11 或者再后續(xù)版本，有可能陸續(xù)出現(xiàn)一定規(guī)模的生產(chǎn)化部署。他認為這樣的趨勢只會在頭部公司發(fā)生，如果一個公司對大堆棧 GC 能力、延遲 SLA 等方面要求沒有那么高，就沒有足夠動力去做相關(guān)升級，也未必有技術(shù)力量解決版本評估、兼容性修正等現(xiàn)實問題。所以結(jié)論就是：Java11 處于早期采用者階段。

對此黃飛補充：也正是因為 Java11 處于早期采用者階段，因此相關(guān)的資料較少，遇到問題會有比較高的學(xué)習(xí)成本，例如 JFR 對 11 的支持，JMC 對 Java11 的分析能力較弱。

而對于 Java 13，小馬哥認為該版本在新 GC 算法的提升以及 Socket 實現(xiàn)上的變化還是非常令?期待的，因此 Java 13 排在創(chuàng)新者之列。

對于 Java 的升級，Oracle 宣布從 Java 9 開始每半年將更新一個 Java 大版本——Java 11 是長期支持（Long-Term -Support, LTS）版本，Java 9、10 則成了過渡版本（non?LTS），因此，陳楚暉不建議用戶在生產(chǎn)中使用 Java 9、10。在他看來，小版本升級相對風(fēng)險是比較小的，而大版本變更則會有可能需要更改大量的代碼，這也是為什么這么多人還在堅持用 Java8，而不去更新 Java 11、12、或者 13 的原因。

對于開發(fā)者升級 Java 動力不足的原因，李三紅的解釋更為詳細，他認為有兩個原因：

敏捷的基礎(chǔ)底層架構(gòu)對軟件升級的支持，企業(yè)對底層架構(gòu)的重視程度也是 Java 升級的一個很關(guān)鍵原因。中國的企業(yè)業(yè)務(wù)發(fā)展都很快，但是其實很多對底層架構(gòu)的支持和重視是不足夠的。底層架構(gòu)是否在企業(yè)內(nèi)部被統(tǒng)一強管控，是否很容易支持不同軟件版本的灰度，并能通過有效的預(yù)發(fā)測試，覆蓋軟件升級不兼容等帶來的不確定性，這都考驗著軟件升級的難度。
另外一點，如果企業(yè)享受不到技術(shù)升級帶來的紅利，包括性能、編程效率等多方面提升，勢必也影響升級的積極性。

從此次 InfoQ 面向開發(fā)者的調(diào)研來看，對于目前 Java 的新特性和發(fā)展方向，56% 的開發(fā)者認為可以解決當(dāng)前的主要業(yè)務(wù)挑戰(zhàn)，24% 開發(fā)者的觀點是不能。這也從另一層面表明：Java 經(jīng)常被吐槽演進太慢，但是業(yè)界對新版本的采用并不十分積極，這可能反映了 Java/JVM 發(fā)展與開發(fā)者的實際需求存在某種脫節(jié)。

OpenJDK 定制版或者公開發(fā)行版

由于 Oracle 宣布 2019 年伊始，Oracle JDK 8 以及更?版本在服務(wù)器端部署不再免費，因此 OpenJDK 就成為了大多數(shù) Java 用戶的選項。根據(jù)《JVM 生態(tài)系統(tǒng)報告 2018》調(diào)查顯示，70% 的開發(fā)者選擇使用 Oracle JDK，21% 的開發(fā)者選擇使用 OpenJDK。陳楚暉也介紹了國內(nèi)的情況：目前國內(nèi)開發(fā)者使用最多的依舊是 Oracle JDK，其次是 IBM JDK，也有部分企業(yè)采用 OpenJDK。報告鏈接：https://snyk.io/blog/jvm-ecosystem-report-2018/

對于 OpenJDK 的技術(shù)采用生命周期劃分，專家們有一些觀點上的不一致，楊曉峰認為雖然國內(nèi)很多頭部廠商都在定制 OpenJDK，但是目前定制 OpenJDK 被采用范圍還都有限，這也跟上文數(shù)據(jù)結(jié)果吻合，所以他會把 OpenJDK 歸在創(chuàng)新者階段。

但是對于參與 OpenJDK 的國內(nèi)廠商來說，可能看法更加積極。在李三紅看來：廠商是否轉(zhuǎn)向 OpenJDK，還有一個重要考量因素就是看他們是否愿意付費使用 OracleJDK，如果不是的話，未來 OpenJDK 可能會逐漸取代 Oracle JDK，目前國內(nèi)頭部廠商都在 OpenJDK 上有所動作，所以他把 OpenJDK 定義在早期大眾階段。阿里巴巴使用并開源了 OpenJDK 長期支持版本 Dragonwell，目前阿里巴巴大部分的應(yīng)用運行在 Dragonwell 8, 有些已經(jīng)運行在 Dragonwell 11。

據(jù)來自美團的吳革介紹：美團現(xiàn)階段正在測試基于 OpenJDK 的 MtJDK，作為美團 JDK 基礎(chǔ)服務(wù)。此外，美團主要會關(guān)注 Redhat 和 Amazon 的升級。由于 Azul 沒有公開 OpenJDK 源代碼，所以美團沒有基于 Azul 進行研發(fā)。

來自小米的黃飛也介紹了小米對于 OpenJDK 的應(yīng)用情況：小米主要使用 OpenJDK8 以及 11 版本，目前對 OpenJDK 主要還是以使用為主。

從現(xiàn)有的 OpenJDK 陣營來看，目前分為兩類，一類是 IT 和云廠商，他們對外提供發(fā)布、銷售的 OpenJDK 版本——Amazon、Redhat、Azul 、阿里巴巴、騰訊都在自己生產(chǎn)（除了微軟分發(fā) Azul）；另外就是技術(shù)上的強需求導(dǎo)致自身有定制 OpenJDK 的公司，他們的 OpenJDK 產(chǎn)品較難突破內(nèi)部使用的范圍，比如我們采訪調(diào)研的美團、小米。

對于這樣的一個陣營劃分，楊曉峰有一個觀點：從 OpenJDK 發(fā)布版的競爭格局來看，最終會演變?yōu)樵频母窬?，堅持下來的會是頭部云廠商或與其合作的軟件廠商。換句話說大家在公有云、私有云等方面的競爭格局，深刻影響著在 OpenJDK 上的競爭格局。畢竟對于企業(yè)來說，做 OpenJDK 也需要有利可圖，沒有廣泛的用戶群體和對等的收益，很難支撐基礎(chǔ)軟件的長期演進。

我們把以上觀點拋給了此次調(diào)研采訪對象——IT 公司和云廠商陣營的代表李三紅，在他看來：在 Java 收費的情況下，OpenJDK 一定是大勢所趨，Java 會越來越開放，深度參與 OpenJDK 也是為了通過社區(qū)驅(qū)動 Java 往前走；另外，在當(dāng)前企業(yè)上云的大趨勢下，如果客戶的現(xiàn)有系統(tǒng)是用 Java 寫的，云廠商在為客戶提供服務(wù)的時候勢必要考慮如何讓 Java 生態(tài)變得更好，這也是符合客戶的訴求。

不過楊曉峰也表示：從企業(yè) IT 決策角度來說，相當(dāng)一部分企業(yè)更加看重的是長期可信的支持、及時的安全漏洞和 bug 修復(fù)等。也會有可觀的企業(yè)會決定風(fēng)險自負，直接獲取免費、自由的 OpenJDK 發(fā)行版，并不會購買支持服務(wù)，甚至不考慮升級 JDK，直到今天 JDK 7 等歷史版本仍有可觀的占有率，正是說明了這一點。

非 Hotspot JDK 生產(chǎn)實踐——Graal VM、IBM OpenJ9

Graal VM 被列為早期采用者階段，對此李三紅表示：Graal VM 已經(jīng)在 Oracle Cloud 生產(chǎn)環(huán)境大規(guī)模使用，TCK 兼容。值得一提的是，Graal VM 下的靜態(tài)編譯 SVM 造成了 Java 語言一些方面的不兼容，這個也是整個社區(qū)擔(dān)心的地方。如何讓 SVM/ 靜態(tài)編譯能納入到 Java Language/JVM Specification 里來？值得關(guān)注。

楊曉峰的看法更加極端：在國內(nèi)，懷疑 Graal VM、IBM OpenJ9 進入普遍生產(chǎn)實踐的可能性會比較低。懷疑它們可能不會再走到下個階段，很難跨越技術(shù)鴻溝。提及原因，他認為主要是國內(nèi)公司大都在強調(diào)業(yè)務(wù)創(chuàng)新的速度，沒有做如此深度的底層更新的耐心和業(yè)務(wù)必要性。而且從技術(shù)上來看，在動態(tài)特性支持等需求沒有平滑解決方案之前，遷移難度很高，會帶來很高的開發(fā)和運維成本。

所以對于國內(nèi)普通企業(yè)用戶來說，沒有單獨關(guān)注的價值。未來更加現(xiàn)實的技術(shù)采用路徑是，用戶使用集成了 Graal VM 先進技術(shù)的 OpenJDK 主分支。同樣，IBM OpenJ9 有很多獨到的技術(shù)，如果能夠合并入 OpenJDK 主分支，更能創(chuàng)造普遍的生產(chǎn)價值，否則難免會被局限在 IBM 中間件等用戶群內(nèi)部。另外，訂閱 Graal VM 服務(wù)的具體信息可能在今年 Code One 會有說明，大家有興趣可以關(guān)注。

Lambda /Stream、Vector API 等語法與特性

對于 Lambda /Stream 等語法與特性，采訪調(diào)研專家認為應(yīng)該歸類在晚期大眾階段。小馬哥認為這些語法與特性在開發(fā)人員的?常?作中?泛地運用，并且沒有看到語法回退的趨勢。吳革表示：在美團內(nèi)部，目前已經(jīng)大量使用 Lambda 和 Stream 表達式。

而對于 Vector API 等前沿版本特性，楊曉峰認為還只在個別頭部公司處于原型階段，應(yīng)該被歸在創(chuàng)新者階段。

Kotlin、Scala

對于 Kotlin 和 Scala，我們也采訪調(diào)研了兩位 Kotlin 和 Scala 領(lǐng)域的專家。

在今年 5 月份的 Google I/O 大會上，Google 官方正式宣布：Kotlin 是 Android 應(yīng)用程序開發(fā)人員的首選語言。這是否意味著 Java 占據(jù) Android 開發(fā)絕對統(tǒng)治的時代一去不復(fù)返了？

雖然身為 Kotlin 專家，但是張濤的觀點還是很理性而客觀的，他表示：每幾年都會有語言號稱要取代 Java，但是從誕生到現(xiàn)在，好像依然沒有語言能取代它。這主要源于 Java 在服務(wù)端的穩(wěn)固地位，沒有語言能夠做到 Java 這樣完善的社區(qū)、用戶群和三方庫支持。

張濤認為：Kotlin 在國內(nèi)應(yīng)該處于早期大眾向晚期大眾過渡階段，在未來一兩年內(nèi)，會有大部分的 JVM 平臺開發(fā)者開始使用 Kotlin。

在 2017 年年底，張濤曾經(jīng)做過一次調(diào)查，邀請將近 1000 名 Android 開發(fā)者，了解他們的項目中是否使用了 Kotlin。當(dāng)時的結(jié)果是 30% 的人使用過 Kotlin，60% 的人聽說過 Kotlin，還有 80 多人沒有聽說過。他相信目前國內(nèi)的 Android 應(yīng)用應(yīng)該 90% 都包含有 Kotlin 代碼。

此前 InfoQ 曾對字節(jié)跳動大數(shù)據(jù)工程師、Scala 程序員王石沖以及另外幾位來自 Scala 社區(qū)的專家進行過一次訪談，了解 Scala 在國內(nèi)的發(fā)展情況。對于有人認為的 Scala 難成主流的說法，王石沖表示：Scala 為什么非要成為主流呢？它在自己適合的領(lǐng)域做王者就夠了，主流不主流其實并不是那么重要。

王石沖把 Scala 歸在早期大眾或者晚期大眾階段：Scala 在可預(yù)見的未來都會是小眾——有一少部分人非常喜愛它；有一少部分團隊或公司在使用它；大部分人最多只是聽說過它而已。Scala 無論是在國內(nèi)還是在國外，都稱不上是主流語言。不過有部分團隊水平很高的公司，還是深度應(yīng)用 Scala 來做事情。

成名的例子就有 Twitter、LinkedIn、Verizon 等。金融行業(yè)則有摩根士丹利、渣打等（但是他們作為悶聲發(fā)大財?shù)牡湫?，很少對外宣傳自己的技術(shù)選型）。而很多硅谷的初創(chuàng)團隊早期為了快速開發(fā)，也是采用的 Scala。在國內(nèi)，除了小米、阿里和騰訊的部分團隊以及類似于 GrowingIO、水滴這樣的初創(chuàng)公司和一些廣告公司外，大部分開發(fā)者都是應(yīng)用 Scala 來做 Spark 開發(fā)。因為沒有典型的、具有號召力的大公司主導(dǎo)，所以 Scala 在社區(qū)方面做得也一般。

Spring Boot/Cloud、Apache Dubbo、TARS、ServiceComb 等微服務(wù)框架

對于微服務(wù)框架的技術(shù)采用生命周期的劃分，我們分別采訪調(diào)研了阿里、騰訊、華為等幾家大廠的專家，這幾家大廠都擁有各自的微服務(wù)框架解決方案。不過微服務(wù)框架的王者依舊非 Spring Boot 和 Spring Cloud 莫屬，對于這一點大家也達成了共識——Spring Boot/Cloud 處于晚期采用者階段，擁有大量用戶。從 InfoQ 此次面向開發(fā)者的調(diào)研來看，選擇 Spring Boot/Cloud 的開發(fā)者占到 70%；其次是 Apache Dubbo，占到 20%；其他微服務(wù)框架的占比都還不太高。

田曉亮表示：Spring Cloud 社區(qū)依然在蓬勃發(fā)展，也開始為云廠商創(chuàng)造商業(yè)機會，如何與 Spring Cloud 結(jié)合，成為了云廠商要解決的關(guān)鍵問題之一。

雖然越來越多的企業(yè)選擇了 ServiceComb 進行微服務(wù)轉(zhuǎn)型，并獲得了成功，但并未普及到早期大眾階段。ServiceComb 中微服務(wù)框架與 Service Mesh 可以融合使用，讓用戶有了靈活的選擇。

Java 依然是最流行的語言，但企業(yè)也終于能夠選擇其他語言進行微服務(wù)開發(fā)了。同時提供 Spring Cloud 的組件可以使其接入到 ServiceComb 中，幫助 Spring Cloud 用戶平滑向多語言轉(zhuǎn)型，Java 不再是微服務(wù)唯一的選擇。

Apache Dubbo 一開始并不叫這個名字，Dubbo 一開始只是阿里內(nèi)部的一個系統(tǒng)，2010 年 Dubbo 項目進行重構(gòu)，2018 年初，Dubbo 項目正式進入 Apache 孵化器。在小馬哥看來，Apache Dubbo 屬于晚期大眾階段，不過最新的 Apache Dubbo ECO System（生態(tài)系統(tǒng)）則是一個基于 Apache Dubbo 衍進的 Cloud Native 解決方案，目前尚未枝葉茂盛，處于創(chuàng)新者陣營。

對于 Apache Dubbo，黃飛表示：它在 RPC 中間件這個領(lǐng)域可以算得上引領(lǐng)者之一。Apache Dubbo 的服務(wù)注冊與發(fā)現(xiàn)、服務(wù)治理相對完善，支持灰度發(fā)布，智能的負載均衡策略、可視化的服務(wù)治理與運維工具便于開發(fā)人員上手。可以說 Dubbo/Dubbox 在 RPC 框架 / 微服務(wù)領(lǐng)域已經(jīng)展露頭腳甚至在某些方面已經(jīng)形成優(yōu)勢。

TARS 在騰訊內(nèi)部叫 TAF(Tencent Application Framework)，是騰訊應(yīng)用產(chǎn)品最多、最廣泛的微服務(wù)開發(fā)框架，并且已經(jīng)在騰訊大規(guī)模應(yīng)用了超過十年。2017 年中旬，騰訊正式將 TARS 開源，開源后一年便成為 Linux 基金會開源項目。由于相對其他微服務(wù)項目開源晚，錯過了很多社區(qū)發(fā)展紅利。

對于 TARS，據(jù)單致豪介紹，不同的微服務(wù)主流框架可以滿足不同的應(yīng)用痛點，TARS 則原生專注多語言和高性能。他認為 TARS 已經(jīng)有大型互聯(lián)網(wǎng)公司廣泛使用，已經(jīng)從早期采用者階段邁過了鴻溝，進入了早期大眾階段。

Java 應(yīng)用實踐

InfoQ：您的企業(yè)使用的 JDK 版本情況，是否采用了某個 OpenJDK 發(fā)行版？您如何看待 OpenJDK 在國內(nèi)的發(fā)展？（如果沒有采用，原因以及后續(xù)計劃？）

阿里巴巴李三紅：目前阿里巴巴大部分的應(yīng)用運行在 Dragonwell 8，有些已經(jīng)運行在了 Dragonwell 11，我們正在逐步推動從 Java8 到 Java11 的升級，充分享受技術(shù)紅利。

美團吳革：美團現(xiàn)階段主要使用 Java8，很少一部分是 Java7。部分核心團隊正在嘗試 Java 11。在美團內(nèi)部采用的開發(fā)版本 JDK 主要還是 Oracle JDK。我們在服務(wù)器上的 JDK 版本主要是美團自己的 MtJDK 和 Oracle JDK。美團現(xiàn)階段正在測試基于 OpenJDK 的 MtJDK，作為美團 JDK 基礎(chǔ)服務(wù)。

MtJDK 主要基于 OpenJDK 構(gòu)建，現(xiàn)階段主要針對補丁和安全性進行維護。現(xiàn)階段在特定業(yè)務(wù)線內(nèi)部進行測試和應(yīng)用。未來配合 Serverless 等基礎(chǔ)服務(wù)升級，MtJDK 會在 JDK 啟動性能和增強應(yīng)用之間的隔離進行深度定制。

小米黃飛：小米主要使用 OpenJDK8 以及 11 版本。目前對 OpenJDK 主要還是以使用為主，主要的業(yè)務(wù)關(guān)注點在于這個版本是否為長期支持；是否有更加高效易用的特征，例如 GC 算法由 CMS、G1 升級到 ZGC 等；開源社區(qū)是否活躍；以及對遇到的問題是否有足夠豐富的資料與討論等。 Java 作為使用最為廣泛的語言，最近幾年還是有比較大進步的，無論從語法的易用性上還是性能上都有很大程度的提升。吸收了函數(shù)式編程的思想，lambda 表達式、Parallem stream、Var 變量等提升了開發(fā)人員的效率與代碼的簡潔性。ZGC 無疑是一項重大的改進，在一定程度上解決了 Java 天生的 GC 問題。

InfoQ：您的企業(yè)目前在支持 Java 技術(shù)棧方面的策略是什么？計劃和目標是什么？相關(guān)的核心痛點或者業(yè)務(wù)需求是什么？

騰訊單致豪：騰訊內(nèi)部占領(lǐng)導(dǎo)地位的開發(fā)者是 C++，同時有大量的 Node.Js、Golang、Java、PHP、Python 開發(fā)者，當(dāng)然也有少量的 Rust、C# 的開發(fā)者。我們在海量用戶的后端大部分采用 C++ 和 Golang，Java 在前端和大數(shù)據(jù)方面有廣泛使用，在對外 ToB 的交付中也大量采用。

由于騰訊的開發(fā)者使用了多種開發(fā)語言，而且不同開發(fā)語言在不同領(lǐng)域有不同優(yōu)勢，所以當(dāng)前要解決的問題是多語言開發(fā)的服務(wù)互通問題，一套支持多語言的微服務(wù)開發(fā)框架是必需品，TARS 也是在這樣的多語言背景下誕生。

美團吳革：美團的 Java 技術(shù)棧策略偏向穩(wěn)定，在穩(wěn)定的基礎(chǔ)之上推動技術(shù)升級。Java 核心痛點就是依賴升級，當(dāng)一個 jar 包升級，必須一個服務(wù)一個服務(wù)升級，不能自動化整體升級，所以對于美團來說，正在解決相關(guān)依賴升級的問題。

紅帽陳楚暉：紅帽主要采用市場流行的 Java 技術(shù)棧。大部分的項目都會采用 Java 進行開發(fā)，主要是因為 Java 比較成熟，有很多成熟的技術(shù)框架可以直接使用，同時也有很多類似的代碼可以重用，也比較容易找到熟悉 Java 的技術(shù)人員。這樣開發(fā)的速度和效率會比較高，以及成本會比較低。

InfoQ：請介紹您的企業(yè)是否進行了微服務(wù)實踐？如果是，在整體系統(tǒng)架構(gòu)中的比例是多少？如果不是，是否有相關(guān)計劃？

阿里巴巴小馬哥：大多數(shù)應(yīng)用已實施微服務(wù)架構(gòu)，微服務(wù)應(yīng)用的比重達 80% 以上。

騰訊單致豪：早在 2008 年以前，騰訊已經(jīng)開始實踐“大系統(tǒng)小做”的海量服務(wù)之道理念，大量的服務(wù)已經(jīng)是遵循微服務(wù)理念開發(fā)。因為騰訊要支持快速迭代和敏捷研發(fā)，所以微服務(wù)比例占比在 95% 以上。核心業(yè)務(wù)模塊因為要支持海量用戶的巨大流量，100% 都是微服務(wù)。騰訊內(nèi)部使用 TARS 開發(fā)的微服務(wù)已經(jīng)超數(shù)十萬個節(jié)點，在規(guī)模上來看，是全球最大的微服務(wù)集群之一。

美團吳革：美團在 2015 年開始微服務(wù)架構(gòu)演進，核心系統(tǒng)已經(jīng) 100% 微服務(wù)化。

紅帽陳楚暉：已經(jīng)進行了微服務(wù)實踐，在整體系統(tǒng)架構(gòu)中占比不超過 30%。

華為田曉亮：華為云的所有服務(wù)都采用微服務(wù)架構(gòu)，但并非所有服務(wù)都用了某種微服務(wù)解決方案——比如 ServiceComb，Istio 或者 Spring cloud，各服務(wù)主要是自行實踐微服務(wù)設(shè)計模式。但幾乎所有應(yīng)用服務(wù)都采用了華為云容器服務(wù) CCE(Cloud Container Engine) 的 kubernetes 集群。

InfoQ：您所采用的主要微服務(wù)框架是什么？如何判斷國內(nèi)該領(lǐng)域的技術(shù)發(fā)展情況？您認為微服務(wù)主流框架的爭奪是否塵埃落定？

阿里巴巴小馬哥：2015 年初開始，阿里巴巴集團的應(yīng)用架構(gòu)逐漸由 SOA 衍生至微服務(wù)，所使用的微服務(wù)框架主要以 Spring Boot / Spring Cloud 和 Apache Dubbo（HSF）為主，涵蓋所有 Java 中間件核心基礎(chǔ)設(shè)施、九成以上的內(nèi)部系統(tǒng)，以及阿里云商戶應(yīng)用等。

同時，基于 Spring Cloud API，阿里巴巴衍生并開源出一套全新的微服務(wù)框架 - Spring Cloud Alibaba，并且正走向下一代 “云原生” 架構(gòu)，越來越多的應(yīng)用開始嘗試 Serverless 以及 Service Mesh 等前沿技術(shù)。相信未來微服務(wù)在不同語言和平臺上將會提供更多的選擇，至于那時誰是王者或主流框架，這個問題的答案已經(jīng)不再重要。

騰訊單致豪：不同的微服務(wù)主流框架可以滿足不用的應(yīng)用痛點，比如 SpringCloud、Dubbo 專注 Java 領(lǐng)域，TARS 則專注于多語言和高性能，充分發(fā)揮 C++ 的高性能、Go 的性能與高效兼顧、Java 的全能、Python 豐富基礎(chǔ)庫尤其是 AI 方面、Node.Js 和 PHP 便捷全面為 Web 而生等等優(yōu)勢。

目前中國和美國大廠開源的微服務(wù)框架（騰訊的 TARS、阿里的 Dubbo、百度的 brpc、谷歌的 gRPC、Facebook 的 Thrift、Pivotal 的 SpringCloud）基本能覆蓋所有用戶的痛點，企業(yè)直接從開源社區(qū)選型能解決自己痛點的開發(fā)框架即可。

美團吳革：主要采用自研 OCTO 和 Pigeon，現(xiàn)在正在開發(fā) Service Mesh 服務(wù)?，F(xiàn)在國內(nèi)主要是基于 Dubbo、Spring Cloud、Google gRPC 作為基礎(chǔ)進行二次封裝，主流框架選型已經(jīng)相對成熟。

紅帽陳楚暉：主要采用 Spring Cloud 的微服務(wù)框架，也對 Service Mesh（Istio）有研究。由于現(xiàn)有的微服務(wù)框架需要開發(fā)人員過多的介入，需要有大量的開發(fā)，所以目前大家比較看好 Istio。但是由于 Istio 還不夠成熟，因此大家都還處于預(yù)研階段。

華為田曉亮：華為許多的云服務(wù)和內(nèi)部項目采用了 ServiceComb 的微服務(wù)解決方案，比如消費者云，在全世界運行著數(shù)千微服務(wù)實例來為手機用戶提供服務(wù)。此外，華為云的音視頻服務(wù)也運行著數(shù)千的微服務(wù)實例，來提供視頻通話、音視頻解碼等服務(wù)。并且我們也向社區(qū)（通過 ServiceComb）和商業(yè)用戶（通過 ServiceStage）提供解決方案。

InfoQ：您如何看待 Service Mesh 在國內(nèi)的發(fā)展現(xiàn)狀和發(fā)展前景？

阿里巴巴小馬哥：個?對 Service Mesh 的看法是樂觀偏謹慎的，一??，作為從業(yè)人員，對于技術(shù)總有獵奇的心態(tài)。另外一??，這個技術(shù)在設(shè)計上存在一些理想主義，比如，性能損耗以及穩(wěn)定性，并且分布式場景中的典型問題并沒有得到解決和改善，比如數(shù)據(jù)一致性、分布式事務(wù)等。據(jù)我所知，國內(nèi)不少的互聯(lián)?公司，如阿?巴巴、螞蟻?服以及美團等已經(jīng)開始在生產(chǎn)環(huán)境試點 Service Mesh，聽起來這是一件好事。前沿的技術(shù)總需要有?去探險，如果成功，前人栽樹，后人乘涼。至于它能否成功，主要看市場是否愿意買單。

美團吳革：未來 Service Mesh 會在跨語言場景下大放異彩。Service Mesh 主要是基于云平臺和多技術(shù)棧場景下的痛點進行的開發(fā)，短時間內(nèi)不會有爆發(fā)性的增長。但是基于原生云架構(gòu)系統(tǒng)的增多，未來 Service Mesh 會不斷演進，最終變?yōu)樵圃軜?gòu)下的網(wǎng)絡(luò)基礎(chǔ)服務(wù)。

騰訊單致豪：Service Mesh 目前還處在早期發(fā)展階段，其理念設(shè)計已經(jīng)決定了性能及維護性上會是它最突出的短板。但有部分企業(yè)包括騰訊已經(jīng)嘗鮮，也有小量周邊不重要非核心業(yè)務(wù)在上面跑。Service Mesh 有著優(yōu)美的架構(gòu)理念，但性能確實讓人擔(dān)憂，社區(qū)生態(tài)也至少需要三年以上的發(fā)展時間。

華為田曉亮：大環(huán)境來看，傳統(tǒng)企業(yè)面臨的挑戰(zhàn)依然是業(yè)務(wù)系統(tǒng)如何向微服務(wù)轉(zhuǎn)型，以構(gòu)建自己的業(yè)務(wù)平臺，在這其中微服務(wù)框架是一種手段。為了尋求更快速地微服務(wù)化，開發(fā)人員就會避免學(xué)習(xí)陡峭的開發(fā)框架，而轉(zhuǎn)向使用 Service Mesh。開發(fā)者將結(jié)合輕量的 SDK（例如對接監(jiān)控系統(tǒng)、配置管理、AI 平臺，而不是微服務(wù)框架）與 Service Mesh 來實現(xiàn)自己的業(yè)務(wù)系統(tǒng)，從繁重的架構(gòu)工作中解放出來。這個發(fā)展歷程在我看來大概需要 2-3 年的時間。

而且，在我看來，最終站上舞臺的并不是 Service Mesh，而是底層由 Service Mesh 提供支持的 Serverless 平臺，用戶感知不到 Service Mesh 技術(shù)的復(fù)雜性，否則將面臨比開發(fā)框架更繁重的基礎(chǔ)設(shè)施運維挑戰(zhàn)。所以 Service Mesh 其實和 Serverless 的發(fā)展是綁定在一起的。Serverless 的普及和使用必然會幫助 Service Mesh 進行發(fā)展。

InfoQ：對于當(dāng)前 Java 的整體發(fā)展情況，您有什么感想？

楊曉峰：在可預(yù)見的將來，Java 依舊是企業(yè)軟件、大數(shù)據(jù)、電商等等最核心的技術(shù)棧。但是目前 Java/JVM 能力在云時代有一定局限性，比如云里強調(diào)的無服務(wù)器、微服務(wù)等場景，Java/JVM 都有一定短板。另外 Java 新版本采用速度這么慢，本身就說明，Java 創(chuàng)新和實際需求存在某種程度的脫節(jié)——一方面大量創(chuàng)新會帶來兼容性和版本混亂的問題；另外創(chuàng)新帶來的優(yōu)點卻需要極大增大開發(fā)運維成本，這也讓部分創(chuàng)新的價值被抵消了。但是 Java 會被取代嗎？應(yīng)該也不會，目前在社區(qū)、工具、類庫等等方面，Java 還沒有真正意義的對手，但是最大的威脅是新的需求浪潮是否與你有關(guān)。我們可以看下 GitHub 上 Java 新項目的趨勢，一定程度上可以佐證 Java 堅實的基本面和不可忽視的隱憂。

阿里巴巴李三紅：從技術(shù)角度來看，Java（JDK）這二十幾年的發(fā)展一直試圖在 Productivity 以及 Performance 之間做最好的平衡。Java 是靜態(tài)類型語言，但是為了生產(chǎn)效率提供了大量動態(tài)的特性比如 Bytecode Instrument、Dynamic Class Loading、Metaprogramming(Annotation、Reflection 等，這些形成了 Java 在運維、生產(chǎn)監(jiān)控等領(lǐng)域的基石技術(shù)。同時由于 Java 大量的動態(tài)特性存在，使得它在面向云原生、Serverless 計算時 Memory Footprint、Startup 方面被人所詬病。這也是整個 Java 社區(qū)，當(dāng)然包括 Alibaba Dragonwell 所試圖解決的問題。

阿里巴巴小馬哥：Java 目前仍具在編程語言排?榜上奪魁的能力，不過在整體比重上微幅下滑。個?看來，未來這個趨勢還將持續(xù)。究其原因，一??是由于新語種出現(xiàn)的中短期效應(yīng)，一方面是 Java 的編程復(fù)雜度并沒有明顯的降低，比如 I/O 處理、并發(fā) / 并?計算，以及類加載等等。再者是 Java 與操作系統(tǒng)之間的交互仍不夠充分，盡管 Java 9 開始提供了不少的 API，然?了解和使用的群體不?。Java 在這方面明顯不及 GO 語言。

從語?層?來看，Java 正在向主流非 Java 語?融合，解決其中鴻溝的關(guān)鍵是語法的變化，比如 Java 8 的 Lambda 表達式和 Java 10 的局部變量類型（ var ）等。個人認為這是一件好事，未來前后端不分家，相互滲透，對于彼此語言都是良性發(fā)展。

除此之外，個人比較期待的是 GraalVM 對 Java 的改變，傳統(tǒng) Java 應(yīng)用必須依賴 JVM 進程加載字節(jié)碼后解釋執(zhí)行，無法保證所有的代碼能夠在運行期編程完成，不免有運?時編譯所帶來的性能開銷，從而影響 JVM 的啟停時間。簡單地說，這種方式不夠 Native，對于云原生或許不夠友好。如果未來 GraalVM 的社區(qū)版也能夠像 OpenJDK 那般“親民”，那么，Java 的變化將是顛覆性的。

美團吳革：當(dāng)前 Java 已經(jīng)發(fā)展成為一個龐然大物，語言上基本不會有太多突破，更多是借鑒和兼容。隨著 GC 算法的升級和編譯器換代，面對 Go 等新一代語言挑戰(zhàn)，還有一戰(zhàn)之力。

騰訊單致豪：毋庸置疑，Java 語言依然活力十足，但在某些方面已經(jīng)失去優(yōu)勢，如云原生領(lǐng)域現(xiàn)在出現(xiàn)了更具活力的 Go 語言。紛繁的世界必定會出現(xiàn)多語言并存、不斷替代的現(xiàn)象?；仡櫄v史發(fā)展進程，一種語言要從出現(xiàn)到早期大眾使用基本都需要十年時間，能歷經(jīng)十年磨礪生存下來的開發(fā)語言，必定是有很強的生命力，而且都會有不同的企業(yè)構(gòu)筑其生態(tài)。正如上文所說：不同語言也會在自己優(yōu)勢之處持續(xù)發(fā)展，形成很強的競爭壁壘。

字節(jié)跳動王石沖：Scala 語言目前有兩個大的目標運行平臺——JVM 和 js，所以 Scala 作為一個語言和生態(tài)并不敢完全投資在單一目標平臺上。雖然 JVM 本身在不斷進步，但是 Java 已經(jīng)被同平臺的多種語言趕超，比如 Kotlin、Clojure、Groovy。

報告參與者介紹

楊曉峰，Java 技術(shù)專家，OpenJDK Committer。李三紅，阿里云智能資深技術(shù)專家，2014 年加入螞蟻金服，現(xiàn)為阿里 / 螞蟻 Java 技術(shù)負責(zé)人，有超過 10 年的 Java 開發(fā)經(jīng)驗?；钴S于 Java 技術(shù)社區(qū)，在 Java 虛擬機領(lǐng)域擁有多項技術(shù)專利。小馬哥（@mercyblitz），《Spring Boot 編程思想》作者、Apache Dubbo PMC 和 Spring-Cloud-Alibaba Architect。田曉亮，華為云 ServiceStage 首席工程師和 Apache ServiceComb PMC，7 年云計算領(lǐng)域工作經(jīng)驗，在 PaaS，混合云，DevOps，微服務(wù)，APM 方面有多年的實踐經(jīng)驗。單致豪，騰訊技術(shù)委員會和騰訊開源辦公室成員，負責(zé)微服務(wù)框架 TARS 的開源生態(tài)，并將項目捐贈 Linux 基金會。云原生產(chǎn)業(yè)聯(lián)盟專家顧問，DevOps 標準專家，GOPS 大會主席團。吳革，美團點評高級技術(shù)專家，現(xiàn)在主要負責(zé)美團點評小象事業(yè)部系統(tǒng)架構(gòu)工作。陳楚暉，紅帽 AppDev 首席架構(gòu)師，開源技術(shù)專家，熟悉多種開源中間件，長期就職于國際知名軟件公司，二十年中間件工作經(jīng)驗，擁有豐富的電信運營商、政府企業(yè)、金融等行業(yè)的系統(tǒng)集成、IT 項目管理經(jīng)驗，具有豐富的一線實踐經(jīng)驗。王石沖，字節(jié)跳動大數(shù)據(jù)工程師，Scala 程序員。譯著有《反應(yīng)式設(shè)計模式》。主要專注于基于 Scala 構(gòu)建的反應(yīng)式架構(gòu)以及相關(guān)應(yīng)用的實現(xiàn)。之前在從事中小型企業(yè)的實時數(shù)據(jù)流分析系統(tǒng)的開發(fā)。第四屆阿里中間件性能大賽優(yōu)勝獎，第一屆阿里云 PolarDB 性能大賽季軍。張濤，網(wǎng)名 kymjs，Android 技術(shù)專家，“開源實驗室”博主，Kotlin 技術(shù)推廣者，四年前開始接觸和使用 Kotlin 語言。帶過團隊，做過架構(gòu)，寫過應(yīng)用，做過開源社區(qū)。曾先后在滬江、餓了么、攜程工作，目前在一條生活館負責(zé)移動開發(fā)管理工作。黃飛，小米互聯(lián)網(wǎng)商業(yè)部技術(shù)主管，在互聯(lián)網(wǎng)商業(yè)化變現(xiàn)方面有豐富經(jīng)驗，負責(zé)小米互聯(lián)網(wǎng)廣告業(yè)務(wù)引擎與算法架構(gòu)工程研發(fā)，在高并發(fā)分布式推薦系統(tǒng)有多年的實踐經(jīng)驗。特別感謝：感謝楊曉峰老師參與此次報告的前期策劃，并在報告撰寫過程中給予專業(yè)的建議和指導(dǎo)。