dubbo概念

dubbo原理

dubbo應用場景

    Dubbo概念：

      Dubbo是一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分散式的需求，其實是不需要用的，只有在分散式的時候，才有dubbo這樣的分散式服務框架的需求。Dubbo預設協議採用單一長連線和NIO非同步通訊，適合於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況。

其核心部分包含：

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

     Dubbo原理：

     第一步start，就是將服務裝載容器中，然後準備註冊服務。和Spring中啟動過程類似，spring啟動時，將bean裝載進容器中的時候，首先要解析bean。所以dubbo也是先讀配置檔案解析服務。 

    解析服務： 

1）、基於dubbo.jar內的Meta-inf/spring.handlers配置，spring在遇到dubbo名稱空間時，會回撥DubboNamespaceHandler類。 
2）、所有的dubbo標籤，都統一用DubboBeanDefinitionParser進行解析，基於一對一屬性對映，將XML標籤解析為Bean物件。 
原始碼截圖： 
在ServiceConfig.export 或者ReferenceConfig.get 初始化時，將Bean物件轉會為url格式，將所以Bean屬性轉成url的引數。 
然後將URL傳給Protocol擴充套件點，基於擴充套件點的Adaptive機制，根據URL的協議頭，進行不同協議的服務暴露和引用。 


      暴露服務：

       只暴露服務埠，或者通過註冊中心暴露，基於擴充套件點的Adaptive機制，通過URL的“registry：//”協議頭識別，呼叫RegistryProtocol的export方法，將export引數中的提供者URL先註冊到註冊中心，再重新傳給Protocol擴充套件點進行暴露


     引用服務：

      直接應用服務埠，或者從註冊中心發現引用服務。
      基於擴充套件點的Adaptive機制，通過提供者URL的“dubbo：//”協議頭識別，就會呼叫DubboProtocol的refer（）方法，得到提供者引用。 然後RegistryProtocol將多個提供者引用，通過Cluster擴充套件點，偽裝成單個提供這引用返回。

提供服務的過程：

上圖是服務提供者暴露服務的主過程：

1.serviceconfig 封裝ref。然後將ProxyFactory類的getInvoker方法使用ref（真實類）封裝成一個AbstractProxyInvoker（代理）例項

2.Invoker轉換到Exporter的過程。Dubbo協議的Invoker轉為Exporter發生在DubboProtocol類的export方法，它主要是開啟socket偵聽服務，並接收客戶端發來的各種請求，通訊細節由dubbo自己實現。

服務消費者消費一個服務的詳細過程：

上圖是服務消費的主過程： 

        首先ReferenceConfig類的init方法呼叫Protocol的refer方法生成Invoker例項。接下來把Invoker轉為客戶端需要的介面。

       Dubbo應用場景：

1，rpc的分散式叢集支援：負載均衡是對外提供一個公共地址，請求過來時通過輪詢、隨機的形式來分攤壓力，掛一臺補一臺
2，結合zookeeper解耦：(提供者註冊和消費者訂閱)客戶端和服務端啟動的時候都會把自己的機器IP註冊到zookeeper上。客戶端會把zk上的服務端ip拉到磁碟上，並記錄哪些ip提供哪些服務（服務端啟動的時候暴露給zk）。
   然後呼叫的時候客戶端會根據ip呼叫服務端的服務，這時候即使zk掛掉也沒關係。
3：長連線通訊：nio通訊抽象封裝