分布式Dubbo+Zookeeper+springmvc+mybatis+Shiro+restful+Bootstrap實例

Dubbo是阿里巴巴SOA服務(wù)化治理方案的核心框架，每天為2,000+個服務(wù)提供3,000,000,000+次訪問量支持，并被廣泛應(yīng)用于阿里巴巴集團的各成員站點

Dubbo是一個阿里巴巴開源出來的一個分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。其核心部分包含:

遠(yuǎn)程通訊: 提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應(yīng)”模式的信息交換方式。

集群容錯: 提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。

自動發(fā)現(xiàn): 基于注冊中心目錄服務(wù)，使服務(wù)消費方能動態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機器。

Dubbo產(chǎn)生的背景

隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)站應(yīng)用的規(guī)模不斷擴大，常規(guī)的垂直應(yīng)用架構(gòu)已無法應(yīng)對，分布式服務(wù)架構(gòu)以及流動計算架構(gòu)勢在必行，亟需一個治理系統(tǒng)確保架構(gòu)有條不紊的演進(jìn)。

單一應(yīng)用架構(gòu)

當(dāng)網(wǎng)站流量很小時，只需一個應(yīng)用，將所有功能都部署在一起，以減少部署節(jié)點和成本。

此時，用于簡化增刪改查工作量的數(shù)據(jù)訪問框架(ORM)是關(guān)鍵。

垂直應(yīng)用架構(gòu)

當(dāng)訪問量逐漸增大，單一應(yīng)用增加機器帶來的加速度越來越小，將應(yīng)用拆成互不相干的幾個應(yīng)用，以提升效率。

此時，用于加速前端頁面開發(fā)的Web框架(MVC)是關(guān)鍵。

分布式服務(wù)架構(gòu)

當(dāng)垂直應(yīng)用越來越多，應(yīng)用之間交互不可避免，將核心業(yè)務(wù)抽取出來，作為獨立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場需求。

此時，用于提高業(yè)務(wù)復(fù)用及整合的分布式服務(wù)框架(RPC)是關(guān)鍵。

流動計算架構(gòu)

當(dāng)服務(wù)越來越多，容量的評估，小服務(wù)資源的浪費等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心基于訪問壓力實時管理集群容量，提高集群利用率。

此時，用于提高機器利用率的資源調(diào)度和治理中心(SOA)是關(guān)鍵。

Dubbo可以滿足的需求

在大規(guī)模服務(wù)化之前，應(yīng)用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠(yuǎn)程服務(wù)，通過配置服務(wù)的URL地址進(jìn)行調(diào)用，通過F5等硬件進(jìn)行負(fù)載均衡。

(1)?當(dāng)服務(wù)越來越多時，服務(wù)URL配置管理變得非常困難，F(xiàn)5硬件負(fù)載均衡器的單點壓力也越來越大。

此時需要一個服務(wù)注冊中心，動態(tài)的注冊和發(fā)現(xiàn)服務(wù)，使服務(wù)的位置透明。

并通過在消費方獲取服務(wù)提供方地址列表，實現(xiàn)軟負(fù)載均衡和Failover，降低對F5硬件負(fù)載均衡器的依賴，也能減少部分成本。

(2)?當(dāng)進(jìn)一步發(fā)展，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。

這時，需要自動畫出應(yīng)用間的依賴關(guān)系圖，以幫助架構(gòu)師理清理關(guān)系。

(3)?接著，服務(wù)的調(diào)用量越來越大，服務(wù)的容量問題就暴露出來，這個服務(wù)需要多少機器支撐？什么時候該加機器？

為了解決這些問題，第一步，要將服務(wù)現(xiàn)在每天的調(diào)用量，響應(yīng)時間，都統(tǒng)計出來，作為容量規(guī)劃的參考指標(biāo)。

其次，要可以動態(tài)調(diào)整權(quán)重，在線上，將某臺機器的權(quán)重一直加大，并在加大的過程中記錄響應(yīng)時間的變化，直到響應(yīng)時間到達(dá)閥值，記錄此時的訪問量，再以此訪問量乘以機器數(shù)反推總?cè)萘俊?/p>

Dubbo的系統(tǒng)架構(gòu)

節(jié)點角色說明：

Provider:?暴露服務(wù)的服務(wù)提供方。

Consumer:?調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。

Registry:?服務(wù)注冊與發(fā)現(xiàn)的注冊中心。

Monitor:?統(tǒng)計服務(wù)的調(diào)用次調(diào)和調(diào)用時間的監(jiān)控中心。

Container:?服務(wù)運行容器。

上圖中，藍(lán)色的表示與業(yè)務(wù)有交互，綠色的表示只對Dubbo內(nèi)部交互。上述圖所描述的調(diào)用流程如下：

服務(wù)容器負(fù)責(zé)啟動，加載，運行服務(wù)提供者。

服務(wù)提供者在啟動時，向注冊中心注冊自己提供的服務(wù)。

服務(wù)消費者在啟動時，向注冊中心訂閱自己所需的服務(wù)。

注冊中心返回服務(wù)提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。

服務(wù)消費者，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺調(diào)用。

服務(wù)消費者和提供者，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心。

將上面抽象的調(diào)用流程圖展開，詳細(xì)如圖所示：

(1) 連通性：

注冊中心負(fù)責(zé)服務(wù)地址的注冊與查找，相當(dāng)于目錄服務(wù)，服務(wù)提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉(zhuǎn)發(fā)請求，壓力較小

監(jiān)控中心負(fù)責(zé)統(tǒng)計各服務(wù)調(diào)用次數(shù)，調(diào)用時間等，統(tǒng)計先在內(nèi)存匯總后每分鐘一次發(fā)送到監(jiān)控中心服務(wù)器，并以報表展示

服務(wù)提供者向注冊中心注冊其提供的服務(wù)，并匯報調(diào)用時間到監(jiān)控中心，此時間不包含網(wǎng)絡(luò)開銷

服務(wù)消費者向注冊中心獲取服務(wù)提供者地址列表，并根據(jù)負(fù)載算法直接調(diào)用提供者，同時匯報調(diào)用時間到監(jiān)控中心，此時間包含網(wǎng)絡(luò)開銷

注冊中心，服務(wù)提供者，服務(wù)消費者三者之間均為長連接，監(jiān)控中心除外

注冊中心通過長連接感知服務(wù)提供者的存在，服務(wù)提供者宕機，注冊中心將立即推送事件通知消費者

注冊中心和監(jiān)控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表

注冊中心和監(jiān)控中心都是可選的，服務(wù)消費者可以直連服務(wù)提供者

(2) 健狀性：

監(jiān)控中心宕掉不影響使用，只是丟失部分采樣數(shù)據(jù)

數(shù)據(jù)庫宕掉后，注冊中心仍能通過緩存提供服務(wù)列表查詢，但不能注冊新服務(wù)

注冊中心對等集群，任意一臺宕掉后，將自動切換到另一臺

注冊中心全部宕掉后，服務(wù)提供者和服務(wù)消費者仍能通過本地緩存通訊

服務(wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用

服務(wù)提供者全部宕掉后，服務(wù)消費者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復(fù)

(3) 伸縮性：

注冊中心為對等集群，可動態(tài)增加機器部署實例，所有客戶端將自動發(fā)現(xiàn)新的注冊中心

服務(wù)提供者無狀態(tài)，可動態(tài)增加機器部署實例，注冊中心將推送新的服務(wù)提供者信息給消費者

(4) 升級性：

當(dāng)服務(wù)集群規(guī)模進(jìn)一步擴大，帶動IT治理結(jié)構(gòu)進(jìn)一步升級，需要實現(xiàn)動態(tài)部署，進(jìn)行流動計算，現(xiàn)有分布式服務(wù)架構(gòu)不會帶來阻力：

Dubbo支持的協(xié)議

在通信過程中，不同的服務(wù)等級一般對應(yīng)著不同的服務(wù)質(zhì)量，那么選擇合適的協(xié)議便是一件非常重要的事情。你可以根據(jù)你應(yīng)用的創(chuàng)建來選擇。例如，使用 RMI協(xié)議，一般會受到防火墻的限制，所以對于外部與內(nèi)部進(jìn)行通信的場景，就不要使用RMI協(xié)議，而是基于HTTP協(xié)議或者Hessian協(xié)議。 Dubbo支持多種協(xié)議，如下所示：

Dubbo協(xié)議

Hessian協(xié)議

HTTP協(xié)議

RMI協(xié)議

WebService協(xié)議

Thrift協(xié)議

Memcached協(xié)議

Redis協(xié)議

Dubbo的模塊組成

Dubbo以包結(jié)構(gòu)來組織各個模塊，各個模塊及其關(guān)系，如圖所示：

可以通過Dubbo的代碼（使用Maven管理）組織，與上面的模塊進(jìn)行比較。簡單說明各個包的情況：

dubbo-common 公共邏輯模塊，包括Util類和通用模型。

dubbo-remoting 遠(yuǎn)程通訊模塊，相當(dāng)于Dubbo協(xié)議的實現(xiàn)，如果RPC用RMI協(xié)議則不需要使用此包。

dubbo-rpc 遠(yuǎn)程調(diào)用模塊，抽象各種協(xié)議，以及動態(tài)代理，只包含一對一的調(diào)用，不關(guān)心集群的管理。

dubbo-cluster 集群模塊，將多個服務(wù)提供方偽裝為一個提供方，包括：負(fù)載均衡、容錯、路由等，集群的地址列表可以是靜態(tài)配置的，也可以是由注冊中心下發(fā)。

dubbo-registry 注冊中心模塊，基于注冊中心下發(fā)地址的集群方式，以及對各種注冊中心的抽象。

dubbo-monitor 監(jiān)控模塊，統(tǒng)計服務(wù)調(diào)用次數(shù)，調(diào)用時間的，調(diào)用鏈跟蹤的服務(wù)。

dubbo-config 配置模塊，是Dubbo對外的API，用戶通過Config使用Dubbo，隱藏Dubbo所有細(xì)節(jié)。

dubbo-container 容器模塊，是一個Standalone的容器，以簡單的Main加載Spring啟動，因為服務(wù)通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去加載服務(wù)。

核心技術(shù)：Maven,Springmvc mybatis shiro, Druid, Restful, Dubbo, ZooKeeper,Redis,FastDFS,ActiveMQ,Nginx

1.?????項目核心代碼結(jié)構(gòu)截圖

項目模塊依賴

特別提醒：開發(fā)人員在開發(fā)的時候可以將自己的業(yè)務(wù)REST服務(wù)化或者Dubbo服務(wù)化

2.????項目依賴介紹

2.1?后臺管理系統(tǒng)、Rest服務(wù)系統(tǒng)、Scheculer定時調(diào)度系統(tǒng)依賴如下圖：

2.2?Dubbo獨立服務(wù)項目依賴如下圖：

3.??項目功能部分截圖：

zookeeper、dubbo服務(wù)啟動

dubbo管控臺

REST服務(wù)平臺