Dubbo簡介
Apache Dubbo是一款RPC服務開發(fā)框架，那何為RPC呢史煎？全稱為Remote Procedure Call谦屑，翻譯過來就是遠程過程調用驳糯。
使用 Dubbo 開發(fā)的微服務原生具備相互之間的遠程地址發(fā)現(xiàn)與通信能力， 利用 Dubbo 提供的豐富服務治理特性氢橙，可以實現(xiàn)諸如服務發(fā)現(xiàn)酝枢、負載均衡、流量調度等服務治理訴求悍手。Dubbo 被設計為高度可擴展帘睦，用戶可以方便的實現(xiàn)流量攔截、選址的各種定制邏輯坦康。
1竣付，什么是dubbo
阿里巴巴開發(fā)的云原生微服務架構框架，類似于springcloud滞欠，兩者之間各有優(yōu)勢古胆。那什么又是云原生？很早之前就已經提出了云原生的思想筛璧，在計算機領域中逸绎，思想重要，技術的變革夭谤，一定是思想先行棺牧。云原生是一種構建和運行應用程序的方法，是一套技術體系和方法論朗儒。云原生（CloudNative）是一個組合詞颊乘，Cloud+Native。Cloud表示應用程序位于云中采蚀，而不是傳統(tǒng)的數(shù)據(jù)中心疲牵；Native表示應用程序從設計之初即考慮到云的環(huán)境，原生為云而設計榆鼠，在云上以最佳姿勢運行纲爸，充分利用和發(fā)揮云平臺的彈性+分布式優(yōu)勢。
Dubbo開發(fā)相較于Springcloud具有一些優(yōu)勢：
- 開箱即用
- 易用性高妆够，如 Java 版本的面向接口代理特性能實現(xiàn)本地透明調用
- 功能豐富识啦，基于原生庫或輕量擴展即可實現(xiàn)絕大多數(shù)的微服務治理能力
- 面向超大規(guī)模微服務集群設計
- 極致性能，高性能的 RPC 通信協(xié)議設計與實現(xiàn)
- 橫向可擴展神妹，輕松支持百萬規(guī)模集群實例的地址發(fā)現(xiàn)與流量治理
- 高度可擴展
- 調用過程中對流量及協(xié)議的攔截擴展颓哮，如 Filter、Router鸵荠、LB 等
- 微服務治理組件擴展冕茅，如 Registry、Config Center、Metadata Center 等
- 企業(yè)級微服務治理能力
- 國內共有云廠商支持的事實標準服務框架
2姨伤，Dubbo的一些概念
RPC通信
在Dubbo3中哨坪，RPC通信主要是使用Triple協(xié)議，Triple協(xié)議構建于HTTP/2協(xié)議上乍楚，兼容gRPC（gRPC協(xié)議是Google開發(fā)的基于HTPP/2和protobuf的RPC協(xié)議框架）当编，提供提供 Request Response、Request Streaming徒溪、Response Streaming忿偷、Bi-directional Streaming 等通信模型；從 Triple 協(xié)議開始臊泌，Dubbo 還支持基于 IDL 的服務定義鲤桥。
此外，Dubbo 還集成了業(yè)界主流的大部分協(xié)議缺虐，使得用戶可以在 Dubbo 框架范圍內使用這些通信協(xié)議芜壁，為用戶提供了統(tǒng)一的編程模型與服務治理模型，這些協(xié)議包括 rest高氮、hessian2慧妄、jsonrpc、thrift 等剪芍，注意不同語言 SDK 實現(xiàn)支持的范圍會有一些差異塞淹。
服務發(fā)現(xiàn)
服務發(fā)現(xiàn)，是消費端自動發(fā)現(xiàn)服務地址列表的能力罪裹，是微服務框架需要具備的關鍵能力饱普，借助于自動化的服務發(fā)現(xiàn)，微服務之間在無需感知對端部署位置與IP地址的情況下實現(xiàn)通信状共。
實現(xiàn)的方式有多種套耕，一種是Dubbo提供的Client-Based服務發(fā)現(xiàn)機制，同時也需要第三方注冊中心來協(xié)調服務發(fā)現(xiàn)過程峡继，比如Nacos/Zookeeper等冯袍。
基本原理圖：
流量治理
Dubbo2開始，Dubbo就提供了豐富的服務治理規(guī)則碾牌，包括路由規(guī)則/動態(tài)配置等康愤。
一方面 Dubbo3 正在通過對接 xDS 對接到時下流行的 Mesh 產品如 Istio 中所使用的以 VirtualService、DestinationRule 為代表的治理規(guī)則舶吗，另一方面 Dubbo 正尋求設計一套自有規(guī)則以實現(xiàn)在不通部署場景下的流量治理征冷，以及靈活的治理能力。
Dubbo Mesh
Mesh網(wǎng)絡可以理解為WiFi路由器覆蓋不到一些死角誓琼，可以在死角覆蓋得到的地方检激，放一臺中繼WIFI肴捉，形成MESH網(wǎng)絡，就可以覆蓋到死角叔收。
Dubbo Mesh 的目標是提供適應 Dubbo 體系的完整 Mesh 解決方案每庆，包含定制化控制面（Control Plane）、定制化數(shù)據(jù)面解決方案今穿。Dubbo 控制面基于業(yè)界主流 Istio 擴展，支持更豐富的流量治理規(guī)則伦籍、Dubbo應用級服務發(fā)現(xiàn)模型等蓝晒，Dubbo 數(shù)據(jù)面可以采用 Envoy Sidecar，即實現(xiàn) Dubbo SDK + Envoy 的部署方案帖鸦，也可以采用 Dubbo Proxyless 模式芝薇，直接實現(xiàn) Dubbo 與控制面的通信。
3作儿，Dubbo 架構圖
整體上來看洛二，Dubbo首先是一款RPC框架，用戶在使用 Dubbo 時首先需要定義好 Dubbo 服務攻锰；其次晾嘶，是在將 Dubbo 服務部署上線之后，依賴 Dubbo 的應用層通信協(xié)議實現(xiàn)數(shù)據(jù)交換娶吞，Dubbo 所傳輸?shù)臄?shù)據(jù)都要經過序列化垒迂，而這里的序列化協(xié)議是完全可擴展的。 使用 Dubbo 的第一步就是定義 Dubbo 服務妒蛇，服務在 Dubbo 中的定義就是完成業(yè)務功能的一組方法的集合机断，可以選擇使用與某種語言綁定的方式定義，如在 Java 中 Dubbo 服務就是有一組方法的 Interface 接口绣夺，也可以使用語言中立的 Protobuf Buffers IDL 定義服務吏奸。
定義好服務之后，服務端（Provider）需要提供服務的具體實現(xiàn)陶耍，并將其聲明為 Dubbo 服務奋蔚，而站在服務消費方（Consumer）的視角，通過調用 Dubbo 框架提供的 API 可以獲得一個服務代理（stub）對象物臂，然后就可以像使用本地服務一樣對服務方法發(fā)起調用了旺拉。
在消費端對服務方法發(fā)起調用后，Dubbo 框架負責將請求發(fā)送到部署在遠端機器上的服務提供方棵磷，提供方收到請求后會調用服務的實現(xiàn)類蛾狗，之后將處理結果返回給消費端，這樣就完成了一次完整的服務調用仪媒。如圖中的 Request沉桌、Response 數(shù)據(jù)流程所示谢鹊。
需要注意一點，在Dubbo中留凭，服務指的是RPC粒度的佃扼，和讀者印象中的泛指的功能型服務不是同一概念。
在分布式系統(tǒng)中蔼夜，服務越來越多兼耀，應用之間的部署越來越繁雜，用戶作為RPC的消費方求冷，如何動態(tài)知道服務提供方地址瘤运，因此Dubbo引入了注冊中心來協(xié)調提供方和消費方的地址。提供者啟動之后向注冊中心注冊自身地址匠题，消費方通過拉取或訂閱注冊中心特定節(jié)點拯坟，動態(tài)的感知提供方地址列表的變化。
注冊中心可以使用：
- 如 Nacos韭山、Zookeeper郁季、Consul、Etcd 等钱磅。
- 將服務的組織與注冊交給底層容器平臺梦裂，如 Kubernetes，這可以理解為更加云原生的使用方式盖淡。
Dubbo的部署架構圖：
Dubbo微服務組件包含三個中心組件：
注冊中心塞琼，協(xié)調Consumer與Provider之間的地址與發(fā)現(xiàn)
-
配置中心
- 存儲Dubbo啟動階段的全局配置，保證配置的跨環(huán)境共享與全局一致性
- 負責服務治理規(guī)則（路由規(guī)則/動態(tài)配置等）的存儲與推送
-
元數(shù)據(jù)中心
- 接收Provider上報的服務接口元數(shù)據(jù)禁舷，為Admin等控制臺提供運維能力（如服務測試/接口文檔等）
- 也作為注冊中心的額外擴展彪杉，作為服務發(fā)現(xiàn)機制的補充，提供額外的接口/方法級別配置信息的同步能力
注冊中心
不依賴于配置中心和元數(shù)據(jù)中心牵咙，主要承載的作用是服務注冊和服務發(fā)現(xiàn)的職責派近，Dubbo支持接口級別和應用級別的兩種粒度的服務發(fā)現(xiàn)和服務注冊。
如果Dubbo僅僅是使用RPC直連服務洁桌，可以不部署注冊中心渴丸。在接口或者應用級別，可以選擇部署對應的注冊中心另凌。在Dubbo + Mesh 的場景下谱轨，隨著 Dubbo 服務注冊能力的弱化，Dubbo內的注冊中心也不再是必選項吠谢，其職責開始被控制面取代土童，如果采用了Dubbo + Mesh的部署方式，無論是ThinSDK的mesh方式還是Proxyless的mesh方式工坊，都不再需要獨立部署注冊中心献汗。
metadata(元數(shù)據(jù)中心)
- 對于一個原先采用老版本Dubbo搭建的應用服務敢订，在遷移到Dubbo 3時，Dubbo 3 會需要一個元數(shù)據(jù)中心來維護RPC服務與應用的映射關系（即接口與應用的映射關系）罢吃，因為如果采用了應用級別的服務發(fā)現(xiàn)和服務注冊楚午，在注冊中心中將采用“應用 —— 實例列表”結構的數(shù)據(jù)組織形式，不再是以往的“接口 —— 實例列表”結構的數(shù)據(jù)組織形式尿招，而以往用接口級別的服務注冊和服務發(fā)現(xiàn)的應用服務在遷移到應用級別時矾柜，得不到接口與應用之間的對應關系，從而無法從注冊中心得到實例列表信息就谜，所以Dubbo為了兼容這種場景把沼，在Provider端啟動時，會往元數(shù)據(jù)中心存儲接口與應用的映射關系吁伺。
- 為了讓注冊中心更加聚焦與地址的發(fā)現(xiàn)和推送能力，減輕注冊中心的負擔租谈，元數(shù)據(jù)中心承載了所有的服務元數(shù)據(jù)篮奄、大量接口/方法級別配置信息等，無論是接口粒度還是應用粒度的服務發(fā)現(xiàn)和注冊割去，元數(shù)據(jù)中心都起到了重要的作用窟却。
如果有以上兩種需求，都可以選擇部署元數(shù)據(jù)中心呻逆，并通過Dubbo的配置來集成該元數(shù)據(jù)中心夸赫。
元數(shù)據(jù)中心并不依賴于注冊中心和配置中心，用戶可以自由選擇是否集成和部署元數(shù)據(jù)中心咖城，如下圖所示：
配置中心
整個部署架構中茬腿，整個集群內實例（無論是Provider還是Consumer）都會共享該配置中心集群中的配置。
三大中心不一定是Dubbo應用服務必須使用的宜雀，但是如果集成了三大部署中心切平，還是會遇到可用性問題，比如多個注冊中心辐董，多個配置中心悴品，多個元數(shù)據(jù)中心，系統(tǒng)該如何運行简烘。
Dubbo對三大中心都支持了Multiple模式：
- 多注冊中心：Dubbo 支持多注冊中心苔严，即一個接口或者一個應用可以被注冊到多個注冊中心中，比如可以注冊到ZK集群和Nacos集群中孤澎，Consumer也能夠從多個注冊中心中進行訂閱相關服務的地址信息届氢，從而進行服務發(fā)現(xiàn)。通過支持多注冊中心的方式來保證其中一個注冊中心集群出現(xiàn)不可用時能夠切換到另一個注冊中心集群覆旭，保證能夠正常提供服務以及發(fā)起服務調用悼沈。這也能夠滿足注冊中心在部署上適應各類高可用的部署架構模式贱迟。
- 多配置中心：Dubbo支持多配置中心，來保證其中一個配置中心集群出現(xiàn)不可用時能夠切換到另一個配置中心集群絮供，保證能夠正常從配置中心獲取全局的配置衣吠、路由規(guī)則等信息。這也能夠滿足配置中心在部署上適應各類高可用的部署架構模式壤靶。
- 多元數(shù)據(jù)中心：Dubbo 支持多元數(shù)據(jù)中心：用于應對容災等情況導致某個元數(shù)據(jù)中心集群不可用缚俏，此時可以切換到另一個元數(shù)據(jù)中心集群，保證元數(shù)據(jù)中心能夠正常提供有關服務元數(shù)據(jù)的管理能力贮乳。
如遇到多個注冊中心的話忧换，部署架構如下：
機房A，機房B向拆，兩個Registry亚茬，Provider A會通過Dubbo SDK把地址注冊到Registry A，Consumer A會和注冊中心A進行一個互相訂閱地址浓恳。機房B原理和機房A原理一樣刹缝。機房AB中的注冊中心會進行數(shù)據(jù)同步，這樣機房A的consumer A也可以看作和機房B的Registry進行訂閱地址同步颈将。
4梢夯，Dubbo可擴展性
為什么要在系統(tǒng)中強調可擴展性呢？一個很大的原因是晴圾，比如一個系統(tǒng)設計好之后颂砸，后期又需要加入一些功能代碼或者插件，如何最小化改變原有代碼加入功能代碼或者插件死姚，這個就是擴展性人乓，Dubbo在架構時期也一直重視可擴展性。
在市面上都毒，有成熟的可擴展技術撒蟀，比如SPring的IOC容器，或者是Factory温鸽，Dubbo在設計之初保屯，不想強依賴于Spring的IOC，又不想大費周章開發(fā)出來一個IOC容器涤垫，因此使用了最簡單的Factory姑尺。
Dubbo擴展加載流程如圖：
主要步驟為 4 個：
- 讀取并解析配置文件
- 緩存所有擴展實現(xiàn)
- 基于用戶執(zhí)行的擴展名，實例化對應的擴展實現(xiàn)
- 進行擴展實例屬性的 IOC 注入以及實例化擴展的包裝類蝠猬，實現(xiàn) AOP 特性
歡迎關注我的公眾號：我只是個碼字的
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布切蟋！
