dubbo簡單配置與使用
dubbo簡介
隨著互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
此時，用於簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相幹的幾個應用，以提升效率。
此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
分布式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。
此時，用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。
dubbo架構構成
1、Provider:暴露服務的服務提供方。 Consumer: 調用遠程服務的服務消費方。 2、Registry:服務註冊與發現的註冊中心。 Monitor: 統計服務的調用次調和調用時間的監控中心。 3、Container: 服務運行容器。
調用關系說明：
1、服務容器負責啟動，加載，運行服務提供者。
3、服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
4、註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
5、服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
6、服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
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
1、新建接口
2、服務端配置
3、調用端配置
demo源碼地址
https://gitee.com/xuliugen/dubbodemo.git
dubbo配置文件詳解
常用配置
<dubbo:service/> 服務配置，用於暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以註冊到多個註冊中心。 eg、<dubbo:service ref="demoService" interface="com.unj.dubbotest.provider.DemoService" /> <dubbo:reference/> 引用服務配置，用於創建一個遠程服務代理，一個引用可以指向多個註冊中心。 eg、<dubbo:reference id="demoService" interface="com.unj.dubbotest.provider.DemoService" /> <dubbo:protocol/> 協議配置，用於配置提供服務的協議信息，協議由提供方指定，消費方被動接受。 eg、<dubbo:protocol name="dubbo" port="20880" /> <dubbo:application/> 應用配置，用於配置當前應用信息，不管該應用是提供者還是消費者。 eg、<dubbo:application name="xixi_provider" /> <dubbo:application name="hehe_consumer" /> <dubbo:module/> 模塊配置，用於配置當前模塊信息，可選。 <dubbo:registry/> 註冊中心配置，用於配置連接註冊中心相關信息。 eg、<dubbo:registry address="zookeeper://192.168.2.249:2181" /> <dubbo:monitor/> 監控中心配置，用於配置連接監控中心相關信息，可選。 <dubbo:provider/> 提供方的缺省值，當ProtocolConfig和ServiceConfig某屬性沒有配置時，采用此缺省值，可選。 <dubbo:consumer/> 消費方缺省配置，當ReferenceConfig某屬性沒有配置時，采用此缺省值，可選。 <dubbo:method/> 方法配置，用於ServiceConfig和ReferenceConfig指定方法級的配置信息。 <dubbo:argument/> 用於指定方法參數配置。
超時設置
上圖中以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" />
訂閱
1、問題
為方便開發測試，經常會在線下共用一個所有服務可用的註冊中心，這時，如果一個正在開發中的服務提供者註冊，可能會影響消費者不能正常運行。
2、解決方案
可以讓服務提供者開發方，只訂閱服務(開發的服務可能依賴其它服務)，而不註冊正在開發的服務，通過直連測試正在開發的服務。
禁用註冊配置： <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容器去加載服務。
dubbo簡單配置與使用