可能是國內第一篇全面解讀 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”