分布式Dubbo+Zookeeper+springmvc+mybatis+Shiro+restful+Bootstrap實(shí)例

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

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ù)消費(fèi)方能動態(tài)的查找服務(wù)提供方恃轩，使地址透明结洼，使服務(wù)提供方可以平滑增加或減少機(jī)器。

Dubbo產(chǎn)生的背景

隨著互聯(lián)網(wǎng)的發(fā)展叉跛，網(wǎng)站應(yīng)用的規(guī)模不斷擴(kuò)大松忍，常規(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é)點(diǎn)和成本。

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

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

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

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

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

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

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

流動計算架構(gòu)

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

此時，用于提高機(jī)器利用率的資源調(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ù)載均衡器的單點(diǎn)壓力也越來越大岭粤。

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

并通過在消費(fèi)方獲取服務(wù)提供方地址列表巾兆，實(shí)現(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ù)需要多少機(jī)器支撐抵赢？什么時候該加機(jī)器欺劳？

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

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

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

節(jié)點(diǎn)角色說明：

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

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

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

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

Container:?服務(wù)運(yùn)行容器柔滔。

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

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

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

服務(wù)消費(fèi)者在啟動時嘶朱，向注冊中心訂閱自己所需的服務(wù)蛾坯。

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

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

服務(wù)消費(fèi)者和提供者，在內(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ù)提供者和消費(fèi)者只在啟動時與注冊中心交互蚌吸，注冊中心不轉(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ù)消費(fèi)者向注冊中心獲取服務(wù)提供者地址列表，并根據(jù)負(fù)載算法直接調(diào)用提供者萌焰，同時匯報調(diào)用時間到監(jiān)控中心哺眯，此時間包含網(wǎng)絡(luò)開銷

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

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

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

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

(2) 健狀性：

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

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

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

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

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

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

(3) 伸縮性：

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

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

(4) 升級性：

當(dāng)服務(wù)集群規(guī)模進(jìn)一步擴(kuò)大惦积，帶動IT治理結(jié)構(gòu)進(jìn)一步升級，需要實(shí)現(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é)議的實(shí)現(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啟動滑凉，因?yàn)榉?wù)通常不需要Tomcat/JBoss等Web容器的特性统扳，沒必要用Web容器去加載服務(wù)。

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

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

項(xiàng)目模塊依賴

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

2.????項(xiàng)目依賴介紹

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

2.2?Dubbo獨(dú)立服務(wù)項(xiàng)目依賴如下圖：

3.??項(xiàng)目功能部分截圖：

zookeeper、dubbo服務(wù)啟動

dubbo管控臺

REST服務(wù)平臺