作者 | 張曉楠

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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”

標籤：其他

上一篇：Docker-核心筆記(含Dockerfile,Compose)

下一篇：Rancher與ARM深化戰略合作，“軟硬結合”加速邊緣計算時代