Dubbo3.0 - 開啟下一代雲原生微服務

2021-02-13 阿里巴巴雲原生

作者 | 郭浩(項升)  阿里巴巴經濟體 RPC 框架負責人

導讀:本文整理自作者於 2020 年雲原生微服務大會上的分享《Dubbo3.0 - 開啟下一代雲原生微服務》,主要介紹了關於思考 rpc 框架層面,功能演進的方向是什麼?以及怎麼更好地支持雲上的多語言開發的新思考。

公眾號後臺回復 818 即可獲取直播回看地址和大會 PPT 合集。


看到這個題目,大家可能會有幾個問題,比如,什麼是雲原生微服務?Dubbo3.0 是什麼?和目前的 Dubbo2.0 有什麼區別?用了 Dubbo3.0 會帶來哪些業務視角的好處?後面的分享會對這些問題逐一解答。

這次分享分為以下幾個環節:

Dubbo 的演進歷史

Dubbo 的開源現狀

定義 Dubbo3.0 

分享 Dubbo 3.0 目前取得的一些成果

考慮到有些同學對 Dubbo 可能不太熟悉,在介紹背景之前,我先簡單介紹一下 Dubbo 是什麼。簡單地說,Dubbo 是基於 Java 的 RPC 框架。一個 RPC 框架至少由數據格式、傳輸協議和連接管理組成,這三點也是構成核心。Dubbo 能夠被廣泛應用主要有兩個原因:

 


Dubbo 發展歷程

簡單介紹完 Dubbo,現在讓我們一起回顧一下 Dubbo 的歷史。

在 2008 年,Dubbo 作為阿里巴巴內部 SOA 解決方案橫空出世。業務的急速發展帶來了強烈的服務化需求,只用了兩年的時間 dubbo 就在內部大面積落地,日均調用量超過了 30 億。經過落地過程中不斷的打磨,Dubbo 無論是在性能上還是在擴展性方面,都成為了當時遙遙領先的 RPC 框架。為了更好地回饋開發用戶和其他有服務化需求的公司,在 2011 年 Dubbo 選擇了開源,並發布了 2.0.7 版本作為開源的第一個正式版本。

開源後 Dubbo 蓬勃發展,社區活躍,獲得了開發者的一致好評。2017 年 9 月,阿里巴巴宣布重啟 dubbo 的開源維護,重啟開源後,解決了積累很久的 pull request 和 Issue ,以及之前一些公司不得不開始自己維護 dubbo 的私有分支也逐步合入了主幹。同時,與社區進一步的互動,也會激發 dubbo 團隊對產品的靈感。

目前 Dubbo 團隊就是阿里巴巴內部負責服務框架的團隊,我們在大流量、大規模集群、服務治理領域有著豐富的實踐,這些經驗已經在有序地回饋給社區。重啟開源後發布的 2.7.x 版本帶了了很多新的特性,比如 JDK8 支持,完整的異步支持,以及元數據的精簡和抽象。在今年,我們啟動了另外一個新的歷程碑 —— Dubbo3.0,這也會帶領 Dubbo 走向下一個階段,即雲原生微服務。


Dubbo 開源現狀

簡單介紹完 Dubbo 的歷史,下一步我們來走進 Dubbo 的開源現狀。

Dubbo 目前有 57 位 committer 和 379 位 contributor 。根據 X-lab 開放實驗室最新發布的《2020 年微服務領域開源數位化報告》,Dubbo 的開源活躍度全球排名 693,在微服務框架中排名第五。整個社區蓬勃發展,來自外部的代碼貢獻量已經超過來自阿里員工的貢獻量。也正是由於有這麼活躍的社區,Dubbo 目前支持 6 種語言和 30 多個生態項目。

數據來源《2020 年微服務領域開源數位化報告》,公眾號後臺回復關鍵詞「微服務報告」獲取報告全文。

作為國內 RPC 框架的領跑者, Dubbo 也在被 Spring Cloud Sleuth、Zipkin、Envoy、Mosn 等標杆項目官方集成。Dubbo-go 子社區是社區演進的另一個探索和優秀實踐。Dubbo-go 子社區由官方引導,完全社區化運作和開發,前不久發布的 Dubbo-go 1.5 版本在功能上已經完全對齊 Dubbo-java 2.7 版本,後續的 Dubbo3.0 也會包含 Dubbo-go 3.0 ,讓我們拭目以待。

從數據上看, Dubbo 目前有 33k stars 和 21k forks,分別位於 github java 項目前十和前三,用戶的認可帶來了社區的活躍,而活躍的社區則會以高頻率的版本更新帶來更多新的、有用的特性來彰顯其旺盛的活力。目前已經登記的 Dubbo 企業用戶超過了 200 個,其中有 30 多個企業成為了 Dubbo 的生態合作夥伴。

有了這些公司的幫助, Dubbo 在設計、開發、測試、灰度上線的整個流程都有了更強有力的保障。讓使用了 Dubbo 的應用跑的更快更穩定一直是 Dubbo 社區不變的追求。

從功能上看,Dubbo 3.0 完成後的功能將涵蓋從開發人員直接接觸的 API 層到底層傳輸的完整鏈路。

API 層將包括基於 IDL 的完整數據交換格式打通,這會帶來兩方面的好處:

第二層是對於註冊中心、元數據中心和配置中心的擴展。註冊中心和配置中心基本支持了所有業界主流的實現,元數據中心是 Dubbo 2.7 新抽象出的組件,負責元數據的存取。這裡的元數據包括服務的調用配置,如超時時間,序列化方式,協議等,以及對服務方法籤名的抽象,方便 Dubbo 實現跨框架和跨語言調用。

集群層是 Dubbo 的一個主要亮點,除了支持各種重試策略外,Dubbo 也提供了各種場景下的負載均衡器,比如隨機和權重。值得一提的是,Dubbo3.0 將帶來 pull-based 的自適應負載均衡,這將顯著提升分布式集群的性能和效率。

再下一層是協議層,協議層是 RPC 框架的內核部分,一般分為應用層協議和傳輸層協議。應用層協議 Dubbo3.0 支持 GRPC / Redis / REST 等主流協議以及 Dubbo 原生的 Dubbo2.0 協議。傳輸層支持 HTTP / HTTP2 和一些自定義的協議如 RSOCKET。序列化方面,Dubbo 除了支持 hessian 、Java 外,還支持 protobuf,這對於性能和跨語言都有著巨大的意義。

看完了 Dubbo 3.0-java 的功能圖,我們再來看一下 Dubbo-go 的功能圖。可以看到,從分層到實現, Dubbo-go 已經基本和 JAVA 對齊,後面的 3.0 版本也會和 JAVA 齊頭並進,共同邁向雲原生。


Dubbo3.0-下一代雲原生微服務

介紹完了 Dubbo 的現狀,下面我們進入今天的主題:Dubbo3.0 -下一代雲原生微服務。

一個新架構或新技術的出現一定會伴隨特定的發展趨勢。

目前我們可以看到的幾個趨勢是 K8s 成為資源調度的事實標準、Mesh 化成為主流以及規模上的急速增長。這些趨勢的存在對 Dubbo 提出了更高的要求:

 

 

這些雲原生時代帶來的挑戰,促成了 Dubbo 的下一代定義。新協議、K8s 基礎架構支持、多語言支持和規模化支持四個子項目共同組成了 Dubbo3.0 。下面我們將走進 Dubbo3.0,看看具體有哪些新特性。

首先我們從協議開始。

大家可以看到,這是 Dubbo2.0 的協議。從功能上看, Dubbo2.0 提供了 RPC 的核心語義,包括協議頭、標誌位、請求 ID 以及請求/響應數據。在雲原生時代,2.0 協議主要面臨兩個挑戰:

那麼,在支持已有的功能和解決存在的問題的前提下,下一代的協議需要有哪些特性呢?

 

 

 

基於這些需求,HTTP2/protobuf 的組合是最符合的。提到這兩個,大家可能很容易想到 GRPC 協議。那新一代的協議和 GRPC 的關係是什麼呢?

 

 

 

Dubbo3.0 第二個內容是應用級註冊發現。

熟悉 Dubbo 的同學都知道,Dubbo 目前的註冊發現都是接口級別的。也就是同一個應用發布的多個服務會在註冊中心註冊多份數據,這些數據彼此獨立,方便進行服務化改造和接口遷移。為什麼要提出應用級註冊發現呢?

主要有兩個原因:

 

可以看到,應用級註冊發現帶來的優化是十分顯著的。由於應用級註冊發現目前已經基本開發完畢,下面我們可以簡單介紹下它的原理。

首先要解決的一個問題是如何保證平滑遷移,用戶基於接口的配置怎麼映射到應用上去。

這裡我們抽象出了元數據中心來管理接口到應用的映射以及應用級的元數據。在部署態,Dubbo 框架會自動上報這個關係到元數據中心。而運行態用戶側的配置和服務治理則通過這份映射關係重新將應用粒度映射到接口粒度。涉及到最核心的部分——選址也是分為兩部分,應用級選址和接口級選址同時存在,方便進行服務治理。

Dubbo3.0 第三個內容是 K8s 雲原生支持。

這裡主要包括兩部分內容:

 

Dubbo3.0 最後一部分是柔性增強。

柔性增強要解決的問題有兩個:

從方法上看,Dubbo3.0 的柔性增強會以面向失敗設計為理念,提供包括精準容量評估、自適應限流、自適應負載均衡的支持,自底向上的分步構建大規模可靠應用。從單一服務的視角看,服務是壓不垮的,穩定的。

從分布式視角看,複雜的拓撲不會帶來性能的下降,分布式負載均衡能夠以最優的方式動態分配流量,保證異構系統能夠根據運行時的準確服務容量合理分配請求,從而達到性能最優。


Dubbo3.0 路線圖

介紹完了 Dubbo3.0 的主要內容,下面我們來看一下 roadmap。

在接下來的 9 月份,應用級註冊發現會同時在阿里巴巴內部和外部公司同時大規模落地。今年雙十一前會交付雲原生服務治理規則。到明年的 3 月份,開源側的新協議支持功能基本完備。明年的 6 月份,雲原生 K8s 的支持和 Mesh 支持功能完備,開始試點。柔性增強將在 2022 年的 3 月份全面落地,請拭目以待。

看了 roadmap ,大家可以發現,Dubbo3.0 已經是運行態。

首先,基於 Dubbo3.0 核心的 HSF3.0 在阿里巴巴內部大規模落地,內外統一的路線不僅僅是對 Dubbo 質量的肯定,也是對社區用戶的保障和回饋。

後續我們會將內部的大規模高並發經驗繼續輸出到 Dubbo 開源側,也會以最高的質量來保證 Dubbo 的可靠演進。Dubbo 3.0 的應用級註冊發現功能也在內部和開源側同時灰度試點。在協議側,新協議已經在阿里巴巴和螞蟻的互通中得到廣泛應用,內部實踐的經驗將更好的服務開源側協議演進。

最後,歡迎大家參與 dubbo 的社區,分享你們在實踐中的經驗,反饋碰到的問題,攜手讓 Dubbo 發展的更好。

公眾號後臺回復 818 即可獲取直播回看地址和大會 PPT 合集。

相關焦點

  • 微服務優劣勢
    3、容錯 在微服務架構下,當某一組件發生故障時,故障會被隔離在單個服務中。 通過限流、熔斷等方式降低錯誤導致的危害,保障核心業務正常運行。 4、擴展 單塊架構應用也可以實現橫向擴展,就是將整個應用完整的複製到不同的節點。當應用的不同組件在擴展需求上存在差異時,微服務架構便體現出其靈活性,因為每個服務可以根據實際需求獨立進行擴展。
  • Genesys李進宜演講PPT《微服務、雲原生——Genesys Cloud 生而為...
    體驗即服務℠解決方案由Genesys Cloud™提供支持,Genesys Cloud™是一款全球領先的一體化解決方案和公有雲聯絡中心平臺,具備突出的快速創新性、可擴展性和靈活性。訪問www.genesys.com/zh-cn  ©2020 Genesys電信實驗室保留所有權利。Genesys和Genesys標識是Genesys的商標或註冊商標。
  • Dubbo 3.0 預覽版解讀,支持 Filter 鏈的異步化
    自去年 12 月開始,Dubbo 3.0 便已正式進入開發階段,並備受社區和廣大 Dubbo 用戶的關注,本文將為您詳細解讀 3.0 預覽版的新特性和新功能。
  • 20道你必須要背會的微服務面試題,面試一定會被問到
    3、springcloud 與dubbo有哪些區別?4、請談談對SpringBoot 和SpringCloud的理解5、分布式系統面臨的問題6、什麼是服務熔斷,什麼是服務降級7、微服務的優缺點分別是什麼?說下你在項目開發中碰到的坑?8、你所知道的微服務技術棧有哪些?請列舉一二9、什麼是 Eureka服務註冊與發現10、Eureka的基本架構是什麼?
  • 微服務升級優點 - CSDN
    【編者的話】微服務的概念源於 2014 年 3 月 Martin Fowler 所寫的一篇文章「Microservices」。文中內容提到:微服務架構是一種架構模式,它提倡將單一應用程式劃分成一組小的服務,服務之間互相協調、互相配合,為用戶提供最終價值。背景應用系統的架構歷史什麼是微服務?
  • 微服務架構開發實戰:如何實現微服務的自動擴展?
    1.容器編排的重要性 編排很重要,是因為在微服務的架構裡面,應用程式被拆分成不同的微服務應用,因此需要更多的伺服器節點進行部署。為了正確管理微服務,開發人員傾向於為每個虛擬機部署一個微服務 ,這在一定程度上:降低了資源利用率。在很多情況下,這會導致CPU和內存的過度分配。
  • 信也科技推出Radar微服務框架 助力行業提升微服務治理能力
    1月6日,信也科技正式對外推出Radar微服務框架,此微服務組件如其名稱一樣,像雷達般迅速,可有效提高架構靈活性與服務可治理性。 近年來,微服務框架在各業務場景中已大量落地。信也科技在對內部系統進行微服務改造的過程中,摸索出了一條獨具特色的道路。
  • 愛奇藝微服務監控的探索與實踐 選型寶精選閱讀
    本文分享愛奇藝有關微服務監控的實踐和思考。如文章《愛奇藝視頻後臺從"單兵作戰"到"團隊協作"的微服務實踐》 所述,2018年愛奇藝信息流技術團隊基於Spring Cloud和公司服務雲組件,實現了業務系統的全面微服務化。微服務的拆分,一方面提升了服務負責人的ownership,助力業務快速迭代。
  • 智能升級新階段,華為雲助力新雲原生企業駛出加速度
    隨著企業上雲步伐加快,傳統的開發模式較難滿足企業產品業務快速迭代升級需求,越來越多的企業和開發者開始把業務與技術向雲原生演進。據數據顯示,到 2021 年,將有 92% 的公司成為雲原生公司。據 CNCF 的雲原生開發現狀報告顯示,如今全球雲原生開發人員超過 470 萬。我們發現,雲原生 2.0 時代已經到來。
  • 雲視頻,華為雲新的「殺手鐧」
    雲原生2.0究竟是怎樣的趨勢?鬥魚為什麼這麼選擇?華為雲在雲原生2.0時代將發揮怎樣的作用?雲原生由CloudNative翻譯而來,指一種面向雲計算去構建和運行「應用程式」的方法。華為雲CTO張宇昕則表示,新雲原生企業既需要滿足新生能力生於雲、長於雲,也需要繼承和發展既有能力,並與新生能力立而不破、有機協同。華為雲CTO張宇昕為了幫助企業客戶成為雲原生2.0時代的居民,華為雲推出雲原生基礎設施全棧解決方案,引領雲原生進入Cloud Native 2.0時代。
  • 構築雲原生安全技術底座 綠盟科技發布《雲原生安全技術報告》
    3. 安全左移,更早的發現安全問題在雲原生架構中,容器生命周期短、業務複雜、網絡複雜,現有的物理或虛擬化的安全設備無法工作,運行時的安全檢測將會投入很高成本。「安全前置」或者「安全左移」可以在軟體開發生命周期的更早階段,投入更多的安全資源,嵌入安全動作,來有效的收斂安全漏洞問題,儘可能更早的確定其安全性。4.
  • 騰訊雲聯合寒武紀、美團等六家單位 共同發布SuperEdge邊緣容器...
    騰訊雲方面介紹,SuperEdge是基於原生Kubernetes的邊緣容器管理系統。該系統把雲原生能力擴展到邊緣側,可實現雲端對邊緣端的管理和控制,簡化應用從雲端部署到邊緣端的過程。騰訊雲將開源邊緣容器產品TKE Edge中邊緣相關的原始碼,並貢獻到SuperEdge開源項目中。
  • 入選InfoQ中國技術力量年度榜單 青雲QingCloud以雲原生強化工業...
    (原標題:入選InfoQ中國技術力量年度榜單 青雲QingCloud以雲原生強化工業數位化變革)
  • 青雲科技QKE容器雲服務增強GPU能力 輕鬆構建 AI 應用
    北京,2020年5月21日——企業級混合雲服務商青雲QingCloud(qingcloud.com)日前宣布,其容器公有雲服務QKE(QingCloud KubeSphere Engine)再次升級(詳情:qingcloud.com/products/kubesphereqke/),新增 GPU 計算節點與 CPU 指令集配置
  • 雲遊戲能否終結下一代遊戲主機?
    3.8億美元收購美國雲遊戲公司Gaikai對未來雲遊戲的發展所做的一些評點,對於雲遊戲能否終結下一代遊戲主機作者並沒有給出明確的結論。不過這一周發生的一件有趣的事情可能會改變主機廠商對他們的硬體和軟體服務的看法:本周一,索尼宣布斥資3.8億美元收購美國雲遊戲公司Gaikai。當然,關於新的遊戲主機的硬體、晶片和規格的謠言只有當它真正發布的時候才會得到證實。所有的跡象表明我們看到的老一代遊戲主機都在進行著同一類型的硬體開發工作——包括提高性能、下一代CPU和GPU的引入來提高遊戲性和圖形能力。
  • 騰訊雲聯合英特爾、美團等發布SuperEdge邊緣容器開源項目
    SuperEdge是基於原生Kubernetes的邊緣容器管理系統。該系統把雲原生能力擴展到邊緣側,很好的實現了雲端對邊緣端的管理和控制,極大簡化了應用從雲端部署到邊緣端的過程。SuperEdge為應用實現邊緣原生化提供了強有力的支持。SuperEdge是騰訊雲牽頭社區多家廠商共同發起的一個的開源項目。
  • 騰訊雲聯合六家發起單位,共同發布 SuperEdge 邊緣容器開源項目
    作為一個通用的邊緣容器管理系統,SuperEdge 項目擁有諸多特性:  1.Kubernetes 原生:SuperEdge 以無侵入的方式將 Kubernetes 強大的容器編排、調度能力拓展到邊緣端,其原生支持 Kubernetes,完全兼容 Kubernetes 所有 API 及資源,無額外學習成本。
  • 騰訊云云原生產品矩陣再升級,推出八款雲原生系列產品
    《中國雲原生用戶調研報告(2020年)》顯示,2019年我國雲原生產業市場規模已達350.2億元,未來還將延續高速增長態勢。近幾年,隨著雲原生領域市場規模的快速增長,企業和開發者也對產品功能的多樣性、便捷性以及應用場景的豐富性提出了更多要求。對此,騰訊雲重磅推出了八款產品,以成熟穩定的服務方式,將騰訊在雲原生領域的技術積累輸出,讓雲原生新技術能快速落地。
  • 在混合多雲世界中構建雲端原生應用程式
    重視客戶體驗創新的企業很快就會發現採用雲端原生開發模型的價值。採用雲端原生開發,既有特定於應用程式的需求,也有與部署相關的動機。  希望轉變其應用程式的企業正在考慮採用雲端原生技術開發和部署其最關鍵的工作負載。
  • 猜想雲遊戲能否終結下一代遊戲主機?
    1雲遊戲機目前還是啞巴盒子  本文是其就周一索尼宣布斥資3.8億美元收購美國雲遊戲公司Gaikai對未來雲遊戲的發展所做的一些評點,對於雲遊戲能否終結下一代遊戲主機作者並沒有給出明確的結論。