分佈式服務框架：Dubbo

前言

Dubbo，阿里巴巴旗下的開源產品，以前由於團隊解散體中止了更新，不過最近我看maven倉庫又開始發佈新版本，估計開發團隊又回來繼續更新了

首先說下dubbo的簡介：
dubbo是分佈式服務治理框架，也是RPC遠程服務調用框架
什麼是服務治理呢，好比負責均衡，服務註冊，容錯機制等等
RPC遠程調用框架有不少，好比SpringCloud，dubbo，dubbox，Hessian等等

首先來看下官方給出的dubbo工做流程圖：

我來簡單講解下：（看不明白的先往下看，最後回來閱讀便會恍然大悟）

1.服務提供者把本身的IP，名稱等信息註冊到註冊中心
（默認使用zookeeper，所謂註冊就是在zookeeper上建立一個持久化節點，存儲本身的信息）

2.服務消費者訂閱註冊中心
（當消費者訂閱了，一旦註冊中心註冊了新節點，消費者就會立刻知道，這就是爲何用zookeeper的緣由，由於zookeeper有循環監聽事件的功能，這也是爲何能夠用redis作註冊中心，redis也有此功能）

3.消費者在註冊中心拿到服務提供者的IP等信息，而後再與提供者服務器鏈接，調用接口實現類

4.監控中心會監控操做的相關信息，並記錄

那麼怎樣才能最快的瞭解dubbo框架？我以爲code纔是最重要的
這裏用一個小項目來進行演示
最基本的demo有三個基本模塊：
1.服務提供者（provider）
2.服務消費者（consumer）
3.前二者的公用接口（api）
看下目錄結構：

註冊中心

首先安裝zookeeper，能夠參考個人另外一篇博客：分佈式協調服務：zookeeper
開啓zookeeper服務，打開2181端口

服務接口

單獨構建一個模塊，叫作api，只須要在此模塊中寫入共享接口：

package com.dubbo.api;

public interface UserService {
    public String test(Integer userId);
}

服務提供者

必須引入的maven庫和依賴api模塊

<dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>dubbo</artifactId>
            <version>2.5.8</version>
        </dependency>

        <dependency>
            <groupId>com.101tec</groupId>
            <artifactId>zkclient</artifactId>
            <version>0.10</version>
        </dependency>

        <dependency>
            <groupId>com.dubbo</groupId>
            <artifactId>api</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>

服務提供者模塊的配置文件：
dubbo-provider.xml

服務提供者應用信息，用於計算依賴關係
<dubbo:application name="provider" />  
  
向註冊中心暴露服務
<dubbo:registry address="zookeeper://127.0.0.1:2181" />

使用指定協議以及指定端口暴露服務
<dubbo:protocol name="dubbo" port="20880" />

聲明須要暴露的服務接口
<dubbo:service interface="com.dubbo.api.UserService" ref="UserService"/>

<bean id="UserService" class="com.dubbo.service.Impl.UserServiceImpl"/>

test類進行啓動：
providerTest.java

public class providerTest {
    public static void main(String[] args) throws IOException {
        ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("provider.xml");
        applicationContext.start();
        System.out.println("服務已啓動");
        System.in.read(); //讓程序阻塞
    }
}

請注意：provider中的實體類須要實現序列化，不然dubbo協議沒法傳輸

服務消費者

服務消費者模塊的配置文件：
dubbo-consume.xm

<dubbo:application name="consumer"/>

協議配置由服務提供方指定，消費方被動接受
 <dubbo:registry protocol="zookeeper" address="zookeeper://127.0.0.1:2181"/>

生成遠程服務代理，引用api的接口
 <dubbo:reference id="UserService" interface="com.dubbo.api.UserService"/>

消費者測試啓動類：
consumerTest.java

public class consumerTest {
    public static void main(String[] args) throws IOException {
        ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("consumer.xml");
        applicationContext.start();
        UserService userService = (UserService) applicationContext.getBean("UserService");
        String name = userService.test(1);
        System.out.println("========="+name+"=========");
        System.in.read();
    }
}

請注意：服務消費者要設置超時設置，不然可能沒法調用到數據量較大的接口

<dubbo:consumer timeout="5000"/>

測試啓動

打開zookeeper：zkServer.sh start
監控zookeeper日誌：tail -f zookeeper.out

運行providerTest.java

zookeeper日誌：

說明此服務提供者已在zookeeper註冊

啓動服務消費者：

說明經過dubbo框架的dubbo協議，成功遠程調用了consumer服務

dubbo的服務治理

容錯流程

先來看一張官方的圖：

節點解釋：

集羣提供了不少容錯方案（如：Failover,Failfast,Failsafe....)
缺省是Failover方案，也就是出現失敗時，調用其餘服務器的服務，獲取重試次數，參數retries，默認重試兩次

invoker（調用器）：他是Provider的service的抽象，封裝了provider的地址和service的接口

Directory（目錄）：至關於一個list，元素爲invuker實例，不一樣於list的是，它的元素是動態的

Router：進行路由的選擇

LoadBalance：負載均衡

容錯方案：
1.Failover Cluster
當出現失敗時，調用其餘服務器服務
設置調用次數：

<dubbo:service retries="2"/>
或者
<dubbo:reference retries="2"/>

2.Failfast Cluster
只容許發起一次調用，失敗當即報錯

3.Failsafe Cluster
異常安全處理，當出現異常時，直接忽略

4.Failback Cluster
失敗當即回滾

5.Forking Cluster
並行調用多個服務器服務，只要一個成功返回便可
經過 forks=「2」 設置並行數

6.Broadcast Cluster
廣播調用全部provider，遂個調用，任意一個失敗就報錯

容錯方案的模式選擇：

<dubbo:service cluster="failsafe"/>
或者
<dubbo:reference cluster="failsafe"/>

具體操做流程：

1.首先調用MockClusterInvoker.invoke方法，判斷是調用Mock功能仍是具體的集羣策略類

2.調用Directory.list獲取Invoker列表；

3.調用Router.route進行路由選擇；

4.LoadBalance進行負載均衡選擇；

5.最後獲取Invoker對象；

當全部的服務提供者都宕機，dubbo會啓動keepalived，不斷重啓service服務

負載均衡

官方給出了四種負載均衡策略
咱們能夠在dubbo-admin模塊使用圖形界面來進行策略選擇

在github上clone下dubbo源碼：dubbo

mvn命令(mvn package)打包dubbo-admin的war包
使用tomcat啓動：

能夠看到咱們剛纔啓動的兩個應用

選擇某服務的負載均衡策略：

與SpringCloud對比

相比於如今社區很是活躍的SpringClouddubbo沒有網關和斷路由等功能可是它支持多種協議，而SpringCloud只支持http協議而且SpringCloud逐漸成爲主流在中小型企業也廣泛使用SpringCloud，由於dubbo過重，許多功能須要本身實現雖然spring這麼厲害，但咱們仍是要支持國產