Java分散式服務架構Dubbo介紹

2022-06-29 18:03:57

1、什麼是Dubbo？

Dubbo是阿里巴巴公司開源的一個高效能分散式服務架構。其核心部分包含：

叢集容錯：提供基於介面方法的透明遠端過程呼叫，包括多協定支援，以及軟負載均衡，失敗容錯，地址路由，動態設定等叢集支援。
遠端通訊：提供對多種基於長連線的NIO框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”模式的資訊交換方式。
自動發現：基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

2、Dubbo核心元件是？

生產者（Provider）：暴露服務的提供方，可以通過jar或者容器的方式啟動服務；
消費者（Consumer）：呼叫遠端服務的服務消費方；
註冊中心（Registry）：服務註冊中心和發現中心；
監控中心（Monitor）：統計服務和呼叫次數，呼叫時間監控中心；
服務容器（Container）：服務執行的容器，負責啟動、載入，執行服務；

流程：首先生產者將服務註冊到註冊中心（zk），使用zk持久節點進行儲存，消費訂閱zk節點，一旦有節點變更，zk通過事件通知傳遞給消費者，消費可以呼叫生產者服務。服務與服務之間進行呼叫，都會在監控中心中，儲存一個記錄。

3、Dubbo的工作原理是？

服務啟動的時候，Provider和Consumer根據設定資訊，連線到註冊中心Register，分別向註冊中心註冊和訂閱服務；
register根據服務訂閱關係，返回Provider資訊到Consumer，同時Consumer會把Provider資訊快取到本地。如果資訊有變更，Consumer會收到來自Register的推播；
Consumer生成代理物件，同時根據負載均衡策略，選擇一臺Provider，同時定時向Monitor記錄介面的呼叫次數和時間資訊，拿到代理物件之後，Consumer通過代理物件發起介面呼叫；
Provider收到請求後對資料進行反序列化，然後通過代理呼叫具體的介面實現；

4、介紹一下Dubbo框架分層？

從大的範圍來說，Dubbo分為3層：Business業務邏輯層由我們自己來提供介面和實現還有一些設定資訊，RPC層就是真正的RPC呼叫的核心層，封裝整個RPC的呼叫過程、負載均衡、叢集容錯、代理，Remoting層則是對網路傳輸協定和資料轉換的封裝。

劃分到更細的層面，就是10層模式，整個分層依賴由上至下，除開business業務邏輯之外，其他的幾層都是SPI機制。10層模式如下：

服務介面層（Service）：與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。
設定層（Config）：對外設定介面，以ServiceConfig和ReferenceConfig為中心，可以直接new設定類，也可以通過Spring解析設定生成設定類。
服務代理層（Proxy）：服務介面透明代理，生成服務的使用者端Stub和伺服器端Skeleton，以ServiceProxy為中心，擴充套件介面為ProxyFactory。
服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL為中心，擴充套件介面為RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
叢集層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心，擴充套件介面為Cluster、Directory、Router和LoadBalance。將多個服務提供方組合為一個服務提供方，實現對服務消費方來透明，只需要與一個服務提供方進行互動。
監控層（Monitor）：RPC呼叫次數和呼叫時間監控，以Statistics為中心，擴充套件介面為MonitorFactory、Monitor和MonitorService。
遠端呼叫層（Protocol）：封將RPC呼叫，以Invocation和Result為中心，擴充套件介面為Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和參照的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke呼叫，它有可能是一個原生的實現，也可能是一個遠端的實現，也可能一個叢集實現。
資訊交換層（Exchange）：封裝請求響應模式，同步轉非同步，以Request和Response為中心，擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
網路傳輸層（Transport）：抽象mina和netty為統一介面，以Message為中心，擴充套件介面為Channel、Transporter、Client、Server和Codec。
資料序列化層（Serialize）：可複用的一些工具，擴充套件介面為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

5、Dubbo支援哪些協定？

1.dubbo預設協定：

單一 TCP 長連線，Hessian 二進位制序列化和 NIO 非同步通訊；
適合於小封包大並行的服務呼叫和服務消費者數遠大於服務提供者數的情況；
不適合傳送巨量資料包的服務；

2.rmi協定：

採用 JDK 標準的 java.rmi.* 實現，阻塞式短連線和 JDK 標準序列化方式；
如果服務介面繼承了 java.rmi.Remote 介面，可以和原生 RMI 互操作；
因反序列化漏洞，需升級 commons-collections3 到 3.2.2版本或 commons-collections4 到 4.1 版本；
對傳輸封包不限，消費者和傳輸者個數相當；

3.hessian協定：

底層 Http 通訊，Servlet 暴露服務，Dubbo 預設內嵌 Jetty 作為伺服器實現；
可與原生 Hessian 服務互操作；
通訊效率高於 WebService 和 Java 自帶的序列化；
引數及返回值需實現 Serializable 介面，自定義實現 List、Map、Number、Date、Calendar 等介面；
適用於傳輸封包較大，提供者比消費者個數多，提供者壓力較大；

4.http協定：

基於 http 表單的遠端呼叫協定，短連線，json 序列化；
對傳輸封包不限，不支援傳檔案；
適用於同時給應用程式和瀏覽器 JS 使用的服務；

5.webservice協定：

基於Apache CXF 的frontend-simple和transports-http 實現，短連線，SOAP文字序列化；
可與原生WebService服務互操作；
適用於系統整合、跨語言呼叫；

6.thrift協定：

對 thrift 原生協定的擴充套件新增了額外的頭資訊；
使用較少，不支援傳 null 值；

7.redis協定:

redis在TCP埠6379上監聽到來的連線，使用者端連線到來時，Redis伺服器為此建立一個TCP連線 ;
redis接收由不同引陣列成的命令。一旦收到命令，將會立刻被處理，並回復給使用者端;

8.memcached協定:

使用者端使用TCP連結與伺服器通訊，一個執行中的memcached伺服器監視一些埠，使用者端連線這些埠，傳送命令到伺服器，讀取回應，最後關閉連線;
memcached協定中傳送的資料分為文字行和自由資料兩種；

6、Dubbo核心設定有哪些？

核心設定有：

設定	說明
dubbo:service/	服務設定
dubbo:reference/	參照設定
dubbo:argument/	引數設定
dubbo:protocol/	協定設定
dubbo:registry/	註冊中心設定
dubbo:application/	應用設定
dubbo:provider/	提供方設定
dubbo:consumer/	消費方設定
dubbo:method/	方法設定
dubbo:module/	模組設定
dubbo:monitor/	監控中心設定

7、Dubbo有哪幾種叢集容錯方案、哪幾種負載均衡策略？

在叢集呼叫失敗時，Dubbo 提供了多種容錯方案，預設為 failover 重試。具體的叢集容錯方案有：

叢集容錯方案	說明
Failover Cluster	失敗自動切換，自動重試其他伺服器（預設）
Failfast Cluster	快速失敗，立即報錯，只發起一次呼叫
Failsafe Cluster	失敗安全，出現異常時，直接忽略
Failback Cluster	失敗自動恢復，記錄失敗請求，定時重發
Forking Cluster	並行呼叫多個伺服器，只要一個成功即返回
Broadcast Cluster	廣播逐個呼叫所有提供者，任意一個報錯則報錯

Dubbo內建了4種負載均衡策略：

負載均衡策略	說明
RandomLoadBalance	隨機負載均衡，按權重設定隨機概率（預設）
RoundRobinLoadBalance	輪詢負載均衡，按公約後的權重設定輪詢比率
LeastActiveLoadBalance	最少活躍呼叫數，相同活躍數的隨機
ConsistentHashLoadBalance	一致性Hash負載均衡，相同引數的請求總是發到同一個提供者

8、Dubbo用到哪些設計模式，簡要介紹？

工廠模式：Provider在export服務時，會呼叫ServiceConfig的export方法，實現類的獲取採用了JDK SPI的機制，想要擴充套件實現，只需要在classpath下增加檔案即可，程式碼零侵入；
裝飾器模式：Dubbo在啟動和呼叫階段都大量使用了裝飾器模式，如ClassLoaderFilter在主功能上新增功能，更改當前執行緒的ClassLoader是典型的裝飾器模式；
觀察者模式：Dubbo的Provider啟動時，需要與註冊中心互動，先註冊自己的服務，再訂閱自己的服務，訂閱時，採用了觀察者模式；
動態代理模式：Dubbo擴充套件JDK SPI的類ExtensionLoader的Adaptive實現是典型的動態代理實現，Dubbo需要靈活地控制實現類，即在呼叫階段動態地根據引數決定呼叫哪個實現類，所以採用先生成代理類的方法，做到靈活的呼叫。

9、Dubbo有哪些註冊中心？

Multicast 註冊中心：Multicast 註冊中心不需要任何中心節點，只要廣播地址，就能進行服務註冊和發現,基於網路中組播傳輸實現。
Zookeeper 註冊中心：基於分散式協調系統 Zookeeper 實現，採用 Zookeeper 的 watch 機制實現資料變更。
Redis 註冊中心：基於 Redis 實現，採用 key/map 儲存，key 儲存服務名和型別，map 中 key 儲存服務 url，value 服務過期時間。基於 Redis 的釋出/訂閱模式通知資料變更。
Simple 註冊中心：Simple 註冊中心本身就是一個普通的 Dubbo 服務，可以減少第三方依賴，使整體通訊方式一致。