dubbo介紹
dubbo是阿里公司推出解決分佈式服務問題的框架,是一個基於SOA面向服務體系結構的基礎設施,提供了諸如服務發佈註冊、容錯調用、部署、調用次數監控、每一個服務的性能監控等不少功能。
一看以爲很是不錯能夠將咱們各類服務作成遠程服務調用,雖然看起來不錯,若是要具體實施將一個或多個系統抽象成一個合理、穩定的SOA系統卻不是一翠兒就,它須要遵循一些經驗和原則,不然會曹成費力不討好,事倍功半的效果。
優勢
動態註冊與發現服務
服務愈來愈多時,不須要咱們手工配置每個服務的URL調用地址,也不須要手工查找一個服務,添加或刪除服務對咱們來講是透明的、動態的,服務配置更加方便。
實現了軟負載,能夠經過配置dubbo集羣策略爲Failover,默認也是這個策略,失敗自動切換。
依賴關係
因爲服務變多,服務調用服務、依賴另外一個服務成爲常態,dubbo能夠幫咱們管理服務之間的依賴。
PS:服務雖然能夠相互依賴可是不建議層次過多,通常不該超過三層,即A依賴B,B依賴C,則C不該該再依賴於D,若是真須要依賴,應該從新考慮是否服務劃分粒度過細、太小,服務劃分不易太小或過大,應儘可能避開分佈式事務帶來的問題。
監控服務質量
服務既然已經抽取出來,那麼對每一個服務的最大調用量、每次調用的響應時間、多少臺機器能夠支撐多大訪問量等等問題,須要時刻來動態監測,來保證服務器資源的既不浪費又合理利用,依賴於dubbo監控中心完成。
架構演變
1.單一應用
在這個階段咱們只是開發單個的應用程序或許應用很大或者很小,都是開發部署在一個應用程序裏面這個時候典型的是類型於Struts+spring+ORM框架,經常見於中小型企業使用很是普遍,以致於大部分的培訓機構都是培訓SSH框架,這一框架在這時成爲了主流,受到了不少程序員的追捧。
2.多個應用
在一些電商網站隨着訪問數量逐漸增大,尤爲是到過年過節時下單用戶量會暴增,單一應用沒法解決訪問量暴增的需求,因而把關鍵瓶頸節點垂直抽取出來作成單獨應用來跑,在必定程度上解決了高訪問量的問題。
3.RPC分佈式服務
爲了適用不斷變化的市場需求,以及多個垂直應用之間數據交互方便,咱們把公共的業務抽取出來做爲獨立的模塊,爲其餘的應用提供服務,系統逐漸依賴於抽象和rpc遠程服務調用。
4.管理服務
隨着服務也愈來愈多,若是單靠程序員手工來管理折磨多的服務變的不願能,須要一個管理、監控、調度服務接口的中心應用,基於SOA思想管理服務的框架營運而生。
用一幅圖來歸納dubbo的演化過程顯着很是形象,以下:

應用場景
我的感受dubbo什麼時候使用均可以,小的網站項目未必不可使用dubbo框架,只是小的項目使用dubbo可能會拖延開發週期,而且對開發人員的素質要求比較高,後臺服務器也須要比普通項目消耗資源多,若是公司捨得出錢就能夠,何況,公司也在發展爲之後的擴展業務作好準備。
服務提供者
即實現服務接口的一方,服務說的通俗一些即咱們經常使用的接口,把須要讓別人調用的接口發佈出去,以供其餘應用使用但咱們也要爲接口實現方法,服務提供者即提供服務的一方。
根據項目開發,即咱們項目裏面service接口以及實現層如下部分,將此實現的調用地址發佈到註冊中心即完成了服務提供端的開發。
服務消費者
這個更好理解就是使用服務的一端,經常爲web項目的Controller層,對於服務提供方與消費方不只僅是寫好接口和實現就萬事大吉,dubbo不只僅能夠將一個接口和實現發佈爲遠程服務,還能夠爲該接口提供性能、安全等保障。
配置cluster集羣屬性,默認爲Failover失敗自動切換;失敗重試次數 retries="2",表示發三次請求不包括第一次;timeout="10000",超時;check="false",安全檢查,默認true,但通常需配置爲false,極可能會致使服務啓動不起來;等等,還有不少性能參數來保證服務正常運行,對於參數的優先級服務消費者要高於服務提供者,若是二者都有配置,那麼以消費端配置爲準,服務端配置會被覆蓋。
註冊中心
一個用來管理和協調服務軟件系統,能夠管理後臺不少的服務,避免出現服務死鎖、服務當機、服務不夠用等狀況發生,即時對服務進行註冊和發現,若是一個服務地址有變動,註冊中心會即時將變動地址推送給服務消費者。
總結
公司也在使用dubbo開發項目,在使用過程當中逐漸加深了對dubbo框架的理解,對架構調用流程更加清晰,不過,感受對於框架只會用仍是遠不夠的須要研究和理解框架的設計原理,要多學習框架裏面的東西,設計思路和框架裏面的代碼,多看優秀的而後多去思考,學着使用纔會和優秀的人框架逐漸靠近。