日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

Dubbo 起源于阿里巴巴，對于我們做電商開發(fā)的人來說，基本是選擇的技術，那么為何一個區(qū)區(qū) soa 服務治理框架，會受到這么多人的青睞呢?

為衛(wèi)輝等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及衛(wèi)輝網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站建設、網(wǎng)站建設、衛(wèi)輝網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

今天就跟著小羽一起看看這個微服務框架之一的 Dubbo 的詳細解讀吧。

前言

互聯(lián)網(wǎng)的不斷發(fā)展，網(wǎng)站應用的規(guī)模不斷擴大，常規(guī)的垂直應用架構已無法應對。

服務化的進一步發(fā)展，服務越來越多，服務之間的調(diào)用和依賴關系也越來越復雜，誕生了面向服務的架構體系(SOA)，

也因此衍生出了一系列相應的技術，如對服務提供、服務調(diào)用、連接處理、通信協(xié)議、序列化方式、服務發(fā)現(xiàn)、服務路由、日志輸出等行為進行封裝的服務框架。

就這樣分布式系統(tǒng)的服務治理框架就出現(xiàn)了，Dubbo也就這樣產(chǎn)生了。

概念

Dubbo 是一款高性能、輕量級的開源 RPC 框架、提供服務自動注冊、自動發(fā)現(xiàn)等高效治理方案，可以和 Spring 框架無縫集成。

簡單的說，dubbo就是個分布式服務框架，在有分布式需要的時候可以使用 dubbo 的框架，使用 dubbo 的好處：

1、透明化的遠程方法調(diào)用

2、軟負載均衡及容錯機制

3、服務自動注冊與發(fā)現(xiàn)

4、提供了完善的服務接口管理與監(jiān)控功能

架構圖

RPC

簡介

RPC全稱為 remote procedure call，即遠程過程調(diào)用。比如兩臺服務器 A 和 B，A 服務器上部署一個應用，B 服務器上部署一個應用，A 服務器上的應用想調(diào)用 B 服務器上的應用提供的方法，由于兩個應用不在一個內(nèi)存空間，不能直接調(diào)用，所以需要通過網(wǎng)絡來表達調(diào)用的語義和傳達調(diào)用的數(shù)據(jù)。

RPC 并不是一個具體的技術，而是指整個網(wǎng)絡遠程調(diào)用過程。

RPC 是一個泛化的概念，嚴格來說一切遠程過程調(diào)用手段都屬于 RP C范疇。各種開發(fā)語言都有自己的 RPC 框架。Java 中的 RPC 框架比較多，廣泛使用的有 RMI、Hessian、Dubbo 等。

原理

服務消費方(client)調(diào)用以本地調(diào)用方式調(diào)用服務?？蛻舳舜娓?client stub)接收到調(diào)用后負責將方法、參數(shù)等編碼成能在網(wǎng)絡中傳輸?shù)南Ⅲw。然后，客戶端存根找到服務地址后，將消息發(fā)送給服務端。

服務提供方(server)收到序列化后的消息，就按照解碼該消息。然后，根據(jù)解碼結果調(diào)用本地服務，執(zhí)行完畢后，將結果打包發(fā)送給消費方。

服務消費方收到執(zhí)行結果后，也是進行解碼后得到結果。

原理

使用場景

RPC 分布式服務，拆分應用進行服務化，提高開發(fā)效率，調(diào)優(yōu)性能，節(jié)省競爭資源

配置管理，解決服務的地址信息劇增，配置困難的問題

服務依賴，解決服務間依賴關系錯蹤復雜的問題

服務擴容，解決隨著訪問量的不斷增大，動態(tài)擴展服務提供方的機器的問題

核心功能

Remoting：遠程通訊，提供對多種 NIO 框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。

Cluster：服務框架，提供基于接口方法的透明遠程過程調(diào)用，包括多協(xié)議支持，以及軟負載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。

Registry：服務注冊中心，服務自動發(fā)現(xiàn): 基于注冊中心目錄服務，使服務消費方能動態(tài)的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

核心組件

Provider：服務的提供方

Consumer：調(diào)用遠程服務的服務消費方

Registry：服務注冊和發(fā)現(xiàn)的注冊中心

Monitor：統(tǒng)計服務調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心

Container：服務運行容器

組件

服務注冊與發(fā)現(xiàn)

流程如下：

1、Provider(提供者)綁定指定端口并啟動服務

2、供者連接注冊中心，并發(fā)本機 IP、端口、應用信息和提供服務信息發(fā)送至注冊中心存儲

3、Consumer(消費者)，連接注冊中心 ，并發(fā)送應用信息、所求服務信息至注冊中心

4、注冊中心根據(jù)消費者所求服務信息匹配對應的提供者列表發(fā)送至Consumer 應用緩存。

5、Consumer 在發(fā)起遠程調(diào)用時基于緩存的消費者列表擇其一發(fā)起調(diào)用。

6、Provider 狀態(tài)變更會實時通知注冊中心、在由注冊中心實時推送至Consumer設計的原因：

Consumer 與 Provider 解偶，雙方都可以橫向增減節(jié)點數(shù)。注冊中心對本身可做對等集群，可動態(tài)增減節(jié)點，并且任意一臺宕掉后，將自動切換到另一臺

7、去中心化，雙方不直接依懶注冊中心，即使注冊中心全部宕機短時間內(nèi)也不會影響服務的調(diào)用

8、服務提供者無狀態(tài)，任意一臺宕掉后，不影響使用

流程

服務治理

治理原因

Dubbo的服務治理主要原因：

1、過多的服務 URL 配置困難。

2、負載均衡分配節(jié)點壓力過大的情況下也需要部署集群。

3、服務依賴混亂，啟動順序不清晰。

4、過多服務導致性能指標分析難度較大，需要監(jiān)控。

主要特性

透明遠程調(diào)用：就像調(diào)用本地方法一樣調(diào)用遠程方法;只需簡單配置，沒有任何 API 侵入

負載均衡機制：Client 端 LB，可在內(nèi)網(wǎng)替代 F5 等硬件負載均衡器

容錯重試機制：服務 Mock 數(shù)據(jù)，重試次數(shù)、超時機制等

自動注冊發(fā)現(xiàn)：注冊中心基于接口名查詢服務提 供者的 IP 地址，并且能夠平滑添加或刪除服務提供者

性能日志監(jiān)控：Monitor 統(tǒng)計服務的調(diào)用次調(diào)和調(diào)用時間的監(jiān)控中心

服務治理中心：路由規(guī)則，動態(tài)配置，服務降級，訪問控制，權重調(diào)整，負載均衡，等手動配置

自動治理中心：無，比如：熔斷限流機制、自動權重調(diào)整等(因此可以搭配SpringCloud的熔斷機制等進行開發(fā))

服務治理

架構設計

整體架構

先看下 Dubbo 的整體架構圖：

圖例說明：

整體架構

圖中左邊淡藍背景的為服務消費方使用的接口，右邊淡綠色背景的為服務提供方使用的接口，位于中軸線上的為雙方都用到的接口。

圖中從下至上分為十層，各層均為單向依賴，右邊的黑色箭頭代表層之間的依賴關系，每一層都可以剝離上層被復用，其中，Service 和 Config 層為 API，其它各層均為 SPI。

圖中綠色小塊的為擴展接口，藍色小塊為實現(xiàn)類，圖中只顯示用于關聯(lián)各層的實現(xiàn)類。

圖中藍色虛線為初始化過程，即啟動時組裝鏈，紅色實線為方法調(diào)用過程，即運行時調(diào)時鏈，紫色三角箭頭為繼承，可以把子類看作父類的同一個節(jié)點，線上的文字為調(diào)用的方法。

各層說明

config 配置層：對外配置接口，以 ServiceConfig, ReferenceConfig 為中心，可以直接初始化配置類，也可以通過 spring 解析配置生成配置類

proxy 服務代理層：服務接口透明代理，生成服務的客戶端 Stub 和服務器端 Skeleton,以ServiceProxy 為中心，擴展接口為 ProxyFactory

registry 注冊中心層：封裝服務地址的注冊與發(fā)現(xiàn)，以服務 URL 為中心，擴展接口為RegistryFactory, Registry, RegistryService

cluster 路由層：封裝多個提供者的路由及負載均衡，并橋接注冊中心，以 Invoker 為中心，擴展接口為 Cluster, Directory, Router, LoadBalance

monitor 監(jiān)控層：RPC 調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以 Statistics 為中心，擴展接口為MonitorFactory, Monitor, MonitorService

protocol 遠程調(diào)用層：封裝 RPC 調(diào)用，以 Invocation, Result 為中心，擴展接口為 Protocol, Invoker, Exporter

exchange 信息交換層：封裝請求響應模式，同步轉異步，以 Request, Response 為中心，擴展接口為 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer

transport 網(wǎng)絡傳輸層：抽象 mina 和 netty 為統(tǒng)一接口，以 Message 為中心，擴展接口為 Channel, Transporter, Client, Server, Codec

serialize 數(shù)據(jù)序列化層：可復用的一些工具，擴展接口為 Serialization, ObjectInput, ObjectOutput, ThreadPool

主要模塊

dubbo-common 公共邏輯模塊，包括 Util 類和通用模型。

dubbo-remoting 遠程通訊模塊，相當于 Dubbo 協(xié)議的實現(xiàn)，如果 RPC 用 RMI 協(xié)議則不需要使用此包。

dubbo-rpc 遠程調(diào)用模塊，抽象各種協(xié)議，以及動態(tài)代理，只包含一對一的調(diào)用，不關心集群的管理。

dubbo-cluster 集群模塊，將多個服務提供方偽裝為一個提供方，包括：負載均衡、容錯、路由等，集群的地址列表可以是靜態(tài)配置的，也可以是由注冊中心下發(fā)。

dubbo-registry 注冊中心模塊，基于注冊中心下發(fā)地址的集群方式，以及對各種注冊中心的抽象。

dubbo-monitor 監(jiān)控模塊，統(tǒng)計服務調(diào)用次數(shù)，調(diào)用時間的，調(diào)用鏈跟蹤的服務。

dubbo-config 配置模塊，是 Dubbo 對外的 API ，用戶通過 Config 使用 Dubbo ，隱藏 Dubbo 所有細節(jié)。

dubbo-container 容器模塊，是一個 Standalone 的容器，以簡單的 Main 加載 Spring 啟動，因為服務通常不需要 Tomcat/JBoss 等 Web 容器的特性，沒必要用 Web 容器去加載服務。

主要模塊

調(diào)用方式

異步調(diào)用

基于 NIO 的非阻塞實現(xiàn)并行調(diào)用，客戶端不需要啟動多線程即可完成并行調(diào)用多個遠程服務，相對多線程開銷較小。

異步調(diào)用

本地調(diào)用

使用了Injvm協(xié)議，是一個偽協(xié)議，它不開啟端口，不發(fā)起遠程調(diào)用，只在JVM內(nèi)直接關聯(lián)，但執(zhí)行Dubbo的Filter鏈。

Define injvm protocol:

Set default protocol:

Set service protocol:

Use injvm first:(服務暴露與服務引用都需要聲明injvm=“true”)

 
 
 
 

  
  
  
  

  
  
  
  

  
  
  
  
或
  
  
  
  
 　　
 
 
 
 

容錯機制

調(diào)用流程

1、Cluster 將 Directory 中的多個 Invoker 偽裝成一個Invoker，對上層透明，偽裝過程包含了容錯邏輯。

2、Router 負責從多個 Invoker 中按路由規(guī)則選出子集，比如讀寫分離，應用隔離等。

3、LoadBalance 負責從多個 Invoker 中選出具體的一個用于本次調(diào)用，選的過程包含了負載均衡算法。

調(diào)用流程

容錯策略

Dubbo 官網(wǎng)提出總共有六種容錯策略

1、Failover Cluster

失敗自動切換，當出現(xiàn)失敗，重試其它服務器。(默認)

2、Failfast Cluster

快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

3、Failsafe Cluster

失敗安全，出現(xiàn)異常時，直接忽略。通常用于寫入審計日志等操作。

4、Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。通常用于消息通知操作。

5、Forking Cluster

并行調(diào)用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過 forks=”2”來設置最大并行數(shù)。

6、Broadcast Cluster

廣播調(diào)用所有提供者，逐個調(diào)用，任意一臺報錯則報錯。(2.1.0 開始支持) 通常用于通知所有提供者更新緩存或日志等本地資源信息。

總結：在實際應用中查詢語句容錯策略建議使用默認 Failover Cluster，而增刪改建議使用 Failfast Cluster 或者使用 Failover Cluster(retries=”0”)策略，防止出現(xiàn)數(shù)據(jù)重復添加等等其它問題!建議在設計接口時候把查詢接口方法單獨做一個接口提供查詢。

連接方式

Dubbo 的客戶端和服務端有三種連接方式，分別是：廣播、直連和使用Zookeeper注冊中心。

Dubbo 廣播

這種方式是dubbo官方入門程序所使用的連接方式，但是這種方式有很多問題，在企業(yè)開發(fā)中不使用廣播的方式。

服務端配置：

客戶端配置：

Dubbo 直連

這種方式在企業(yè)中一般在開發(fā)中環(huán)境中使用，但是生產(chǎn)環(huán)境很少使用，因為服務是直接調(diào)用，沒有使用注冊中心，很難對服務進行管理。Dubbo 直連，首先要取消廣播，然后客戶端直接到指定需要的服務的 url 獲取服務即可。

服務端配置：

 
 
 
 

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  
<--  -->
  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

 
 
 
 

客戶端配置：

 
 
 
 

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  
<--  -->
  
  
  
  

  
  
  
  

  
  
  
  

 
 
 
 

zookeeper 注冊中心

Dubbo 注冊中心和廣播注冊中心配置類似，不過需要指定注冊中心類型和注冊中心地址，這個時候就不是把服務信息進行廣播了，而是告訴給注冊中心進行管理，這個時候我們就需要有一個注冊中心，官方推薦使用 zookeeper 作為注冊中心。

Zookeeper 注冊中心

注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者在啟動時與注冊中心交互，消費者不斷的發(fā)起請求獲取服務信息，注冊中心不轉發(fā)請求，壓力較小

服務端配置：

客戶端配置：

 
 
 
 

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  

  
  
  
  
<--  -->
  
  
  
  
    
  
  
  
  

  
  
  
  

  
  
  
  

 
 
 
 

策略

負載均衡策略

1、Random LoadBalance，隨機(默認的負載均衡策略)

RandomLoadBalance 是加權隨機算法的具體實現(xiàn)，可以完全隨機，也可以按權重設置隨機概率。

2、RoundRobin LoadBalance，輪循

可以輪詢和加權輪詢。存在響應慢的提供者會累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調(diào)到第二臺時就卡在那，久而久之，所有請求都卡在調(diào)到第二臺上。

3、LeastActive LoadBalance，最少活躍調(diào)用數(shù)

活躍調(diào)用數(shù)越小，表明該服務提供者效率越高，單位時間內(nèi)可處理更多的請求。此時應優(yōu)先將請求分配給該服務提供者。

4、ConsistentHash LoadBalance，一致性 Hash

一致性 Hash 算法，相同參數(shù)的請求一定分發(fā)到一個 provider 上去。provider 掛掉的時候，會基于虛擬節(jié)點均勻分配剩余的流量，抖動不會太大。

集群容錯策略

1、failover cluster(默認)

失敗自動切換，調(diào)用失敗時，自動重試其他機器。通常用于讀操作，但重試會帶來更長延遲。

2、Failfast Cluster

快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

3、Failsafe Cluster

失敗安全，出現(xiàn)異常時，直接忽略。通常用于寫入審計日志等操作。

4、Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。通常用于消息通知操作。

5、Forking Cluster

并行調(diào)用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。

動態(tài)代理策略

默認使用 javassist 動態(tài)字節(jié)碼生成，創(chuàng)建代理類。也可以通過 spi 擴展機制配置自己的動態(tài)代理策略。

集群容錯方案

• 配置說明，方案配置方式，優(yōu)先使用消費端配置

• 盡量在只在服務端進行配置
• cluster類型均為小寫
• 默認為FailoverCluster失敗切換方案

集群容錯方案support

FailoverCluster(默認)：失敗切換

場景：調(diào)用失敗后切換其他服務

配置：

代碼實現(xiàn)邏輯：

1. 根據(jù)負載均衡策略選出需要調(diào)用的服務實例，排除已調(diào)用的

2. 執(zhí)行選出的實例，并將其保存到已調(diào)用列表中

3. 執(zhí)行實例成功即返回

4. 執(zhí)行實例不成功，為到最大重試次數(shù)則執(zhí)行第一步，否則拋出RpcException異常

FailbackCluster：失敗重試

場景：調(diào)用失敗時記錄失敗請求，定時重發(fā)

配置：

代碼實現(xiàn)邏輯

1. 根據(jù)負載均衡策略選出需要調(diào)用的服務實例

2. 執(zhí)行選出的實例

3. 執(zhí)行實例成功即返回

4. 執(zhí)行異常則創(chuàng)建延時5秒的定時任務，并加入時間輪定時器，第一次需要進行定時器初始化，分為32個時間片，每1秒滾動一次，最大掛起任務默認100個，超出最大任務數(shù)時拋出RejectedExecutionException異常。

5. 重試執(zhí)行定時任務，次數(shù)超出最大執(zhí)行次數(shù)停止，并輸出error日志，默認為3次。

FailfastCluster：快速失敗

場景：調(diào)用失敗立即報錯

配置：

代碼實現(xiàn)邏輯

1. 根據(jù)負載均衡策略選出需要調(diào)用的服務實例

2. 執(zhí)行選出的實例

3. 執(zhí)行實例成功即返回，失敗拋出RpcException異常

FailsafeCluster：安全失敗

場景：調(diào)用失敗后忽略

配置：

代碼實現(xiàn)邏輯

1. 根據(jù)負載均衡策略選出需要調(diào)用的服務實例

2. 執(zhí)行選出的實例

3. 執(zhí)行實例成功即返回，失敗輸出error日志，并返RpcResult，視為忽略。

ForkingCluster：并發(fā)處理

場景：并發(fā)調(diào)用指定數(shù)量的服務，一個成功則返回，對實時性要求高的場景，要求快速返回，需要使用更多服務器資源。

配置：

代碼實現(xiàn)邏輯

1. 根據(jù)負載均衡策略選出幾個不同的服務實例

2. 并發(fā)執(zhí)行選出的幾個實例，并將返回結果放入堵塞隊列中

3. 返回堵塞隊列中的第一個值，如規(guī)定時間內(nèi)未獲取到隊列中的值或獲取到異常值則返回RPC異常。

BroadcastCluster：廣播

場景：廣播方式逐個調(diào)用服務提供者，有一個報錯則返回錯誤，多用于通知服務提供者更新本地資源信息，如緩存，日志等。

配置：

代碼實現(xiàn)邏輯

1. 循環(huán)逐個執(zhí)行所有服務實例信息

2. 保存一份返回結果和異常信息

3. 執(zhí)行完全部實例后，如異常信息不為空，則拋出異常信息，否則返回最后一個實例的結果。

AvailableCluster：可用服務

場景：調(diào)用第一個可用服務

配置：

代碼實現(xiàn)邏輯

1. 循環(huán)所有服務實例信息

2. 執(zhí)行第一個可用的實例，并返回結果

3. 如無可用實例則返回RpcException異常

MergeableCluster：合并處理

場景：返回合并或疊加處理結果

配置：

代碼實現(xiàn)邏輯

1. 判斷merger，為空、null、0、false、N/A是執(zhí)行第一個可用服務并返回結果，無可用則執(zhí)行第一個實例，并返回結果。

2. 獲取方法實例的返回類型

3. 異步調(diào)用所有實例，并將異步結果Result存儲到結果集中，返回異常輸出error日志

4. 結果集為空返回 RpcException，大小為 1時返回第一個Result

5. 當merger的第一個字符為“.”時，判斷當 merger 實例返回類型不為void,且返回類型必須是結果集中第一個返回類型的父類型或相同類型時，循環(huán)執(zhí)行merger實例，每一次都傳入上一次的返回結果，最終返回獲取最后一次結果，非上述情況時循環(huán)執(zhí)行merger實例，返回結果集中的第一個結果。

6. 當merger為true或default時使用Dubbo默認合并器，否則使用自定義merger合并器，合并后返回

RegistryAwareCluster:默認標識、注冊標識

場景：調(diào)用注冊默認標識的服務

配置：

代碼實現(xiàn)邏輯

1.8 循環(huán)所有服務實例信息

2. 執(zhí)行第一個可用的實例且default為true的實例

3. 無默認實例則執(zhí)行第一個可用的實例

4. 無可用的實例則拋出RpcException異常

主要配置

配置應用信息：

配置注冊中心相關信息：

配置服務協(xié)議：

配置所有暴露服務缺省值：

配置暴露服務：

配置所有引用服務缺省值：

注解配置：

 
 
 
 

  
  
  
  
com.alibaba.dubbo.config.annotation.Service 配置暴露服務
  
  
  
  

  
  
  
  
com.alibaba.dubbo.config.annotation.Reference配置引用服務
 
 
 
 

超時設置

Dubbo消費端

全局超時配置

指定接口以及特定方法超時配置

Dubbo服務端

全局超時配置

指定接口以及特定方法超時配置

支持協(xié)議

1、Dubbo 協(xié)議(官方推薦協(xié)議)

優(yōu)點：采用NIO復用單一長連接，并使用線程池并發(fā)處理請求，減少握手和加大并發(fā)效率，性能較好(推薦使用)

缺點：大文件上傳時,可能出現(xiàn)問題(不使用 Dubbo 文件上傳)

2、RMI(Remote Method Invocation)協(xié)議

優(yōu)點:JDK 自帶的能力?？膳c原生 RMI 互操作，基于 TCP 協(xié)議

缺點:偶爾連接失敗.

3、Hessian協(xié)議

優(yōu)點:可與原生 Hessian 互操作，基于 HTTP 協(xié)議

缺點:需 hessian.jar 支持，http 短連接的*開銷大8

常用設計模式

Dubbo 框架在初始化和通信過程中使用了多種設計模式，可靈活控制類加載、權限控制等功能。

工廠模式

Provider 在 export 服務時，會調(diào)用 ServiceConfig 的 export 方法。ServiceConfig 中有個字段：

 
 
 
 

  
  
  
  
private static final Protocol protocol =
  
  
  
  
ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
 
 
 
 

Dubbo 里有很多這種代碼。這也是一種工廠模式，只是實現(xiàn)類的獲取采用了 JDK SPI 的機制。這么實現(xiàn)的優(yōu)點是可擴展性強，想要擴展實現(xiàn)，只需要在 classpath下增加個文件就可以了，代碼零侵入。另外，像上面的 Adaptive 實現(xiàn)，可以做到調(diào)用時動態(tài)決定調(diào)用哪個實現(xiàn)，但是由于這種實現(xiàn)采用了動態(tài)代理，會造成代碼調(diào)試比較麻煩，需要分析出實際調(diào)用的實現(xiàn)類。

裝飾器模式

Dubbo 在啟動和調(diào)用階段都大量使用了裝飾器模式。以 Provider 提供的調(diào)用鏈為例，具體的調(diào)用鏈代碼是在 ProtocolFilterWrapper 的buildInvokerChain 完成的，具體是將注解中含有 group=provider 的 Filter 實現(xiàn)，按照 order 排序，最后的調(diào)用順序是：

 
 
 
 

  
  
  
  
EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->
  
  
  
  
ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->
  
  
  
  
ExceptionFilter
 
 
 
 

更確切地說，這里是裝飾器和責任鏈模式的混合使用。例如，EchoFilter 的作用是判斷是否是回聲測試請求，是的話直接返回內(nèi)容，這是一種責任鏈的體現(xiàn)。而像ClassLoaderFilter 則只是在主功能上添加了功能，更改當前線程的 ClassLoader，這是典型的裝飾器模式。

觀察者模式

Dubbo 的 Provider 啟動時，需要與注冊中心交互，先注冊自己的服務，再訂閱自己的服務，訂閱時，采用了觀察者模式，開啟一個 listener。注冊中心會每 5 秒定時檢查是否有服務更新，如果有更新，向該服務的提供者發(fā)送一個 notify 消息，provider 接受到 notify 消息后，即運行 NotifyListener 的 notify 方法，執(zhí)行監(jiān)聽器方法。

動態(tài)代理模式

Dubbo 擴展 JDK SPI 的類 ExtensionLoader 的 Adaptive 實現(xiàn)是典型的動態(tài)代理實現(xiàn)。Dubbo 需要靈活地控制實現(xiàn)類，即在調(diào)用階段動態(tài)地根據(jù)參數(shù)決定調(diào)用哪個實現(xiàn)類，所以采用先生成代理類的方法，能夠做到靈活的調(diào)用。生成代理類的代碼是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理類的主要邏輯是，獲取 URL 參數(shù)中指定參數(shù)的值作為獲取實現(xiàn)類的 key

工作流程

整體流程：

第一步：provider 向注冊中心去注冊

第二步：consumer 從注冊中心訂閱服務，注冊中心會通知 consumer 注冊好的服務

第三步：consumer 調(diào)用 provider

第四步：consumer 和 provider 都異步通知監(jiān)控中心

流程圖

總結

最后用一張圖來形象的模擬 Dubbo 的使用：

使用

以上只是我總結的一些關于 dubbo 最基礎的原理及使用介紹，至于代碼編寫過程的 bug 處理經(jīng)驗，環(huán)境搭建、項目布局等等問題，需要我們在平時開發(fā)中，將系統(tǒng)知識與實戰(zhàn)經(jīng)驗相結合去總結，這樣才能真正的去掌握這項技術點。

Dubbo 目前是我用到過的最多的分布式框架，寫出來的內(nèi)容也是最多的，不過由于Dubbo用的太多，而 SpringCloud 難度比 Dubbo 要小很多，現(xiàn)在大部分項目都即將開始轉投到了 SpringCloud 上面，后面也會出更多的 SpringCloud 相關的文章。

新聞標題：微服務面試必問的Dubbo，這么詳細還怕自己找不到工作？
URL分享：http://www.5511xx.com/article/dhhshhj.html