可能是國内第一篇全面解讀 Java 現狀及趨勢的文章

作者 | 張曉楠 Dragonwell JDK 最新版本 8.1.1-GA 釋出，包括全新特性和更新！

導讀：InfoQ 釋出《2019 中國 Java 發展趨勢報告》，反映 Java 在中國發展的獨特性，同時也希望大家對 Java 有一個正确的認識。

2 個月前，InfoQ 英文站釋出了一份

《2019 Java 發展趨勢報告》

，從技術采用生命周期的角度，分析了 Java 這門 20 多年曆史語言的發展現狀。這份報告釋出後，發生了幾個我們沒想到的問題：一是有些開發者對 Java 産生了深深的懷疑，有人表示“現在還值得深入研究 Java 嗎？”，有人表示“Java 已經落後别的語言好多年”；二是有人覺得這份報告不接地氣，沒有呈現出 Java 在中國的發展情況。

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

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

參與本次趨勢報告的專家

• 楊曉峰，Java 技術專家，OpenJDK Committer
• 李三紅，阿裡 / 螞蟻 Java 技術負責人，阿裡雲智能資深技術專家
• 小馬哥，阿裡巴巴 Apache Dubbo PMC 和 Spring-Cloud-Alibaba Architect
• 田曉亮，華為雲 ServiceStage 首席工程師和 Apache ServiceComb PMC
• 單緻豪，騰訊 TARS 開源項目負責人
• 吳革，美團點評進階技術專家
• 陳楚晖，紅帽 AppDev 首席架構師，開源技術專家
• 王石沖，位元組跳動大資料工程師、Scala 程式員
• 張濤，Kotlin 專家，Android 技術專家，開源實驗室部落客
• 黃飛，小米網際網路商業部技術主管

Java 技術采用生命周期概覽

這張中國 Java 技術采用生命周期概覽圖是本次趨勢報告的精華，結論來自于各位專家的判斷。某些方面專家們觀點出奇的一緻，當然也有很多部分專家觀點并不相同。可謂是金句頻現、火花四濺。

技術采用生命周期劃分方式

• 創新者
• 早期采用者
• 早期大衆
• 晚期大衆

技術采用生命周期是美國高科技營銷大師傑弗裡·摩爾在自己的書《跨越鴻溝》裡提出的概念。技術采用生命周期是一個用來衡量使用者對某項新技術接受程度的模型，它認為一個新的技術，從一開始出現到最後走向成熟，必然會經曆創新者、早期采用者、早期大衆、晚期大衆的階段。

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

重要結論

1. Java 13 處于創新者階段，Java 11 處于早期采用者階段，Java 8 處于晚期大衆階段。

• Java 11 将是未來 Java 使用者的最可能選項；
• 如果一個公司對大堆棧 GC 能力、延遲 SLA 等方面要求沒有那麼高，就沒有足夠動力去做相關更新，也未必有技術力量解決版本評估、相容性修正等現實問題；
• Java 新版本更新在中國的宣傳還是不夠，如果很多企業看不到技術更新的紅利，勢必也影響更新的積極性。

2. OpenJDK 處于創新者階段。

• 雖然國内很多頭部廠商都在定制 OpenJDK，但是目前定制 OpenJDK 被采用範圍還都有限，主體使用還是 Oracle JDK（根據《JVM 生态系統報告 2018》調查顯示，70% 的開發者選擇使用 Oracle JDK，21% 的開發者選擇使用 OpenJDK）；

• 廠商是否轉向 OpenJDK，還有一個重要考量因素就是看他們是否願意付費使用 OracleJDK，如果不是的話，未來 OpenJDK 可能會逐漸取代 Oracle JDK，目前國内頭部廠商都在 OpenJDK 上有所動作；

  （對于參與 OpenJDK 的國内頭部廠商來說，可能他們的看法更加積極，他們把 OpenJDK 定義在早期大衆階段）

• 大家在公有雲、私有雲等方面的競争格局，深刻影響着在 OpenJDK 上的競争格局；
• OpenJDK 很可能被認為是一種退⽽求其次的選擇。

3. 非 Hotspot JDK 生産實踐——Graal VM、IBM OpenJ9 處于早期采用者階段。

• Graal VM 目前還尚不可知其相容性情況以及明确的商業化條款；
• Graal VM 的部分技術，例如，基于 Java 語言開發的 JIT 引擎，可能會成為未來 OpenJDK 的基礎技術；
• 在國内，懷疑 Graal VM、IBM OpenJ9 進入普遍生産實踐的可能性會比較低。

4. Lambda /Stream 處于晚期大衆階段、Vector API 處于創新者階段。

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

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

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

6. 微服務架構：Spring Boot 和 Spring Cloud 進入晚期大衆階段；ServiceComb 處于早期采用者階段；Apache Dubbo 處于晚期大衆階段；Tars 處于早期大衆階段。

• 微服務技術處于早期大衆與晚期大衆之間，新的微服務開發架構需要技術突破和創新，不然已經難有一席之地；
• Java 不再是微服務唯一的選擇；
• 在技術多元化的今天，支援多語言的微服務開發架構是個必須品。

技術采用生命周期解讀

在上一章節我們已經先把各位專家的觀點和結論抛了出來，但是結論背後還需要很關鍵的原因解讀，是以這一章節就按照 Java/JVM、不同層次的主流架構、微服務這三個部分，來逐一呈現。

Java/JVM

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

在 InfoQ 面向開發者的 Java 使用版本調查中，毫無懸念，在參與問卷調研的開發者中，88.7% 正在使用 Java8 版本，這些人當中隻有 35% 有更新計劃，剩餘 65% 并沒有更新計劃。

楊曉峰認為這一情況也正常：Java8 在可預見的将來依然會是生産的主體，放在晚期大衆階段是合理的。但是對于很多頭部廠商來說，Java11 或者再後續版本，有可能陸續出現一定規模的生産化部署。他認為這樣的趨勢隻會在頭部公司發生，如果一個公司對大堆棧 GC 能力、延遲 SLA 等方面要求沒有那麼高，就沒有足夠動力去做相關更新，也未必有技術力量解決版本評估、相容性修正等現實問題。是以結論就是：Java11 處于早期采用者階段。

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

而對于 Java 13，小馬哥認為該版本在新 GC 算法的提升以及 Socket 實作上的變化還是非常令⼈期待的，是以 Java 13 排在創新者之列。

對于 Java 的更新，Oracle 宣布從 Java 9 開始每半年将更新一個 Java 大版本——Java 11 是長期支援（Long-Term -Support, LTS）版本，Java 9、10 則成了過渡版本（non‑LTS），是以，陳楚晖不建議使用者在生産中使用 Java 9、10。在他看來，小版本更新相對風險是比較小的，而大版本變更則會有可能需要更改大量的代碼，這也是為什麼這麼多人還在堅持用 Java8，而不去更新 Java 11、12、或者 13 的原因。

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

• 靈活的基礎底層架構對軟體更新的支援，企業對底層架構的重視程度也是 Java 更新的一個很關鍵原因。中國的企業業務發展都很快，但是其實很多對底層架構的支援和重視是不足夠的。底層架構是否在企業内部被統一強管控，是否很容易支援不同軟體版本的灰階，并能通過有效的預發測試，覆寫軟體更新不相容等帶來的不确定性，這都考驗着軟體更新的難度。

• 另外一點，如果企業享受不到技術更新帶來的紅利，包括性能、程式設計效率等多方面提升，勢必也影響更新的積極性。

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

OpenJDK 定制版或者公開發行版

由于 Oracle 宣布 2019 年伊始，Oracle JDK 8 以及更⾼版本在伺服器端部署不再免費，是以 OpenJDK 就成為了大多數 Java 使用者的選項。根據《JVM 生态系統報告 2018》調查顯示，70% 的開發者選擇使用 Oracle JDK，21% 的開發者選擇使用 OpenJDK。

陳楚晖也介紹了國内的情況：目前國内開發者使用最多的依舊是 Oracle JDK，其次是 IBM JDK，也有部分企業采用 OpenJDK。報告連結：

https://snyk.io/blog/jvm-ecosystem-report-2018/

對于 OpenJDK 的技術采用生命周期劃分，專家們有一些觀點上的不一緻，楊曉峰認為雖然國内很多頭部廠商都在定制 OpenJDK，但是目前定制 OpenJDK 被采用範圍還都有限，這也跟上文資料結果吻合，是以他會把 OpenJDK 歸在創新者階段。

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

據來自美團的吳革介紹：美團現階段正在測試基于 OpenJDK 的 MtJDK，作為美團 JDK 基礎服務。此外，美團主要會關注 Redhat 和 Amazon 的更新。由于 Azul 沒有公開 OpenJDK 源代碼，是以美團沒有基于 Azul 進行研發。

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

從現有的 OpenJDK 陣營來看，目前分為兩類，一類是 IT 和雲廠商，他們對外提供釋出、銷售的 OpenJDK 版本——Amazon、Redhat、Azul 、阿裡巴巴、騰訊都在自己生産（除了微軟分發 Azul）；另外就是技術上的強需求導緻自身有定制 OpenJDK 的公司，他們的 OpenJDK 産品較難突破内部使用的範圍，比如我們采訪調研的美團、小米。

對于這樣的一個陣營劃分，楊曉峰有一個觀點：從 OpenJDK 釋出版的競争格局來看，最終會演變為雲的格局，堅持下來的會是頭部雲廠商或與其合作的軟體廠商。換句話說大家在公有雲、私有雲等方面的競争格局，深刻影響着在 OpenJDK 上的競争格局。畢竟對于企業來說，做 OpenJDK 也需要有利可圖，沒有廣泛的使用者群體和對等的收益，很難支撐基礎軟體的長期演進。

我們把以上觀點抛給了此次調研采訪對象——IT 公司和雲廠商陣營的代表李三紅，在他看來：在 Java 收費的情況下，OpenJDK 一定是大勢所趨，Java 會越來越開放，深度參與 OpenJDK 也是為了通過社群驅動 Java 往前走；另外，在目前企業上雲的大趨勢下，如果客戶的現有系統是用 Java 寫的，雲廠商在為客戶提供服務的時候勢必要考慮如何讓 Java 生态變得更好，這也是符合客戶的訴求。

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

非 Hotspot JDK 生産實踐——Graal VM、IBM OpenJ9

Graal VM 被列為早期采用者階段，對此李三紅表示：Graal VM 已經在 Oracle Cloud 生産環境大規模使用，TCK 相容。值得一提的是，Graal VM 下的靜态編譯 SVM 造成了 Java 語言一些方面的不相容， 這個也是整個社群擔心的地方。如何讓 SVM/ 靜态編譯能納入到 Java Language/JVM Specification 裡來？值得關注。

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

是以對于國内普通企業使用者來說，沒有單獨關注的價值。未來更加現實的技術采用路徑是，使用者使用內建了 Graal VM 先進技術的 OpenJDK 主分支。同樣，IBM OpenJ9 有很多獨到的技術，如果能夠合并入 OpenJDK 主分支，更能創造普遍的生産價值，否則難免會被局限在 IBM 中間件等使用者群内部。另外，訂閱 Graal VM 服務的具體資訊可能在今年 Code One 會有說明，大家有興趣可以關注。

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

對于 Lambda /Stream 等文法與特性，采訪調研專家認為應該歸類在晚期大衆階段。小馬哥認為這些文法與特性在開發人員的⽇常⼯作中⼴泛地運用，并且沒有看到文法回退的趨勢。吳革表示：在美團内部，目前已經大量使用 Lambda 和 Stream 表達式。

而對于 Vector API 等前沿版本特性，楊曉峰認為還隻在個别頭部公司處于原型階段，應該被歸在創新者階段。

Kotlin、Scala

對于 Kotlin 和 Scala，我們也采訪調研了兩位 Kotlin 和 Scala 領域的專家。

在今年 5 月份的 Google I/O 大會上，Google 官方正式宣布：Kotlin 是 Android 應用程式開發人員的首選語言。這是否意味着 Java 占據 Android 開發絕對統治的時代一去不複返了？

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

張濤認為 ：Kotlin 在國内應該處于早期大衆向晚期大衆過渡階段，在未來一兩年内，會有大部分的 JVM 平台開發者開始使用 Kotlin。

在 2017 年年底，張濤曾經做過一次調查，邀請将近 1000 名 Android 開發者，了解他們的項目中是否使用了 Kotlin。當時的結果是 30% 的人使用過 Kotlin，60% 的人聽說過 Kotlin， 還有 80 多人沒有聽說過。他相信目前國内的 Android 應用應該 90% 都包含有 Kotlin 代碼。

此前 InfoQ 曾對位元組跳動大資料工程師、Scala 程式員王石沖以及另外幾位來自 Scala 社群的專家進行過一次訪談，了解 Scala 在國内的發展情況。對于有人認為的 Scala 難成主流的說法，王石沖表示：Scala 為什麼非要成為主流呢？它在自己适合的領域做王者就夠了，主流不主流其實并不是那麼重要。

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

成名的例子就有 Twitter、LinkedIn、Verizon 等。金融行業則有摩根士丹利、渣打等（但是他們作為悶聲發大财的典型，很少對外宣傳自己的技術選型）。而很多矽谷的初創團隊早期為了快速開發，也是采用的 Scala。在國内，除了小米、阿裡和騰訊的部分團隊以及類似于 GrowingIO、水滴這樣的初創公司和一些廣告公司外，大部分開發者都是應用 Scala 來做 Spark 開發。因為沒有典型的、具有号召力的大公司主導，是以 Scala 在社群方面做得也一般。

Spring Boot/Cloud、Apache Dubbo、TARS、ServiceComb 等微服務架構

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

田曉亮表示：Spring Cloud 社群依然在蓬勃發展，也開始為雲廠商創造商業機會，如何與 Spring Cloud 結合，成為了雲廠商要解決的關鍵問題之一。

雖然越來越多的企業選擇了 ServiceComb 進行微服務轉型，并獲得了成功，但并未普及到早期大衆階段。ServiceComb 中微服務架構與 Service Mesh 可以融合使用，讓使用者有了靈活的選擇。

Java 依然是最流行的語言，但企業也終于能夠選擇其他語言進行微服務開發了。同時提供 Spring Cloud 的元件可以使其接入到 ServiceComb 中，幫助 Spring Cloud 使用者平滑向多語言轉型，Java 不再是微服務唯一的選擇。

Apache Dubbo 一開始并不叫這個名字，Dubbo 一開始隻是阿裡内部的一個系統，2010 年 Dubbo 項目進行重構，2018 年初，Dubbo 項目正式進入 Apache 孵化器。在小馬哥看來，Apache Dubbo 屬于晚期大衆階段，不過最新的 Apache Dubbo ECO System（生态系統）則是一個基于 Apache Dubbo 衍進的 Cloud Native 解決方案，目前尚未枝葉茂盛，處于創新者陣營。

對于 Apache Dubbo，黃飛表示：它在 RPC 中間件這個領域可以算得上引領者之一。Apache Dubbo 的服務注冊與發現、服務治理相對完善，支援灰階釋出，智能的負載均衡政策、可視化的服務治理與運維工具便于開發人員上手。可以說 Dubbo/Dubbox 在 RPC 架構 / 微服務領域已經展露頭腳甚至在某些方面已經形成優勢。

TARS 在騰訊内部叫 TAF(Tencent Application Framework)，是騰訊應用産品最多、最廣泛的微服務開發架構，并且已經在騰訊大規模應用了超過十年。2017 年中旬，騰訊正式将 TARS 開源，開源後一年便成為 Linux 基金會開源項目。由于相對其他微服務項目開源晚，錯過了很多社群發展紅利。

對于 TARS，據單緻豪介紹，不同的微服務主流架構可以滿足不同的應用痛點，TARS 則原生專注多語言和高性能。他認為 TARS 已經有大型網際網路公司廣泛使用，已經從早期采用者階段邁過了鴻溝，進入了早期大衆階段。

Java 應用實踐

InfoQ：您的企業使用的 JDK 版本情況，是否采用了某個 OpenJDK 發行版？您如何看待 OpenJDK 在國内的發展？（如果沒有采用，原因以及後續計劃？）

阿裡巴巴李三紅：目前阿裡巴巴大部分的應用運作在 Dragonwell  8，有些已經運作在了 Dragonwell 11， 我們正在逐漸推動從 Java8 到 Java11 的更新，充分享受技術紅利。

美團吳革：美團現階段主要使用 Java8，很少一部分是 Java7。部分核心團隊正在嘗試 Java 11。在美團内部采用的開發版本 JDK 主要還是 Oracle JDK。我們在伺服器上的 JDK 版本主要是美團自己的 MtJDK 和 Oracle JDK。美團現階段正在測試基于 OpenJDK 的 MtJDK，作為美團 JDK 基礎服務。

MtJDK 主要基于 OpenJDK 建構，現階段主要針對更新檔和安全性進行維護。現階段在特定業務線内部進行測試和應用。未來配合 Serverless 等基礎服務更新，MtJDK 會在 JDK 啟動性能和增強應用之間的隔離進行深度定制。

小米黃飛：小米主要使用 OpenJDK8 以及 11 版本。目前對 OpenJDK 主要還是以使用為主，主要的業務關注點在于這個版本是否為長期支援；是否有更加高效易用的特征，例如 GC 算法由 CMS、G1 更新到 ZGC 等；開源社群是否活躍；以及對遇到的問題是否有足夠豐富的資料與讨論等。

Java 作為使用最為廣泛的語言，最近幾年還是有比較大進步的，無論從文法的易用性上還是性能上都有很大程度的提升。吸收了函數式程式設計的思想，lambda 表達式、Parallem stream、Var 變量等提升了開發人員的效率與代碼的簡潔性。ZGC 無疑是一項重大的改進，在一定程度上解決了 Java 天生的 GC 問題。

InfoQ：您的企業目前在支援 Java 技術棧方面的政策是什麼？計劃和目标是什麼？相關的核心痛點或者業務需求是什麼？

騰訊單緻豪：騰訊内部占上司地位的開發者是 C++，同時有大量的 Node.Js、Golang、Java、PHP、Python 開發者，當然也有少量的 Rust、C# 的開發者。我們在海量使用者的後端大部分采用 C++ 和 Golang，Java 在前端和大資料方面有廣泛使用，在對外 ToB 的傳遞中也大量采用。

由于騰訊的開發者使用了多種開發語言，而且不同開發語言在不同領域有不同優勢，是以目前要解決的問題是多語言開發的服務互通問題，一套支援多語言的微服務開發架構是必需品，TARS 也是在這樣的多語言背景下誕生。

美團吳革：美團的 Java 技術棧政策偏向穩定，在穩定的基礎之上推動技術更新。Java 核心痛點就是依賴更新，當一個 jar 包更新，必須一個服務一個服務更新，不能自動化整體更新，是以對于美團來說，正在解決相關依賴更新的問題。

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

InfoQ：請介紹您的企業是否進行了微服務實踐？如果是，在整體系統架構中的比例是多少？如果不是，是否有相關計劃？

阿裡巴巴小馬哥：大多數應用已實施微服務架構，微服務應用的比重達 80% 以上。

騰訊單緻豪：早在 2008 年以前，騰訊已經開始實踐“大系統小做”的海量服務之道理念，大量的服務已經是遵循微服務理念開發。因為騰訊要支援快速疊代和靈活研發，是以微服務比例占比在 95% 以上。核心業務子產品因為要支援海量使用者的巨大流量，100% 都是微服務。騰訊内部使用 TARS 開發的微服務已經超數十萬個節點，在規模上來看，是全球最大的微服務叢集之一。

美團吳革：美團在 2015 年開始微服務架構演進，核心系統已經 100% 微服務化。

紅帽陳楚晖：已經進行了微服務實踐，在整體系統架構中占比不超過 30%。

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

InfoQ：您所采用的主要微服務架構是什麼？如何判斷國内該領域的技術發展情況？您認為微服務主流架構的争奪是否塵埃落定？

阿裡巴巴小馬哥：2015 年初開始，阿裡巴巴集團的應用架構逐漸由 SOA 衍生至微服務，所使用的微服務架構主要以 Spring Boot / Spring Cloud 和 Apache Dubbo（HSF）為主，涵蓋所有 Java 中間件核心基礎設施、九成以上的内部系統，以及阿裡雲商戶應用等。

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

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

目前中國和美國大廠開源的微服務架構（騰訊的 TARS、阿裡的 Dubbo、百度的 brpc、谷歌的 gRPC、Facebook 的 Thrift、Pivotal 的 SpringCloud）基本能覆寫所有使用者的痛點，企業直接從開源社群選型能解決自己痛點的開發架構即可。

美團吳革：主要采用自研 OCTO 和 Pigeon，現在正在開發 Service Mesh 服務。現在國内主要是基于 Dubbo、Spring Cloud、Google gRPC 作為基礎進行二次封裝，主流架構選型已經相對成熟。

紅帽陳楚晖：主要采用 Spring Cloud 的微服務架構，也對 Service Mesh（Istio）有研究。由于現有的微服務架構需要開發人員過多的介入，需要有大量的開發，是以目前大家比較看好 Istio。但是由于 Istio 還不夠成熟，是以大家都還處于預研階段。

華為田曉亮：華為許多的雲服務和内部項目采用了 ServiceComb 的微服務解決方案，比如消費者雲，在全世界運作着數千微服務執行個體來為手機使用者提供服務。此外，華為雲的音視訊服務也運作着數千的微服務執行個體，來提供視訊通話、音視訊解碼等服務。并且我們也向社群（通過 ServiceComb）和商業使用者（通過 ServiceStage）提供解決方案。

InfoQ：您如何看待 Service Mesh 在國内的發展現狀和發展前景？

阿裡巴巴小馬哥：個⼈對 Service Mesh 的看法是樂觀偏謹慎的，一⽅⾯，作為從業人員，對于技術總有獵奇的心态。另外一⽅⾯，這個技術在設計上存在一些理想主義，比如，性能損耗以及穩定性，并且分布式場景中的典型問題并沒有得到解決和改善，比如資料一緻性、分布式事務等。

據我所知，國内不少的互聯⽹公司，如阿⾥巴巴、螞蟻⾦服以及美團等已經開始在生産環境試點 Service Mesh，聽起來這是一件好事。前沿的技術總需要有⼈去探險，如果成功，前人栽樹，後人乘涼。至于它能否成功，主要看市場是否願意買單。

美團吳革：未來 Service Mesh 會在跨語言場景下大放異彩。Service Mesh 主要是基于雲平台和多技術棧場景下的痛點進行的開發，短時間内不會有爆發性的增長。但是基于原生雲架構系統的增多，未來 Service Mesh 會不斷演進，最終變為雲原生架構下的網絡基礎服務。

騰訊單緻豪：Service Mesh 目前還處在早期發展階段，其理念設計已經決定了性能及維護性上會是它最突出的短闆。但有部分企業包括騰訊已經嘗鮮，也有小量周邊不重要非核心業務在上面跑。Service Mesh 有着優美的架構理念，但性能确實讓人擔憂，社群生态也至少需要三年以上的發展時間。

華為田曉亮：大環境來看，傳統企業面臨的挑戰依然是業務系統如何向微服務轉型，以建構自己的業務平台，在這其中微服務架構是一種手段。為了尋求更快速地微服務化，開發人員就會避免學習陡峭的開發架構，而轉向使用 Service Mesh。開發者将結合輕量的 SDK（例如對接監控系統、配置管理、AI 平台，而不是微服務架構）與 Service Mesh 來實作自己的業務系統，從繁重的架構工作中解放出來。這個發展曆程在我看來大概需要 2-3 年的時間。

而且，在我看來，最終站上舞台的并不是 Service Mesh，而是底層由 Service Mesh 提供支援的 Serverless 平台，使用者感覺不到 Service Mesh 技術的複雜性，否則将面臨比開發架構更繁重的基礎設施運維挑戰。是以 Service Mesh 其實和 Serverless 的發展是綁定在一起的。Serverless 的普及和使用必然會幫助 Service Mesh 進行發展。

InfoQ：對于目前 Java 的整體發展情況，您有什麼感想？

楊曉峰：在可預見的将來，Java 依舊是企業軟體、大資料、電商等等最核心的技術棧。但是目前 Java/JVM 能力在雲時代有一定局限性，比如雲裡強調的無伺服器、微服務等場景，Java/JVM 都有一定短闆。

另外 Java 新版本采用速度這麼慢，本身就說明，Java 創新和實際需求存在某種程度的脫節——一方面大量創新會帶來相容性和版本混亂的問題；另外創新帶來的優點卻需要極大增大開發運維成本，這也讓部分創新的價值被抵消了。

但是 Java 會被取代嗎？應該也不會，目前在社群、工具、類庫等等方面，Java 還沒有真正意義的對手，但是最大的威脅是新的需求浪潮是否與你有關。我們可以看下 GitHub 上 Java 新項目的趨勢，一定程度上可以佐證 Java 堅實的基本面和不可忽視的隐憂。

阿裡巴巴李三紅：從技術角度來看，Java（JDK）這二十幾年的發展一直試圖在 Productivity 以及 Performance 之間做最好的平衡。Java 是靜态類型語言，但是為了生産效率提供了大量動态的特性比如 Bytecode Instrument、Dynamic Class Loading、Metaprogramming(Annotation、Reflection 等 ，這些形成了 Java 在運維、生産監控等領域的基石技術。

同時由于 Java 大量的動态特性存在，使得它在面向雲原生、Serverless 計算時 Memory Footprint、Startup 方面被人所诟病。這也是整個 Java 社群，當然包括 Alibaba Dragonwell 所試圖解決的問題。

阿裡巴巴小馬哥：Java 目前仍具在程式設計語言排⾏榜上奪魁的能力，不過在整體比重上微幅下滑。個⼈看來，未來這個趨勢還将持續。究其原因，一⽅⾯是由于新語種出現的中短期效應，一方面是 Java 的程式設計複雜度并沒有明顯的降低，比如 I/O 處理、并發 / 并⾏計算，以及類加載等等。再者是 Java 與作業系統之間的互動仍不夠充分，盡管 Java 9 開始提供了不少的 API，然⽽了解和使用的群體不⾜。Java 在這方面明顯不及 GO 語言。

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

除此之外，個人比較期待的是 GraalVM 對 Java 的改變，傳統 Java 應用必須依賴 JVM 程序加載位元組碼後解釋執行，無法保證所有的代碼能夠在運作期程式設計完成，不免有運⾏時編譯所帶來的性能開銷，進而影響 JVM 的啟停時間。簡單地說，這種方式不夠 Native，對于雲原生或許不夠友好。如果未來 GraalVM 的社群版也能夠像 OpenJDK 那般“親民”，那麼，Java 的變化将是颠覆性的。

美團吳革：目前 Java 已經發展成為一個龐然大物，語言上基本不會有太多突破，更多是借鑒和相容。随着 GC 算法的更新和編譯器換代，面對 Go 等新一代語言挑戰，還有一戰之力。

騰訊單緻豪：毋庸置疑，Java 語言依然活力十足，但在某些方面已經失去優勢，如雲原生領域現在出現了更具活力的 Go 語言。紛繁的世界必定會出現多語言并存、不斷替代的現象。回顧曆史發展程序，一種語言要從出現到早期大衆使用基本都需要十年時間，能曆經十年磨砺生存下來的開發語言，必定是有很強的生命力，而且都會有不同的企業構築其生态。正如上文所說：不同語言也會在自己優勢之處持續發展，形成很強的競争壁壘。

位元組跳動王石沖：Scala 語言目前有兩個大的目标運作平台——JVM 和 js，是以 Scala 作為一個語言和生态并不敢完全投資在單一目标平台上。雖然 JVM 本身在不斷進步，但是 Java 已經被同平台的多種語言趕超，比如 Kotlin、Clojure、Groovy。

報告參與者介紹

楊曉峰，Java 技術專家，OpenJDK Committer。

李三紅，阿裡雲智能資深技術專家，2014 年加入螞蟻金服，現為阿裡 / 螞蟻 Java 技術負責人，有超過 10 年的 Java 開發經驗。活躍于 Java 技術社群，在 Java 虛拟機領域擁有多項技術專利。

小馬哥（@mercyblitz），《Spring Boot 程式設計思想》作者、Apache Dubbo PMC 和 Spring-Cloud-Alibaba Architect。

田曉亮，華為雲 ServiceStage 首席工程師和 Apache ServiceComb PMC，7 年雲計算領域工作經驗，在 PaaS，混合雲，DevOps，微服務，APM 方面有多年的實踐經驗。

單緻豪，騰訊技術委員會和騰訊開源辦公室成員，負責微服務架構 TARS 的開源生态，并将項目捐贈 Linux 基金會。雲原生産業聯盟專家顧問，DevOps 标準專家，GOPS 大會主席團。

吳革，美團點評進階技術專家，現在主要負責美團點評小象事業部系統架構工作。

陳楚晖，紅帽 AppDev 首席架構師，開源技術專家，熟悉多種開源中間件，長期就職于國際知名軟體公司，二十年中間件工作經驗，擁有豐富的電信營運商、政府企業、金融等行業的系統內建、IT 項目管理經驗，具有豐富的一線實踐經驗。

王石沖，位元組跳動大資料工程師，Scala 程式員。譯著有《反應式設計模式》。主要專注于基于 Scala 建構的反應式架構以及相關應用的實作。之前在從事中小型企業的實時資料流分析系統的開發。第四屆阿裡中間件性能大賽優勝獎，第一屆阿裡雲 PolarDB 性能大賽季軍。

張濤，網名 kymjs，Android 技術專家，“開源實驗室”部落客，Kotlin 技術推廣者，四年前開始接觸和使用 Kotlin 語言。帶過團隊，做過架構，寫過應用，做過開源社群。曾先後在滬江、餓了麼、攜程工作，目前在一條生活館負責移動開發管理工作。

黃飛，小米網際網路商業部技術主管，在網際網路商業化變現方面有豐富經驗，負責小米網際網路廣告業務引擎與算法架構工程研發，在高并發分布式推薦系統有多年的實踐經驗。

特别感謝：感謝楊曉峰老師參與此次報告的前期策劃，并在報告撰寫過程中給予專業的建議和指導。

“ 阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”