dubbo |ˈdʌbəʊ| 是阿里下的乙個分布式、高效能、透明化的rpc服務框架，提供服務自動註冊、自動發現等高效服務治理方案的開源框架。
1.1.rpc需要解決的問題
1.1.1.通訊問題
主要是通過在客戶端和伺服器之間建立tcp連線，遠端過程呼叫的所有交換的資料都在這個連線裡傳輸。連線可以是按需連線，呼叫結束後就斷掉，也可以是長連線，多個遠端過程呼叫共享同乙個連線。
1.1.2.定址問題
a伺服器上的應用怎麼告訴底層的rpc框架，如何連線到b伺服器（如主機或ip位址）以及特定的埠，方法的名稱是什麼，這樣才能完成呼叫。比如基於web服務協議棧的rpc，就要提供乙個endpoint uri，或者是從uddi服務上查詢。如果是rmi呼叫的話，還需要乙個rmi registry來註冊服務的位址。
1.1.3.序列化與反序列化
當a伺服器上的應用發起遠端過程呼叫時，方法的引數需要通過底層的網路協議如tcp傳遞到b伺服器，由於網路協議是基於二進位制的，記憶體中的引數的值要序列化成二進位制的形式，也就是序列化（serialize）或編組（marshal），通過定址和傳輸將序列化的二進位制傳送給b伺服器。
同理，b伺服器接收引數要將引數反序列化。b伺服器應用呼叫自己的方法處理後返回的結果也要序列化給a伺服器，a伺服器接收也要經過反序列化的過程。
2.2.dubbo註冊中心
ø multicast註冊中心
øzookeeper註冊中心
ø redis註冊中心
ø ******註冊中心
2.3.協議
dubbo預設協議採用單一長連線和nio非同步通訊，適合於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況。
url格式：
dubbo://username:password@host:port/path?key=value&key=value
ø 透明化的遠端方法呼叫，就像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何api侵入。
ø 軟負載均衡及容錯機制，可在內網替代f5等硬體負載均衡器，降低成本，減少單點。
ø 服務自動註冊與發現，不再需要寫死服務提供方位址，註冊中心基於介面名查詢服務提供者的ip位址，並且能夠平滑新增或刪除服務提供者。
ø 服務介面監控與治理
dubbo-admin與dubbo-monitor提供了完善的服務介面管理與監控功能，針對不同應用的不同介面，可以進行 多版本，多協議，多註冊中心管理。
4.1.在provider上盡量多配置consumer端屬性
ø timeout 方法呼叫超時
ø retries 失敗重試次數，預設是2（表示加上第一次呼叫，會呼叫3次）
ø loadbalance 負載均衡演算法（有多個provider時，如何挑選provider呼叫），預設是隨機（random）。還可以有輪詢(roundrobin)、最不活躍優先（leastactive，指從consumer端併發呼叫最好的provider，可以減少的反應慢的provider的呼叫，因為反應更容易累積併發的呼叫）
ø actives 消費者端，最大併發呼叫限制，即當consumer對乙個服務的併發呼叫到上限後，新呼叫會wait直到超時。 在方法上配置（dubbo:method）則併發限制針對方法，在介面上配置（dubbo:service），則併發限制針對服務。
4.2.provider上配置合理的provider端屬性
ø threads 服務執行緒池大小
ø executes 乙個服務提供者並行執行請求上限，即當provider對乙個服務的併發呼叫到上限後，新呼叫會wait（consumer可能到超時）。在方法上配置（dubbo:method ）則併發限制針對方法，在介面上配置（dubbo:service），則併發限制針對服務。
4.3.配置上dubbo快取檔案
提供者列表快取檔案
4.4.配置優先順序
ø 方法級優先，介面級次之，全域性配置再次之。
ø 如果級別一樣，則消費方優先，提供方次之。
4.5.推薦xml配置
xml version="1.0" encoding="utf-8"?>
<beans xmlns=""
xmlns:xsi="" xmlns:dubbo=""
xsi:schemalocation=" /spring-beans.xsd /dubbo.xsd">
<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"/>
<dubbo:protocol name="dubbo" port="20880"/>
<dubbo:provider timeout="60000" retries="0" accesslog="true"/>
<dubbo:service inte***ce="com.**.api.userinfoservice" ref="userinfoservice"/>
1、介面盡可能大粒度，介面中的方法不要以業務流程來，這個流程盡量在方法邏輯中呼叫，介面應代表乙個完整的功能對外提供；
2、介面應以業務為單位，業務相近的進行抽象，避免介面數量**
3、引數先做校驗，在傳入介面。
4、要做到在設計介面時，已經確定這個介面職責、**呼叫頻率
1、啟動檢查
在啟動某服務時，先檢查該服務所依賴的服務是否可用，不可用則丟擲異常，以便上線時，能及早發現問題，預設check=「true」；
2、負載均衡
針對某一方法在db管控臺進行配置
負載演算法：隨機（random loadbalance）、輪循（roundrobin）、最少活躍呼叫數（leastactive ，越活躍接收請求的概率越大）、一致性hash（consistenthash ）
3、執行緒模型：threadpool threads
最大執行緒數計算方式 ulimit -u命令計算伺服器可執行最大執行緒數
4、只訂閱
只訂閱服務，自己不註冊，例如該服務正在測試，先不能向zk中註冊避免其他服務呼叫它報錯
5、只註冊
只註冊服務，不訂閱；應用在集群中該伺服器上無該服務需要呼叫的服務，就讓他只註冊，指定呼叫其它伺服器上的可用服務
群號：779792048
架構演進及dubbo介紹
總結 架構中有乙個分布式架構，分布式架構中實現服務之間通訊的方式有一種叫rpc方式的通訊，rpc方式通訊的代表框架是dubbo，而能作為dubbo的註冊中心有zookeeper redis等 架構介紹 單體架構 所有東西都在乙個裡面，所有模組都放在乙個tomcat中 垂直架構 每乙個tomcat只放...
Dubbo架構的特點
1 註冊中心 負責服務位址的註冊於查詢 相當於目錄服務，服務提供者與消費者 只在啟動時與註冊中心互動，註冊中心不 請求，壓力較小 2 監控中心 負責統計各服務呼叫次數，呼叫時間等 統計先在記憶體彙總後，每分鐘一次傳送到監控中心伺服器，並以報表展示 3 服務提供者 向註冊中心，註冊其提供的服務 並匯報...
Dubbo架構簡介
一 dubbo的設計角色 1 系統角色 provider 暴露服務的服務提供方。consumer 呼叫遠端服務的服務消費方。registry 服務註冊與發現的註冊中心。1 monitor 統計服務的呼叫次調和呼叫時間的監控中心。container 服務執行容器。2 呼叫關係 服務容器負責啟動，載入，...