轉載地址來源於：https://www.cnblogs.com/darling2047/p/9765341.html
之前記錄了基於springboot的dubbo入門案例,今天在此基礎上記錄dubbo官網介紹的常用屬性配置,dubbo讀取我們配置的屬性時是有優先級的,優先級如下圖：
如圖所示，優先級的屬性依次為虛擬機參數>xml配置>dubbo.properties,虛擬機參數即程序啟動之前我們通過-D配置的dubbo屬性,xml配置即我們項目中自己寫的xml文件或者是springboot中的application.properties，當公共配置很簡單，沒有多注冊中心，多協議等情況，或者想多個 Spring 容器想共享配置的情況下可以用dubbo.properties作為缺省配置；需要注意的是我這里的測試用例都是寫在application.properties中,當然如果感覺不習慣,也可以跟普通maven項目一樣新建xml文件,在xml中進行配置，只是不要忘了在springboot的啟動類中添加@ImportResource(locations="xml路徑")注解來引入就行,下面開始記錄dubbo的常用配置；
一、啟動時檢查(check)
默認情況下dubbo是開啟自動檢查的,即當項目啟動時會自動檢查其依賴的服務是否開啟,如果沒開是會阻止spring的初始化的,即check=true;我們可以將check置為false來關閉啟動時檢查,如我們在測試或者對其他服務沒有依賴的時候可以關閉檢查;在springboot中我們可以進行如下配置來關閉啟動時檢查：
1、關閉某個服務的啟動檢查
在引用該服務的@Reference注解上添加check=false,即@Reference(check = false)
2、關閉所有服務的啟動時檢查
在application.properties中添加dubbo.consumer.check=false
二、超時(timeout,默認為1000)，重試次數(retries)
超時：當消費者調用提供者時由於網絡等原因有可能會造成長時間拿不到響應,而請求還在不斷的發過來這就有可能造成線程阻塞,使用timeout設置超時時間當超過該時間就會拋出異常；設置如下：
當只針對某個服務時：@Reference(timeout=XXX)
當針對所有服務時：dubbo.consumer.timeout=XXX
重試次數：當調用失敗或超時后重新嘗試調用的次數,其值不包含第一次
當只針對某個服務時：@Reference(retries=XXX)
當針對所有服務時:dubbo.consumer.retries=XXX
三、多版本(灰色發布)
當出現系統版本升級時,新版本有可能不夠穩定,這時候可以通過設置version來進行平滑的過渡,下面是dubbo官網的版本遷移步驟：
在低壓力時間段，先升級一半提供者為新版本，再將所有消費者升級為新版本，然后將剩下的一半提供者升級為新版本
而新舊版本我們可以通過version來定義,假設老版本的version=1.0.0新版本的version=2.0.0；
老版本服務提供者：@Service(version='1.0.0')
新版本服務提供者：@Service(version='2.0.0')
老版本服務消費者：@Reference(version='1.0.0')
新版本服務消費者：@Reference(version='2.0.0')
這樣新舊版本就完美錯開,只會調用version對應的服務,如果調用的時候不需要區分版本號,則進行如下配置：@Reference(version='*'),這樣dubbo會默認在新老版本中隨機調用
四、本地存根(stub)
正常情況下,服務搭建成功后服務的實現一般都在服務端,但有時候我們可能需要在客戶端做些邏輯操作,比如參數驗證,緩存處理以及調用失敗后偽造容錯數據的處理等等,這時候我們就需要用到dubbo的本地存根機制,他能在遠程服務調用前在客戶端進行相關的邏輯操作，具體步驟如下：
1、在客戶端寫一個遠程調用服務的實現,並生成有參構造參數為遠程服務,代碼如下：
[url=]
 [/url]
package com.darling.boot.order.service;import com.darling.pubIn.bean.User;importcom.darling.pubIn.service.UserService;import org.springframework.util.StringUtils;import java.util.List;/** * @author 董琳琳 * @date 2018/10/10 15:11 * @description userService的本地存根實現 */public class UserServiceStub implementsUserService{ private final UserService userService; /** * 有參構造 dubbo會自動將遠程Userservice注入進來 * @paramuserService */ public UserServiceStub(UserService userService) { this.userService = userService; } /** * 在遠程調用前可以進行判斷 * @param userId * @return */ @Override public List<User> getUserAddressList(String userId) { // 如果userId不為空則進行遠程調用 否則不調 if(!StringUtils.isEmpty(userId)) { returnuserService.getUserAddressList(userId); } return null; } @Override public void sayHello() { }}[url=]
[/url]
2、進行存根配置
在客戶端調用遠程服務的注解上添加stub,值為我們客戶端實現的遠程服務類的全路徑名,如@Reference(stub = "com.darling.boot.order.service.UserServiceStub")
五、負載均衡
dubbo提供了四種負載均衡策略,分別是：
1、Random LoadBalance 按權重的隨機負載均衡,也是dubbo默認的負載均衡策略
2、RoundRobin LoadBalance 按權重的輪詢負載均衡,即在輪詢的基礎上添加了權重的策略
3、LeastActive LoadBalance 最少活躍調用數,相同活躍數的隨機訪問,活躍數指調用前后的計數差即響應時間的長短;這種策略可以使響應慢的提供者收到的請求較少,大大提供系統性能
4、ConsistentHash LoadBalance 一致性哈希；相同參數的請求總是發到同一提供者
負載均衡的配置：@Reference(loadbalance = "roundrobin")，loadbalance 的值即為四種負載均衡的名稱,全部小寫
六、服務降級
當服務器壓力過大時,我們可以通過服務降級來使某些非關鍵服務的調用變得簡單,可以對其直接進行屏蔽,即客戶端不發送請求直接返回null,也可以正常發送請求當請求超時或不可達時再返回null;服務降級的相關配置可以直接在dubbo-admin的監控頁面進行配置;通常是基於消費者來配置的,在dubbo-admin找到對應的消費者想要降級的服務,點擊其后面的屏蔽或容錯按鈕即可生效；其中,屏蔽按鈕點擊表示放棄遠程調用直接返回空,而容錯按鈕點擊表示繼續嘗試進行遠程調用當調用失敗時再返回空
七、集群容錯
在集群調用失敗時，Dubbo 提供了多種容錯方案，缺省為 failover 重試。下面列舉dubbo支持的容錯策略：
Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但重試會帶來更長延遲。可通過 retries="XXX" 來設置重試次數(不含第一次)。
Failfast Cluster：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用於寫入審計日志等操作。
Failback Cluster：失敗自動恢復，后台記錄失敗請求，定時重發。通常用於消息通知操作。
Forking Cluster：並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設置最大並行數。
Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一台報錯則報錯 [2]。通常用於通知所有提供者更新緩存或日志等本地資源信息。
配置如下：@Reference(cluster = "failsafe")這里表示使用失敗安全的容錯策略
還有一種springcloud默認的容錯策略Hystrix；Hystrix旨在通過控制那些訪問遠程系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備擁有回退機制和斷路器功能的線程和信號隔離，請求緩存和請求打包，以及監控和配置等功能,下面介紹如何整合Hystrix：
1、分別在提供者和消費者添加Hystrix依賴,或者直接在公共接口層添加,代碼如下：
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-hystrix</artifactId><version>1.4.4.RELEASE</version></dependency>
2、在提供者和消費者的啟動類上添加@EnableHystrix來啟用hystrix；
3、在提供者需要容錯的方法上添加@HystrixCommand表示使用hystrix代理：
[url=]
[/url]
@HystrixCommand // 開啟Hystrix代理 @Override public List<User> getUserAddressList(String userId) { ArrayList list = new ArrayList(); list.add(new User(3,"韋德3","男",36,"邁阿密")); list.add(new User(23,"詹姆斯23","男",34,"洛杉磯")); list.add(new User(24,"科比24","男",39,"洛杉磯"));// try {// Thread.sleep(5000);// } catch (InterruptedException e) {// e.printStackTrace();// } return list; } [url=]
[/url]
4、在消費者需要容錯的方法上添加@HystrixCommand,還可以給其添加屬性,表示調用出錯后處理錯誤的方法：
[url=]
[/url]
package com.darling.boot.order.service;import com.alibaba.dubbo.config.annotation.Reference;importcom.darling.pubIn.bean.User;import com.darling.pubIn.service.OrderService;importcom.darling.pubIn.service.UserService;import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;importorg.springframework.stereotype.Service;import java.util.List;/** * @author 董琳琳 * @date 2018/10/8 11:42 * @description */@Servicepublic class OrderServiceimpl implements OrderService { @Reference(version = "*",stub = "com.darling.boot.order.service.UserServiceStub",cluster = "") UserService service; @HystrixCommand(fallbackMethod = "handlerException") @Override public List<User> initOrder(String userId) { returnservice.getUserAddressList(userId); } /** * 表示調用出錯后進行的處理,這里沒有處理直接返回null * @param userId *@return */ public List<User> handlerException(String userId) { return null; }}[url=]
[/url]
在整合hystrix 時發現一個奇怪的現象,就是當你一旦在消費端整合hystrix 后,只要你發送的請求沒有進行遠程調用,即使該請求沒有出錯並且正常返回了還是會進入fallbackMethod指定的容錯方法,百思不得其解, 准備后期去網上問問大神們
由於時間關系,我對照官網就實現了以上幾種配置,還有許多其他配置沒有使用,希望在以后的工作中能有機會用到,到時候再回來記錄,這篇筆記的dubbo屬性配置有個值得注意的地方,就是我幾乎所有的配置都是在引用服務的注解@Reference上進行的,而dubbo支持多種配置,除了全局配置還可以精確到給具體的類具體的方法進行配置,也可以給提供者和消費者進行配置,下面記錄dubbo的配置原則：
dubbo推薦在Provider上盡量多配置Consumer端屬性,原因如下：
1、作服務的提供者，比服務使用方更清楚服務性能參數，如調用的超時時間，合理的重試次數，等等
2、在Provider配置后，Consumer不配置則會使用Provider的配置值，即Provider配置可以作為Consumer的缺省值。否則，Consumer會使用Consumer端的全局設置，這對於Provider不可控的，並且往往是不合理的
配置優先級： 方法級優先，接口級次之，全局配置再次之；如果級別一樣，則消費方優先，提供方次之
|
