阿裡巴巴分布式服務架構Dubbo介紹

引言

網際網路服務和BS架構的傳統企業軟體相比，系統規模上産生了量級的差距。例如

• 傳統BS企業内部門戶隻需要考慮數百人以及幾千人的通路壓力，而大型網際網路服務有時需要考慮的是千萬甚至上億的使用者；
• 傳統企業管理系統管理的物料資訊等，可能隻有數萬或數十萬條記錄，而一個大型B2C網站的商品SKU動辄千萬，考慮到商品資訊更新的曆史記錄，商品訂單記錄等資料，更是天文數字。

原始的SSH+DB的BS開發模式，顯然已經無法滿足現代網際網路服務的需要。随着企業軟體不斷地向雲端遷移的趨勢越來越明顯，最終中小型企業軟體系統的開發将變得越來越非主流，模式和架構被淘汰後，隻熟悉原始的開發模式和架構的工程師，也将遭遇被淘汰的壓力。

SOA化

大型網際網路服務的體系架構有什麼特點呢？以大型B2C電商網站為例，其功能至少應該包含以下幾個部分

• 商鋪
• 商品及庫存
• 銷售（促銷，活動等）
• 訂單
• 支付
• 物流
• 使用者
• 财務等資料統計和報表功能
• 其他支撐系統（例如通路統計功能）

每個功能子產品都有自身的業務邏輯，且側重點各有不同，需要着眼的技術難點也不相同

• 商品的資料量較大，前端使用者對于高性能的檢索有較高要求，高并發時的庫存管理也要處理好；
• 訂單的狀态控制業務較複雜，資料量的累積很快；
• 支付和物流，與外部對接的技術複雜度一般較高；
• 報表功能一般背景計算量很大；

如何開發這樣的複雜大型系統，經過不斷地疊代和發展基本上找到了一條比較合适的道路：

• 将每個子產品都作為一個單獨的系統來進行架構設計和實作
• 子產品與子產品之間定義一定的接口規則來互動
• 每個子產品可以交由不同的團隊負責開發，并且可以根據需求選用不同的架構和技術棧

這時的每個子產品都擁有自己的輸入和輸出結構，相對獨立，可以被稱作一個服務。這種系統的整體架構就是SOA（面向服務的體系結構）。“它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。”，最重要的一點，“接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言”。

“這使得建構在各種各樣的系統中的服務可以使用一種統一和通用的方式進行互動。”   --- 百度百科

随着規模的增大，系統架構如何變遷到SOA的，Dubbo官方網站上有個很好的總結：

• 單一應用架構
  • 當網站流量很小時，隻需一個應用，将所有功能都部署在一起，以減少部署節點和成本。
  • 此時，用于簡化增删改查工作量的 資料通路架構(ORM) 是關鍵。
• 垂直應用架構
  • 當通路量逐漸增大，單一應用增加機器帶來的加速度越來越小，将應用拆成互不相幹的幾個應用，以提升效率。
  • 此時，用于加速前端頁面開發的 Web架構(MVC) 是關鍵。
• 分布式服務架構
  • 當垂直應用越來越多，應用之間互動不可避免，将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  • 此時，用于提高業務複用及整合的 分布式服務架構(RPC) 是關鍵。
• 流動計算架構
  • 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基于通路壓力實時管理叢集容量，提高叢集使用率。
  • 此時，用于提高機器使用率的 資源排程和治理中心(SOA) 是關鍵。

網站系統更加細節具體的架構演化，還可以參考一篇很好的博文 http://www.cnblogs.com/pflee/p/4507579.html

或者閱讀一本好書 《建構高性能Web站點》

服務架構Dubbo

服務化的思路簡化了一些事情，但是也有一些問題尚未解決：

• 如果某個處理需要調用其他服務的接口，不像本地調用某個庫函數那麼直覺友善，性能也有影響；
• 某個服務如果發生了變化，例如由于容量不夠進行了叢集化，依賴這個服務的其他服務需要相應的做什麼樣的調整，梳理需要花不少時間。
• 随之系統規模的增大，服務數量也不斷增多，接口的URL很快的出現了爆炸式的增長，管理困難；服務與服務之間的依賴關系将越來越難控制，那個服務必須先啟動？我的服務癱瘓了會影響到誰？誰又會影響到我？

Dubbo[]是阿裡開源的 ”一個分布式服務架構，緻力于提供高性能和透明化的RPC遠端服務調用方案，以及SOA服務治理方案“，幫助我們解決上述的那些問題。

其核心部分包含:

• 遠端通訊: 提供對多種基于長連接配接的NIO架構抽象封裝，包括多種線程模型，序列化，以及“同步轉異步”和“請求-響應”模式的資訊交換方式。  　基礎功能
• 叢集容錯: 提供基于接口方法的透明遠端過程調用，包括多協定支援，以及軟負載均衡，失敗容錯，位址路由，動态配置等叢集支援。  特色功能
• 自動發現: 基于注冊中心目錄服務，使服務消費方能動态的查找服務提供方，使位址透明，使服務提供方可以平滑增加或減少機器。  重要功能

Dubbo的主要特點

首先看一下來自于官方文檔的架構圖

（Dubbo更具體的架構組成，請參考這裡）

從官方文檔中，可以提煉出Dubbo的一些重要特點

特色1：服務注冊與發現的注冊中心Registry

• 注冊中心傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于長連接配接推送變更資料給消費者。  這個功能是應有之義
• 服務消費者，從提供者位址清單中，基于軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。這個就很好很強大了，

注冊中心的這兩個特性大大提高了系統的可用性和擴充性。注冊中心既可以采用Multicast注冊中心，也可以內建Zookeeper,也可以采用Redis，非生産環境也可以使用一個Dubbo自己實作的Simple注冊中心，非常靈活。

特色2：統計服務的調用次調和調用時間的監控中心Monitor

• 服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控中心。

監控負載，排查性能瓶頸就友善多了。簡易監控中心的安裝，請參考這裡。

特色3：使用上，采用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，隻需用Spring加載Dubbo的配置即可，Dubbo基于Spring的Schema擴充進行加載。

示例代碼

特色4：開源部分中，還包含有一個管理控制台的實作（内部裁剪版本，開源部分主要包含：路由規則，動态配置，服務降級，通路控制，權重調整，負載均衡，等管理功能）。

Dubbo的必讀官方文檔

使用者指南  ||  開發者指南  ||  管理者指南

--------------------------------------------------------------------------------

參考文獻：

http://dubbo.io/Home-zh.htm

http://www.iteye.com/magazines/103

http://www.tuicool.com/articles/YRRjq2E

http://blog.csdn.net/aisoo/article/details/8286875

http://shiyanjun.cn/archives/325.html