遠程服務調用的分布式框架，高性能透明化PRC 遠程服務調用。SOA服務治理。
特征
1、透明化遠程方法調用：像調用本地方法一樣調用遠程方法，只需簡單的配置，沒有任何API侵入。
2、軟負載均衡和容錯機制。
3、服務自動注冊於發現，不需要寫死服務提供方的地址。
dubbox工作流程
節點角色
provider：暴露服務的服務提供方 Service
Consumer：調用遠程服務的服務消費方：controller
Registry：服務注冊和發現中心
zookeeper(官方推薦)、redis、廣播機制、Simple
Monitor：統計服務的調用次數和調用事件的監控中心。dubbox提供監控中心的war包。
Container：服務運行容器
service：spring容器
controller：SpringMVC容器
調用關系說明：
0. 服務容器負責啟動，加載，運行服務提供者。
1. 服務提供者在啟動時，向注冊中心注冊自己提供的服務。
2. 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
3. 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推
送變更數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，
如果調用失敗，再選另一台調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鍾發送一次統計
數據到監控中心。
dubbox的工作原理
說明：dubbox底層分為10層，每層作用如下
第一層：service層，接口層，給服務提供者和消費者來實現的
第二層：config層，配置層，主要是對dubbo進行各種配置的
第三層：proxy層，服務代理層，透明生成客戶端的stub和服務單的skeleton
第四層：registry層，服務注冊層，負責服務的注冊與發現
第五層：cluster層，集群層，封裝多個服務提供者的路由以及負載均衡，將多個實例組合成一個服務
第六層：monitor層，監控層，對rpc接口的調用次數和調用時間進行監控
第七層：protocol層，遠程調用層，封裝rpc調用
第八層：exchange層，信息交換層，封裝請求響應模式，同步轉異步
第九層：transport層，網絡傳輸層，抽象mina和netty為統一接口
第十層：serialize層，數據序列化層
dubbox負載均和策略和集群容錯策略、動態代理策略
dubbo負載均衡策略：
- random loadbalance：默認情況下，dubbo是random load balance隨機調用實現負載均衡，可以對provider不同實例設置不同的權重，會按照權重來負載均衡，權重越大分配流量越高，一般就用這個默認的就可以了。
- roundrobin loadbalance：還有roundrobin loadbalance，這個的話默認就是均勻地將流量打到各個機器上去，但是如果各個機器的性能不一樣，容易導致性能差的機器負載過高。所以此時需要調整權重，讓性能差的機器承載權重小一些，流量少一些。
- leastactive loadbalance：這個就是自動感知一下，如果某個機器性能越差，那么接收的請求越少，越不活躍，此時就會給不活躍的性能差的機器更少的請求
- consistanthash loadbalance：一致性Hash算法，相同參數的請求一定分發到一個provider上去，provider掛掉的時候，會基於虛擬節點均勻分配剩余的流量，抖動不會太大。如果你需要的不是隨機負載均衡，是要一類請求都到一個節點，那就走這個一致性hash策略。
dubbo動態代理策略：
- 默認使用javassist動態字節碼生成，創建代理類但是可以通過spi擴展機制配置自己的動態代理策略
dubbox的服務治理、降級、重試
服務降級：
比如說服務A調用服務B，結果服務B掛掉了，服務A重試幾次調用服務B，還是不行，直接降級，走一個備用的邏輯，給用戶返回響應。
public interface HelloService { void sayHello(); } public class HelloServiceImpl implements HelloService { public void sayHello() { System.out.println("hello world......"); } }
在provider中配置
<dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="true">
將mock修改為true，然后在跟接口同一個路徑下實現一個Mock類，命名規則是接口名稱加Mock后綴。然后在Mock類里實現自己的降級邏輯。
public class HelloServiceMock implements HelloService { public void sayHello() { // 降級邏輯 } }
失敗重試和超時重試
失敗重試，就是consumer調用provider要是失敗了，比如拋異常了，此時應該是可以重試的，或者調用超時了也可以重試。Dubbox默認請求時間是1000ms,請求三次.可以通過timeout設置超時時間，以及設置retries重試次數。
zookeeper注冊中心如果掛掉了可以繼續通信嗎？
可以。因為在剛開始初始化的時候，消費者會將提供者的地址等系拉取到本地緩存中，所以注冊中心掛掉了，可以繼續通信。
dubbox 如何保證服務的安全？
通過令牌驗證在注冊中心控制權限，以決定要不要下發令牌給消費者，可以防止消費者繞過注冊中心訪問提供者，另外通過注冊中心可靈活改變授權方式，而不需修改或升級提供者。
https://yq.aliyun.com/articles/284281
大部分的服務都是部署在內網的，基本很少外網開放，但是zookeeper 的用戶權限認證好像起不了什么作用。
dubbox 的服務集群
集群的目的：實現高可用，容錯功能，集群的服務器不要放在一台物理機上，要分散節點，才能實現高可用，高容錯性。如果一台提供者掛了，還有其他的提供者，保證系統正常穩定的運行。
用戶服務:pay-service-user
交易服務:pay-service-trade
在 121、122的服務器上同時啟動這兩個服務。
在DubboxAdmin 管理控制台中可以看待兩個機器都注冊了服務。
Dubbo服務容錯配置--集群容錯模式
1、failover cluster
失敗自動切換，當出現失敗，重試其他服務器（缺省），通常用於讀操作，但重試會帶來更長的延時，可通過retries=“2”來設置重試次數（不含第一次）
<dubbo:service retries="2"> 或者 <dubbo:reference retries="2"> 或者 <dubbo:reference> <dubbo:method name="findFoo" retries=2> <dubbo:reference/>
2、failfast cluster
快速失效，只發起一次調用，失敗立即報錯。通常用於非冪等性寫操作，比如說新增記錄
<dubbo:service cluster="failfast"> 或者 <dubbo:reference cluster="failfast"
3、failsaft cluster
失敗安全，出現異常時，直接忽略，通常用於寫入審計日志等操作
<dubbo:service cluster="failsafe"> 或者 <dubbo:reference cluster="failsafe">
4、failback cluster
失敗自動恢復，后台記錄失敗請求，定時重發，通常用於消息通知操作
<dubbo:service cluster="failback"> 或者 <dubbo:reference cluster="failback">
5、forking cluster
並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多的服務器資源。可通過forks=“2”來設置最大並行數。
<dubbo:service cluster="forking"> 或者 <dubbo:reference cluster="forking">
