dubbo2

啓動服務檢查

若是提供方沒有啓動的時候，默認會去檢測所依賴的服務是否正常提供服務

好比說order依賴於pay，必須pay啓動了，纔可以使用order

若是check爲false，表示啓動的時候不去檢查。當服務出現循環依賴的時候(兩個服務彼此依賴)，check設置成false

dubbo:reference 屬性： check 默認值是true 、false

dubbo:consumer check=」false」 沒有服務提供者的時候，報錯

dubbo:registry check=false 註冊訂閱失敗報錯

dubbo:provider

多協議支持

dubbo支持的協議： dubbo、RMI、hessian、webservice、http、Thrift、memcached、redis、rest

老項目協議沒法改變，經過配置協議來解決

hessian協議

引入jar包

<dependency>
  <groupId>com.caucho</groupId>
  <artifactId>hessian</artifactId>
  <version>4.0.38</version>
</dependency>
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>servlet-api</artifactId>
  <version>2.5</version>
</dependency>
<dependency>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty</artifactId>
  <version>6.1.26</version>
</dependency>

修改provider.xml

<!--增長hessian協議-->
<dubbo:protocol name="hessian" port="8090" server="jetty"/>

指定service服務的協議版本號

<dubbo:service interface="com.zzjson.IOrderServices" ref="orderService" protocol="hessian"/>

消費端改造

<dubbo:reference interface="com.zzjson.IOrderServices" id="orderServices" protocol="Hessain"/>

dubbo使用spring純註解異常解決方案：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>2.5.3</version>
    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
        </exclusion>
    </exclusions>
</dependency

hessian%3A%2F%2F192.168.4.169%3A8080%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61276%26server%3Djetty%26side%3Dprovider%26timestamp%3D1551776679018

dubbo%3A%2F%2F192.168.4.169%3A20880%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61276%26side%3Dprovider%26timestamp%3D1551776679988

多註冊中心支持

多版本支持

客戶端調用的時候

dubbo%3A%2F%2F192.168.4.169%3A20880%2Fcom.zzjson.IOrderServices2%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D1.0%26side%3Dprovider%26timestamp%3D1551778295256%26version%3D1.0

hessian%3A%2F%2F192.168.4.169%3A8080%2Fcom.zzjson.IOrderServices2%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D1.0%26server%3Djetty%26side%3Dprovider%26timestamp%3D1551778294832%26version%3D1.0

dubbo%3A%2F%2F192.168.4.169%3A20880%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D2.0%26side%3Dprovider%26timestamp%3D1551778294284%26version%3D2.0

hessian%3A%2F%2F192.168.4.169%3A8080%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D2.0%26server%3Djetty%26side%3Dprovider%26timestamp%3D1551778293346%26version%3D2.0

異步調用

​ 調用接口過程可能比較慢，咱們有時候並不須要同步等待，原理使用的是future異步回調機制

async="true"表示接口異步返回

hessian協議，使用async異步回調會報錯

Future<DoOrderResponse> future = RpcContext.getContext().getFuture();
System.out.println("aaa");
DoOrderResponse response = future.get();

主機綁定

1. 經過<dubbo:protocol host配置的地址去找

   <dubbo:protocol name="dubbo" port="20880" host="192.168.4.169"/>

2. host = InetAddress.getLocalHost().getHostAddress()
3. 經過socket發起鏈接鏈接到註冊中心的地址。再獲取鏈接過去之後本地的ip地址
4. host = NetUtils.getLocalHost();

   serviceconfig .class

dubbo服務只訂閱

​ 測試過程當中，正在開發，有問題，註冊到註冊中心了，只須要訂閱服務，只訂閱，不註冊,開發的時候設置爲false，只訂閱，不註冊

dubbo服務只註冊

​ 只提供服務，不訂閱服務

​ 多註冊中心狀況下，服務發佈到兩個註冊中心，其中一個註冊中心尚未發佈，可是須要註冊，dubbo只會選擇其中一個可用的去使用

<dubbo:registry subscribe="false"/>

負載均衡

​ 在集羣負載均衡時，Dubbo提供了多種均衡策略，缺省爲random隨機調用。能夠自行擴展負載均衡策略

​ http://dubbo.apache.org/zh-cn...

Random LoadBalance

​ 隨機，按權重設置隨機機率。

​ 在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance

​ 輪循，按公約後的權重設置輪循比率。

​ 存在慢的提供者累積請求的問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

LeastActive LoadBalance

​ 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。

​ 使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

ConsistentHash LoadBalance

​ 一致性Hash，相同參數的請求老是發到同一提供者。

​ 當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。

鏈接超時timeout

​ 毫秒爲單位 默認 1000

​ 必需要設置服務的處理的超時時間

集羣容錯

​

修改集羣容錯方式

<dubbo:service cluster="failsafe" />

Failover cluster

​ 失敗的時候自動切換並重試其餘服務器。 經過retries=2。 來設置重試次數

Failfast cluster

​ 快速失敗，只發起一次調用

​ 寫操做。好比新增記錄的時候， 非冪(服務調用後端某一接口發起屢次結果不變)等請求

​ insert 惟一的key,影響行數只會影響一行

Failsafe cluster

​ 失敗安全。 出現異常時，直接忽略異常

​ 寫日誌，不必定要日誌保存成功，失敗了不能影響主程序的運行

Failback cluster

​ 失敗自動恢復。 後臺記錄失敗請求，定時重發

​ 好比說消息通知，失敗了一直髮送

Forking cluster

​ 並行調用多個服務器，只要一個成功就返回。 只能應用在讀請求

會浪費服務器的資源

Broadcast cluster

​ 廣播調用全部提供者，逐個調用。其中一臺報錯就會返回異常

配置的優先級

若是消費端和服務端都設置了超時時間，那麼誰的優先級最大

消費端優先級別最高 – 服務端

Reference method>servicemethod>reference>service>consumer>provider

服務改造

• dubbo依賴spring版本是2.幾過低,更改依賴

優雅停機

​ Dubbo 是經過 JDK 的 ShutdownHook 來完成優雅停機的，因此若是用戶使用 kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有經過 kill PID 時，纔會執行。

原理

服務提供方

• 中止時，先標記爲不接收新請求，新請求過來時直接報錯，讓客戶端重試其它機器。
• 而後，檢測線程池中的線程是否正在運行，若是有，等待全部線程執行完成，除非超時，則強制關閉。

服務消費方

• 中止時，再也不發起新的調用請求，全部新的調用在客戶端即報錯。
• 而後，檢測有沒有請求的響應尚未返回，等待響應返回，除非超時，則強制關閉。

# dubbo.properties
dubbo.service.shutdown.wait=15000