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框架的理解，對架構調用流程更加清晰，不過，感覺對於框架只會用還是遠不夠的需要研究和理解框架的設計原理，要多學習框架里面的東西，設計思路和框架里面的代碼，多看優秀的然后多去思考，學着使用才會和優秀的人框架逐漸靠近。
