dubbo簡單配置與使用

dubbo簡介

隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

單一應用架構
當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。

垂直應用架構
當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。

分佈式服務架構
當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。

流動計算架構
當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

dubbo架構構成

1、Provider:暴露服務的服務提供方。 Consumer: 調用遠程服務的服務消費方。
2、Registry:服務註冊與發現的註冊中心。 Monitor: 統計服務的調用次調和調用時間的監控中心。
3、Container: 服務運行容器。

調用關係說明：
一、服務容器負責啓動，加載，運行服務提供者。
二、服務提供者在啓動時，向註冊中心註冊本身提供的服務。
三、服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
四、註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
五、服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
六、服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

dubbo特性

(1) 連通性：

註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表 
註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者

(2) 健狀性：

監控中心宕掉不影響使用，只是丟失部分採樣數據數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信服務提供者無狀態，任意一臺宕掉後，不影響使用服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

(3) 伸縮性：

註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心 
服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者

(4) 升級性：

當服務集羣規模進一步擴大，帶動IT治理結構進一步升級，須要實現動態部署，進行流動計算，現有分佈式服務架構不會帶來阻力：

dubbo的調用方式

基於NIO的非阻塞實現並行調用，客戶端不須要啓動多線程便可完成並行調用多個遠程服務，相對多線程開銷較小。

本地調用，使用了Injvm協議，是一個僞協議，它不開啓端口，不發起遠程調用，只在JVM內直接關聯，但執行Dubbo的Filter鏈。注意：服務暴露與服務引用都須要聲明injvm=「true」

<dubbo:reference injvm="true" .../>
<dubbo:service injvm="true" .../>

支持的註冊中心

Multicast註冊中心
Zookeeper註冊中心
Redis註冊中心
Simple註冊中心

支持的遠程通訊協議

Mina
Netty
Grizzly

支持的遠程調用協議

Dubbo協議
Hessian協議
HTTP協議
RMI協議
WebService協議
Thrift協議
Memcached協議
Redis協議

集羣容災

在集羣調用失敗時，Dubbo提供了多種容錯方案，缺省爲failover重試。

Failover Cluster 
失敗自動切換，當出現失敗，重試其它服務器。(缺省) 
一般用於讀操做，但重試會帶來更長延遲。 
可經過retries=「2」來設置重試次數(不含第一次)。

Failfast Cluster 
快速失敗，只發起一次調用，失敗當即報錯。 
一般用於非冪等性的寫操做，好比新增記錄。

Failsafe Cluster 
失敗安全，出現異常時，直接忽略。 
一般用於寫入審計日誌等操做。

Failback Cluster 
失敗自動恢復，後臺記錄失敗請求，定時重發。 
一般用於消息通知操做。

Forking Cluster 
並行調用多個服務器，只要一個成功即返回。 
一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。 
可經過forks=「2」來設置最大並行數。

Broadcast Cluster 
廣播調用全部提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持) 
一般用於通知全部提供者更新緩存或日誌等本地資源信息。

集羣負載均衡

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

RoundRobin LoadBalance 輪循，按公約後的權重設置輪循比率。 
存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

LeastActive LoadBalance 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。 
使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

ConsistentHash LoadBalance 一致性Hash，相同參數的請求老是發到同一提供者。 
當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。

配置：
<dubbo:service interface="..." loadbalance="roundrobin" />

dubbo-demo

準備工做

下載安裝zookeeper

下載安裝tomcat

demo

一、新建接口

二、服務端配置

三、調用端配置

demo源碼地址

https://gitee.com/xuliugen/dubbodemo.git

dubbo配置文件詳解

經常使用配置明細

http://www.cnblogs.com/zhangyaxiao/p/8183443.html

超時設置

上圖中以timeout爲例，顯示了配置的查找順序，其它retries, loadbalance, actives也相似。
方法級優先，接口級次之，全局配置再次之。
若是級別同樣，則消費方優先，提供方次之。

其中，服務提供方配置，經過URL經由註冊中心傳遞給消費方。
建議由服務提供方設置超時，由於一個方法須要執行多長時間，服務提供方更清楚，若是一個消費方同時引用多個服務，就不須要關心每一個服務的超時設置。
理論上ReferenceConfig的非服務標識配置，在ConsumerConfig，ServiceConfig, ProviderConfig都可以缺省配置。

啓動時檢查

Dubbo缺省會在啓動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止Spring初始化完成，以便上線時，能及早發現問題，默認check=true。

若是你的Spring容器是懶加載的，或者經過API編程延遲引用服務，請關閉check，不然服務臨時不可用時，會拋出異常，拿到null引用，若是check=false，老是會返回引用，當服務恢復時，能自動連上。

能夠經過check="false"關閉檢查，好比，測試時，有些服務不關心，或者出現了循環依賴，必須有一方先啓動。

1、關閉某個服務的啓動時檢查：(沒有提供者時報錯)
<dubbo:reference interface="com.foo.BarService" check="false" />

2、關閉全部服務的啓動時檢查：(沒有提供者時報錯)  寫在定義服務消費者一方
<dubbo:consumer check="false" />

3、關閉註冊中心啓動時檢查：(註冊訂閱失敗時報錯)
<dubbo:registry check="false" />

引用缺省是延遲初始化的，只有引用被注入到其它Bean，或被getBean()獲取，纔會初始化。
若是須要飢餓加載，即沒有人引用也當即生成動態代理，能夠配置：

<dubbo:reference interface="com.foo.BarService" init="true" />

訂閱

一、問題
爲方便開發測試，常常會在線下共用一個全部服務可用的註冊中心，這時，若是一個正在開發中的服務提供者註冊，可能會影響消費者不能正常運行。

二、解決方案
可讓服務提供者開發方，只訂閱服務(開發的服務可能依賴其它服務)，而不註冊正在開發的服務，經過直連測試正在開發的服務。

禁用註冊配置：
<dubbo:registry address="10.20.153.10:9090" register="false" />
或者：
<dubbo:registry address="10.20.153.10:9090?register=false" />

回聲檢測

回聲測試用於檢測服務是否可用，回聲測試按照正常請求流程執行，可以測試整個調用是否通暢，可用於監控。
全部服務自動實現EchoService接口，只需將任意服務引用強制轉型爲EchoService，便可使用。

<dubbo:reference id="memberService" interface="com.xxx.MemberService" />

MemberService memberService = ctx.getBean("memberService"); // 遠程服務引用
EchoService echoService = (EchoService) memberService; // 強制轉型爲EchoService
String status = echoService.$echo("OK"); // 回聲測試可用性
assert(status.equals("OK"))

延遲連接

延遲鏈接，用於減小長鏈接數，當有調用發起時，再建立長鏈接。
只對使用長鏈接的dubbo協議生效。

<dubbo:protocol name="dubbo" lazy="true" />

令牌驗證

防止消費者繞過註冊中心訪問提供者，在註冊中心控制權限，以決定要不要下發令牌給消費者，註冊中心可靈活改變受權方式，而不需修改或升級提供者

1、全局設置開啓令牌驗證：
<!--隨機token令牌，使用UUID生成-->
<dubbo:provider interface="com.foo.BarService" token="true" />

<!--固定token令牌，至關於密碼-->
<dubbo:provider interface="com.foo.BarService" token="123456" />

2、服務級別設置開啓令牌驗證：
<!--隨機token令牌，使用UUID生成-->
<dubbo:service interface="com.foo.BarService" token="true" />

<!--固定token令牌，至關於密碼-->
<dubbo:service interface="com.foo.BarService" token="123456" />

3、協議級別設置開啓令牌驗證：
<!--隨機token令牌，使用UUID生成-->
<dubbo:protocol name="dubbo" token="true" />

<!--固定token令牌，至關於密碼-->
<dubbo:protocol name="dubbo" token="123456" />

日誌適配

缺省自動查找：log4j、slf4j、jcl、jdk

能夠經過如下方式配置日誌輸出策略：dubbo:application logger="log4j"/>

訪問日誌：
若是你想記錄每一次請求信息，可開啓訪問日誌，相似於apache的訪問日誌。此日誌量比較大，請注意磁盤容量。

將訪問日誌輸出到當前應用的log4j日誌：

<dubbo:protocol accesslog="true" />

將訪問日誌輸出到指定文件：

<dubbo:protocol accesslog="http://10.20.160.198/wiki/display/dubbo/foo/bar.log" />

配置緩存文件

配置方法以下：

<dubbo:registryfile=」${user.home}/output/dubbo.cache」 />

注意：
文件的路徑，應用能夠根據須要調整，保證這個文件不會在發佈過程當中被清除。若是有多個應用進程注意不要使用同一個文件，避免內容被覆蓋。

這個文件會緩存：
註冊中心的列表
服務提供者列表

有了這項配置後，當應用重啓過程當中，Dubbo註冊中心不可用時則應用會從這個緩存文件讀取服務提供者列表的信息，進一步保證應用可靠性。

dubbo常見問題

dubbo-admin沒法顯示Group分組信息

http://blog.csdn.net/xlgen157387/article/details/50345545

沒法訪問遠程Zookeeper已註冊服務的問題

 http://blog.csdn.net/xlgen157387/article/details/50385266

dubbo源碼

源碼地址 

http://dangdangdotcom.github.io/dubbox

源碼結構

Dubbo以包結構來組織各個模塊，各個模塊及其關係，如圖所示：

dubbo-common 公共邏輯模塊，包括Util類和通用模型。

dubbo-remoting 遠程通信模塊，至關於Dubbo協議的實現，若是RPC用RMI協議則不須要使用此包。

dubbo-rpc 遠程調用模塊，抽象各類協議，以及動態代理，只包含一對一的調用，不關心集羣的管理。

dubbo-cluster 集羣模塊，將多個服務提供方假裝爲一個提供方，包括：負載均衡、容錯、路由等，集羣的地址列表能夠是靜態配置的，也能夠是由註冊中心下發。

dubbo-registry 註冊中心模塊，基於註冊中心下發地址的集羣方式，以及對各類註冊中心的抽象。

dubbo-monitor 監控模塊，統計服務調用次數，調用時間的，調用鏈跟蹤的服務。

dubbo-config 配置模塊，是Dubbo對外的API，用戶經過Config使用Dubbo，隱藏Dubbo全部細節。

dubbo-container 容器模塊，是一個Standalone的容器，以簡單的Main加載Spring啓動，由於服務一般不須要Tomcat/JBoss等Web容器的特性，不必用Web容器去加載服務。