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();
主機繫結
-
通過<dubbo:protocol host配置的地址去找
<dubbo:protocol name="dubbo" port="20880" host="192.168.4.169"/> -
host = InetAddress.getLocalHost().getHostAddress() - 通過socket發起連線連線到註冊中心的地址。再獲取連線過去以後本地的ip地址
-
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