Dubbo背景的產生
隨著互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分佈式服務架構以及流動計算架構勢在必行。Dubbo是一個分佈式服務框架，就是在這種情況下誕生的。
現在將核心業務抽取出來，作為獨立的服務，使前端應用能更快速和穩定的響應。大規模服務化之前，應用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠程服務，通過配置服務的URL地址進行調用，通過F5等硬件進行負載均衡。
(1).當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。
此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬件負載均衡器的依賴，也能減少部分成本。
(2).當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。
這時需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。
(3).接著服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？
為了解決這些問題，第一步要將服務現在每天的調用量，響應時間，都統計出來，作為容量規劃的參考指標。其次要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
Dubbo概述
Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說dubbo就是個遠程服務調用的分佈式框架(告別Web Service模式中的wsdl，以服務者與消費者的方式在dubbo上註冊)。
其核心部分包含:
1.遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
2.集群容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
3.自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
主要核心部件
Remoting: 網絡通信框架，實現了sync-over-async 和 request-response 消息機制.
RPC: 一個遠程過程調用的抽象，支持負載均衡、容災和集群功能
Registry: 服務目錄框架用於服務的註冊和服務事件發佈和訂閱。
Dubbo的作用
1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。
3.服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。
Dubbo架構圖如下所示：
節點角色說明：
Provider:暴露服務的服務提供方。
Consumer:調用遠程服務的服務消費方。
Registry:服務註冊與發現的註冊中心。
Monitor:統計服務的調用次調和調用時間的監控中心。
Container:服務運行容器。
此處可以根據每個節點角色的狀態來確定該服務是否正常。
調用關係說明：
0.服務容器負責啟動，加載，運行服務提供者。
1.服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2.服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3.註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4.服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5.服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
Dubbo使用方法
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。如果不想使用Spring配置，可以通過API的方式進行調用。
Dubbo建議使用Zookeeper作為服務的註冊中心。
1.Zookeeper的作用：
zookeeper用來註冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓調用者知道，簡單來說就是ip地址和服務名稱的對應關係。當然也可以通過硬編碼的方式把這種對應關係在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用者無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務對應關係從列表中刪除。至於支持高併發，簡單來說就是橫向擴展，在不更改代碼的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper註冊服務，服務的提供者多了能服務的客戶就多了。
2.Dubbo
Dubbo是管理中間層的工具，在業務層到數據倉庫間有非常多服務的接入和服務提供者需要調度，dubbo提供一個框架解決這個問題。這裡的dubbo只是一個框架，至於你架子上放什麼是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調度必須要有一個分佈式的註冊中心，儲存所有服務的元數據，你可以用zookeeper。
3.zookeeper和dubbo的關係
Dubbo將註冊中心進行抽象，使得它可以外接不同的存儲媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作為存儲媒介，也就把ZooKeeper的特性引進來。首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時候就需要分流，負載均衡就是為了分流而存在的，一個ZooKeeper群配合相應的Web應用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不夠，節點之間的數據和資源需要同步，ZooKeeper集群就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發佈。其他特性還有Mast選舉，分佈式鎖等。
Dubbo提供了很多協議，Dubbo協議、RMI協議、Hessian協議。之前沒用Dubbo之前時，大部分都使用Hessian來使用我們服務的暴露和調用，利用HessianProxyFactory調用遠程接口。
在進行Java使用之前，先簡單說明一下相關屬性的功能：
dubbo:registry標籤一些屬性的說明：
1）register是否向此註冊中心註冊服務，如果設為false，將只訂閱，不註冊。
2）check註冊中心不存在時，是否報錯。
3）subscribe是否向此註冊中心訂閱服務，如果設為false，將只註冊，不訂閱。
4）timeout註冊中心請求超時時間(毫秒)。
5）address可以Zookeeper集群配置，地址可以多個以逗號隔開等。
dubbo:service標籤的一些屬性說明：
1）interface服務接口的路徑
2）ref引用對應的實現類的Bean的ID
3）registry向指定註冊中心註冊，在多個註冊中心時使用，值為<dubbo:registry>的id屬性，多個註冊中心ID用逗號分隔，如果不想將該服務註冊到任何registry，可將值設為N/A
4）register 默認true ，該協議的服務是否註冊到註冊中心。
說明：
dubbo:reference 的一些屬性的說明：
1）interface調用的服務接口
2）check 啟動時檢查提供者是否存在，true報錯，false忽略
3）registry 從指定註冊中心註冊獲取服務列表，在多個註冊中心時使用，值為<dubbo:registry>的id屬性，多個註冊中心ID用逗號分隔
4）loadbalance 負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪循，最少活躍調用