多是國內第一篇全面解讀 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 九、10 則成了過渡版本（non‑LTS），所以，陳楚暉不建議用戶在生產中使用 Java 九、10。在他看來，小版本升級相對風險是比較小的，而大版本變動則會有可能須要更改大量的代碼，這也是爲何這麼多人還在堅持用 Java8，而不去更新 Java 十一、十二、或者 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 語言。帶過團隊，作過架構，寫過應用，作過開源社區。曾前後在滬江、餓了麼、攜程工做，目前在一條生活館負責移動開發管理工做。
黃飛，小米互聯網商業部技術主管，在互聯網商業化變現方面有豐富經驗，負責小米互聯網廣告業務引擎與算法架構工程研發，在高併發分佈式推薦系統有多年的實踐經驗。
特別感謝：感謝楊曉峯老師參與這次報告的前期策劃，並在報告撰寫過程當中給予專業的建議和指導。

 

 

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。