Dubbo 是阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。
主要核心部件：
-
Remoting: 網絡通信框架，實現了 sync-over-async 和 request-response 消息機制.
-
RPC: 一個遠程過程調用的抽象，支持負載均衡、容災和集群功能
-
Registry: 服務目錄框架用於服務的注冊和服務事件發布和訂閱
Dubbo工作原理：
本文將通過實例進行講解，包括入門以及和springMVC mybatis整合還有管理端的演示
部分大圖直接觀看不太清晰，請在圖片上點擊右鍵，選擇新窗口打開
本文中有一個接口是實現了dao，和mybatis整合后進行與數據庫的交互，另一個接口如上圖演示的是主要想展示的多個服務提供者之間的負載均衡，均雷同，后面會提供具體的下載地址
步驟1： 定義共通接口，接口應該定義在一個單獨的maven項目中（jar），這樣服務提供者和消費者才能引入
和普通的jar接口一樣，不解釋
步驟2：實現服務提供者
服務提供者也很簡單，就是實現了第一步里面定義的接口，這里很簡單，就是打出一句話，以便后面區分消費者到底調用到了哪個服務提供者了。
另外，需要將服務暴露出去，所以配置文件里面的dubbox.xml就很重要了
這里需要注意的是，由於dubbox的服務注冊要基於zookeeper，所以需要先啟動一個，具體操作可以參考我博客的其他文章或者自行搜索。
為了區分消費者到底調用了哪個服務提供者，所以服務提供者我們至少要部署兩套，所以，需要修改上面的端口，另外，實現類里面打印的文字，還是要區分下
步驟3：實現消費者
接口的調用方就很簡單了，和標准的springMVC一樣，這里我們是整合好了的，直接注入就可以了
這里因為要測試到底調用到了哪個服務提供者，所以我們循環調用1000次，根據打印的文字來進行區分，所以上面紅色字體需要修改的地方一定要改
步驟4：啟動dubbox-admin， 管理端可以查看到發布的服務以及服務的提供者有那些。（我通過源碼編譯獲取的，稍后我會提供我打好包的下載地址）
a 將duboox-admin.war修改為ROOT.war並放在tomcat webAPp目錄下，先刪除掉ROOT文件夾， 然后啟動
同時，啟動后確認下zookeeper地址是否正確，若不正確，停止server，按下圖修改好了再啟動
步驟5：啟動服務提供者1
看見我們的提供的接口了，因為現在還沒有啟動消費者這邊，所以暫時沒有消費者，點擊任意接口進去看可以看到服務提供者的信息
注意到這里的端口，就是之前dubbo.xml里面配置的
步驟六，啟動服務提供者2,如果在啟動2的時候報端口被占用，那就是xml中端口沒改，仔細檢查下
啟動后服務列表還是一樣的，因為我們兩個服務提供者提供的服務接口都一樣，就不截圖了
但是現在我們每個接口都有兩個提供者了，理論上點進任意接口后有兩個實現，並且端口還不一樣 是不是？
如上圖，和我們預期是一樣的。
步驟7：啟動消費者
啟動消費者后我們在admin服務首頁看，注意看重點，不要看這里的文字 紅色圈起來的
最開始是沒有消費者，現在變為了正常了
步驟8：啟動消費者,進行測試，看看打印的log吧， 如果不是兩個server信息，那就再仔細檢查吧
另外可以在admin里面配置負載均衡機制再試試，
說說由此引發的"血案"：
之前的web項目，為了提高並行處理能力，除了代碼優化外，一般都是部署了多套，前端通過nginx等負載均衡機制進行分發。
接觸dubbox自己經過思考認為：
提供給web端的Controller層業務邏輯相對簡單，占用的處理時間及資源相對較少，主要的處理邏輯在service層以及dao數據交互層
如果將controller層單獨分離出來供用戶直接訪問， service和Dao一同作為服務部署多套，如果處理服務層的機器已經很吃力，則可以動態的增加服務節點來進行分擔。
這樣 controller層代碼就可以減少很多部署資源，主要的在后端service和dao了。
然后“血案”就來了， 我正嘗試着將現有項目進行拆分，通過壓力測試來驗證我的設想。。。。。。