Dubbo Roadmap與將來展望

前言

前幾每天看了劉軍關於《從 2019 到 2020，Apache Dubbo 年度總結與展望》線上直播，打算對此寫個觀後感。

首先介紹一下劉軍，他是Apache Dubbo PMC，項目核心維護者，見證了 Dubbo 從重啓開源到 Apache 畢業的整個流程。現任職阿里巴巴中間件團隊，參與服務框架、微服務相關工做，目前主要在推進 Dubbo 開源的雲原生化。

整個線上直播大概一個多小時，整體講了三個方面，分別是：

• Dubbo社區發展回顧
• 重要功能解析
• Roadmap與將來展望

重要功能解析主要是關於2.7.x的特性，這部份內容我會將每一塊分爲一個主題在後續的文章中一一介紹，本文大體介紹一下直播中講到的將來展望這部份內容。

Roadmap與將來展望

在將來規劃裏主要分爲四個發力點，分別是：

• 微服務相關功能的加強
• Dubbo 3.0 協議升級
• 服務自省
• 雲原生

微服務相關功能的加強

目前微服務相關功能正在作的有Dubbo的鑑權功能、內置熔斷能力以及 TLS，在2.7.5版本中已經集成來鑑權功能、鏈路的安全傳輸。涉及到業務開發的功能，dubbo在後續還會作進一步加強。

Dubbo 3.0 協議升級

在將來會針對Dubbo協議作全面升級，該升級主要涉及到如下幾個重要的方向：

• Reactive Stream的支持：前面提到的在協議層面對Reactive Stream的支持，以支持消費端的流式請求，服務端的流式響應或者雙向的流式通訊。
• HTTP/2的支持：由於在微服務雲原生場景下，基於 HTTP/2 構建的通訊協議具備更好的通用性和穿透性，因此在3.0協議上會對HTTP/2的支持。
• 跨語言的支持：針對跨語言的支持，更多的是序列化方面發力。
• 流量控制的支持：好比Reactive編程裏面的request (n)或者 HTTP/2 中提供的流控機制等。
• 協議升級：由於要考慮到老版本協議如何升級到新版本的協議，因此高版本的協議要提供必定的協議協商機制，相似於 HTTP/2 引入的協議協商機制，高版本的協議還要可以對低版本的協議有必定的包容。
• 可擴展性加強：主要是Header的metadata部分，須要區分協議擴展和RPC方法的擴展，由於dubbo原來的協議中attachments更多的是爲了支持方法的擴展，在新版本的協議中須要支持協議的擴展。
• Mesh：新版本的協議須要對mesh更友好，方便完成跟mesh的協做。
• 通用性強：協議設計上要兼顧通用性和性能，可在各類設備上運行。

服務自省

dubbo以前都是基於接口粒度，以後會規劃增長應用粒度的服務發現、治理以及選址，由於經過增長應用粒度的支持，能夠與主流微服務和雲原生模型對齊，而且解決接口帶來的性能問題。接下來應用粒度有幾個方面能夠發力：

• 以應用粒度註冊、註冊中心只關注地址變動。

• 元數據服務提供額外信息。

  • 接口列表、方法列表、方法簽名等;
  • 實例特有配置;

• 保持RPC編程風格不變

  • 繼續面向接口編程，無需額外改造
  • 僅經過Registry配置，區別新老服務發現模型;

雲原生

• 服務發現：dubbo的服務發現能力做爲sdk在之前的基礎設施上能夠正常工做，將來須要解決在Kubernetes的一些基礎設施上該如何工做，將來但願能夠複用這些基礎設施，基於容器調度的能力來複用底層的服務發現能力。
• 雲上、雲下互通：將來會考慮雲上雲下dubbo應用到互通。
• 平滑遷移：將來但願能將普通運用能夠平滑遷移到容器中。
• Talk to xDS：在mesh場景下，dubbo可能會考慮對具有xDS協議的標準式配置的下發能力的sdk的支持。
• 生命週期對齊：將來須要考慮的是dubbo的生命週期如何和容器相關的生命週期進行綁定。 服務治理機制適配：在k8s下，對pod的調度有一套本身的調度機制，它的ip是不停的變化，dubbo有不少治理規則都是強綁定ip的，這些並不適合雲原生的服務治理，因此在將來須要解決dubbo在服務治理機制上如何適配的問題。