Dubbo背景和簡介
官網：http：//dubbo。apache。org/zh-cn/
Dubbo開始於電商系統，因此在這裡先從電商系統的
演變
講起。
單一應用框架（ORM）
當網站流量很小時，只需一個應用，將所有功能如下單支付等都部署在一起，以減少部署節點和成本。
缺點
：單一的系統架構，使得在開發過程中，佔用的資源越來越多，而且隨著流量的增加越來越難以維護
單一應用框架
垂直應用框架（MVC）
垂直應用架構解決了單一應用架構所面臨的擴容問題，流量能夠分散到各個子系統當中，且系統的體積可控，一定程度上降低了開發人員之間協同以及維護的成本，提升了開發效率。
缺點
：但是在垂直架構中相同邏輯程式碼需要不斷的複製，不能複用。
垂直應用框架
分散式應用架構（RPC）
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心
流動計算架構（SOA）
隨著服務化的進一步發展，服務越來越多，服務之間的呼叫和依賴關係也越來越複雜，誕生了面向服務的架構體系（SOA），也因此衍生出了一系列相應的技術，如對服務提供、服務呼叫、連線處理、通訊協議、序列化方式、服務發現、服務路由、日誌輸出等行為進行封裝的服務框架
從以上是電商系統的演變可以看出架構演變的過程：
流動計算架構（SOA）
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
此時，用於簡化增刪改查工作量的 資料訪問框架（ORM） 是關鍵。
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
此時，用於加速前端頁面開發的 Web框架（MVC） 是關鍵。
分散式服務架構
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提高業務複用及整合的 分散式服務框架（RPC） 是關鍵。
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。
此時，用於提高機器利用率的 資源排程和治理中心（SOA） 是關鍵。
在這裡插播一條關於RPC的簡介：
RPC(Remote Procedure Call Protocol)：遠端過程呼叫
：
兩臺伺服器A、B，分別部署不同的應用a，b。當A伺服器想要呼叫B伺服器上應用b提供的函式或方法的時候，由於不在一個記憶體空間，不能直接呼叫，需要透過網路來表達呼叫的語義傳達呼叫的資料。
說白了，就是你在你的機器上寫了一個程式，我這邊是無法直接呼叫的，這個時候就出現了一個遠端服務呼叫的概念。
RPC是一種透過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通訊程式之間攜帶資訊資料。在OSI網路通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網路分散式多程式在內的應用程式更加容易。 RPC採用客戶機/伺服器模式。請求程式就是一個客戶機，而服務提供程式就是一個伺服器。首先，客戶機呼叫程序傳送一個有程序引數的呼叫資訊到服務程序，然後等待應答資訊。在伺服器端，程序保持睡眠狀態直到呼叫資訊到達為止。當一個呼叫資訊到達，伺服器獲得程序引數，計算結果，傳送答覆資訊，然後等待下一個呼叫資訊，最後，客戶端呼叫程序接收答覆資訊，獲得程序結果，然後呼叫執行繼續進行。
RPC需要解決的問題：
（可以稍作了解，詳情可檢視別的博文）
通訊問題
： 主要是透過在客戶端和伺服器之間建立TCP連線，遠端過程呼叫的所有交換的資料都在這個連線裡傳輸。連線可以是按需連線，呼叫結束後就斷掉，也可以是長連線，多個遠端過程呼叫共享同一個連線。
定址問題
： A伺服器上的應用怎麼告訴底層的RPC框架，如何連線到B伺服器（如主機或IP地址）以及特定的埠，方法的名稱名稱是什麼，這樣才能完成呼叫。比如基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查詢。如果是RMI呼叫的話，還需要一個RMI Registry來註冊服務的地址。
序列化 與 反序列化
： 當A伺服器上的應用發起遠端過程呼叫時，方法的引數需要透過底層的網路協議如TCP傳遞到B伺服器，由於網路協議是基於二進位制的，記憶體中的引數的值要序列化成二進位制的形式，也就是序列化（Serialize）或編組（marshal），透過定址和傳輸將序列化的二進位制傳送給B伺服器。
同理，B伺服器接收引數要將引數反序列化。B伺服器應用呼叫自己的方法處理後返回的結果也要序列化給A伺服器，A伺服器接收也要經過反序列化的過程。
Dubbo是什麼
Dubbo是：
一款分散式服務框架
高效能和透明化的RPC遠端服務呼叫方案
SOA服務治理方案
每天為2千多個服務提供大於30億次訪問量支援，並被廣泛應用於阿里巴巴集團的各成員站點以及別的公司的業務中。
Dubbo架構
Provider
： 暴露服務的服務提供方。
Consumer
： 呼叫遠端服務的服務消費方。
Registry
： 服務註冊與發現的註冊中心。
Monitor
： 統計服務的呼叫次數和呼叫時間的監控中心。
呼叫流程
0。服務容器負責啟動，載入，執行服務提供者。
1。服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2。服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3。註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4。服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
5。服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心
Dubbo註冊中心
對於服務提供方，它需要釋出服務，而且由於應用系統的複雜性，服務的數量、型別也不斷膨脹；
對於服務消費方，它最關心如何獲取到它所需要的服務，而面對複雜的應用系統，需要管理大量的服務呼叫。
而且，對於服務提供方和服務消費方來說，他們還有可能兼具這兩種角色，即既需要提供服務，有需要消費服務。
透過將服務統一管理起來，可以有效地最佳化內部應用對服務釋出/使用的流程和管理。服務註冊中心可以透過特定協議來完成服務對外的統一。
Dubbo提供的註冊中心有如下幾種型別可供選擇
：
Multicast註冊中心
Zookeeper註冊中心
Redis註冊中心
Simple註冊中心
Dubbo優缺點
優點：
透明化的遠端方法呼叫
- 像呼叫本地方法一樣呼叫遠端方法；只需簡單配置，沒有任何API侵入。
軟負載均衡及容錯機制
可在內網替代nginx lvs等硬體負載均衡器。
服務註冊中心自動註冊 & 配置管理
-不需要寫死服務提供者地址，註冊中心基於介面名自動查詢提供者ip。
使用類似zookeeper等分散式協調服務作為服務註冊中心，可以將絕大部分專案配置移入zookeeper叢集。
服務介面監控與治理
-Dubbo-admin與Dubbo-monitor提供了完善的服務介面管理與監控功能，針對不同應用的不同介面，可以進行 多版本，多協議，多註冊中心管理。
缺點：
服務提供方與呼叫方介面依賴方式太強：呼叫方對提供方的抽象介面存在強依賴關係，需要嚴格的管理版本依賴，才不會出現服務方與呼叫方的不一致導致應用無法編譯成功等一系列問題；
服務對平臺敏感，難以簡單複用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平臺的特點。在Dubbo中我們要提供REST介面時，不得不實現一層代理，用來將RPC介面轉換成REST介面進行對外發布。所以噹噹網在dubbox（基於Dubbo的開源擴充套件）中增加了對REST支援。
