0. 什麼是高可用
高可用HA（High Availability）是分佈式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。
假設系統一直能夠提供服務，我們說系統的可用性是100%；如果系統每運行100個時間單位，會有1個時間單位無法提供服務，我們說系統的可用性是99%；很多公司的高可用目標是4個9，也就是99.99%，這就意味着，系統的年停機時間爲8.76個小時。
下面介紹配置dubbo的高可用的一些實踐方法。
1. zookeeper宕機與dubbo直連
在實際生產中，假如zookeeper註冊中心宕掉，一段時間內服務消費方還是能夠調用提供方的服務的，實際上它使用的本地緩存進行通訊，這只是dubbo健壯性的一種。
dubbo的健壯性表現：
- 監控中心宕掉不影響使用，只是丟失部分採樣數據
- 數據庫宕掉後，註冊中心仍能通過緩存提供服務列表查詢，但不能註冊新服務
- 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另一臺
- 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊
- 服務提供者無狀態，任意一臺宕掉後，不影響使用
- 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
註冊中心的作用在於保存服務提供者的位置信息，我們可以完全可以繞過註冊中心——採用dubbo直連，即在服務消費方配置服務提供方的位置信息。
點對點直連方式，將以服務接口爲單位，忽略註冊中心的提供者列表，A 接口配置點對點，不影響 B 接口從註冊中心獲取列表。
xml配置方式
<dubbo:reference id="userService" interface="com.zang.gmall.service.UserService" url="dubbo://localhost:20880" />
註解上直接添加
@Reference(url = "127.0.0.1:20880")
UserService userService;
2. 集羣下dubbo負載均衡配置
在集羣負載均衡時，Dubbo提供了4種均衡策略，如：Random LoadBalance(隨機均衡算法)、RoundRobin LoadBalance(權重輪循均衡算法)、LeastAction LoadBalance(最少活躍調用數均衡算法)、ConsistentHash LoadBalance(一致性Hash均衡算法)。缺省時爲Random隨機調用。
幾種負載均衡策略的解釋（截取自官方文檔）
配置方法很簡單，服務端和客戶端都可以配置服務級別或者方法級別的策略。
消費方服務級別配置（基於註解的權重輪詢均衡算法）
@Reference(loadbalance = "roundrobin")
UserService userService;
服務方方法級別配置（基於xml配置的權重輪詢均衡算法）
<dubbo:service interface="com.zang.gmall.service.UserService" <dubbo:method name="getUserAddressList" loadbalance="roundrobin"></dubbo:method> </dubbo:service>
3. 權重設置
當不設置負載均衡策略，即採用默認的Random LoadBalance(隨機均衡算法)時，默認每個服務的權重相同，我們可以通過設置權重來分配訪問的隨機性。
權重默認爲100，可以在暴露服務的同時設置
更便捷的方法是通過管理控制檯來直接設置服務提供者
4. 服務降級
當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運作或高效運作。
可以通過服務降級功能臨時屏蔽某個出錯的非關鍵服務，並定義降級後的返回策略（不調用服務即返回爲空 or 調用失敗返回爲空）。
向註冊中心寫入動態配置覆蓋規則：
RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension(); Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181")); registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
其中：
- mock=force:return+null 表示消費方對該服務的方法調用都直接返回 null 值，不發起遠程調用。用來屏蔽不重要服務不可用時對調用方的影響。
- 還可以改爲 mock=fail:return+null 表示消費方對該服務的方法調用在失敗後，再返回 null 值，不拋異常。用來容忍不重要服務不穩定時對調用方的影響。
通過操作管理控制檯也可以方便的進行服務降級：
5. 集羣容錯
在集羣調用失敗時，Dubbo 提供了多種容錯方案，缺省爲 failover 重試。
各節點關係：截取自 官方文檔
集羣容錯模式主要有以下幾種：
Failover Cluster
失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但重試會帶來更長延遲。可通過 retries="2" 來設置重試次數(不含第一次)。
消費方服務級註解添加（不能到方法級）
提供者方法級xml添加
Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
Forking Cluster
並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設置最大並行數。
Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。通常用於通知所有提供者更新緩存或日誌等本地資源信息。
集羣模式配置方法
在服務提供方和消費方配置集羣模式
6. 整合hystrix
Hystrix 旨在通過控制那些訪問遠程系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備擁有回退機制和斷路器功能的線程和信號隔離，請求緩存和請求打包，以及監控和配置等功能。
spring boot官方提供了對hystrix的集成，直接在pom.xml里加入依賴：
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> <version>1.4.4.RELEASE</version> </dependency>
然後在Application類上增加@EnableHystrix來啓用hystrix starter：
配置服務提供方：
在Dubbo的Provider上增加@HystrixCommand 配置，這樣子調用就會經過Hystrix代理。
配置服務消費方：
對於Consumer端，則可以增加一層method調用，並在method上配置@HystrixCommand 。當調用出錯時，會走到 fallbackMethod = "reliable" 的調用裏。
需要注意的是，@HystrixCommand註解設置的 reliable 調用方法的裏的參數要和 method 的參數保持一致。