Dubbo底層原理深度剖析
一、dubbo 概述
Apache Dubbo （incubating） ｜?d?b??｜ 是一款高性能、輕量級的開源 Java RPC 框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動注冊和發現。 Dubbo 是一個分布式服務框架，致力于提供高性能和透明化的 rpc遠程服務調用方案、服務治理方案。
特性：
面向接口代理：調用接口的方法，在 A 服務器調用 B 服務器的方法，由 dubbo 實現對 B 的調用，無需關心實現的細節，就像 MyBatis 訪問 Dao 的接口，可以操作數據庫一樣。不用關心 Dao 接口方法的實現。這樣開發是方便，舒服的。
二、基本架構
服務提供者（Provider）：暴露服務的服務提供方，服務提供者在啟動時，向注冊中心注冊自己提供的服務。
服務消費者（Consumer）： 調用遠程服務的服務消費方，服務消費者在啟動時，向注冊中心訂閱自己所需的服務，服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失 敗，再選另一臺調用。
注冊中心（Registry）：注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者
監控中心（Monitor）：服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心
三、dubbo 支持的協議
支持多種協議：dubbo ， hessian ， rmi ， http， webservice ， thrift ， memcached ， redis。
dubbo 官方推薦使用 dubbo 協議。dubbo 協議默認端口 20880
使用 dubbo 協議，spring 配置文件加入：
＜dubbo：protocol name＝＂dubbo＂ port＝＂20880＂ ／＞
四、電商平臺需求
某電商平臺系統需求，用戶瀏覽商品；選擇商品下訂單，訂單系統需要獲取用戶信息中的送貨地址；向支付系統請求完成付款。
五、直連方式 dubbo
點對點的直連項目：消費者直接訪問服務提供者，沒有注冊中心。消費者必須指定服務提供者的訪問地址（url）。
消費者直接通過 url 地址訪問固定的服務提供者。這個 url 地址是不變的。
1．實現目標
用戶訪問 －－－－－－＞【商品網站服務】訪問－－－－－＞ 【訂單服務】
2．實現方式
以 JavaSE 為例，服務提供者，服務消費者都是 JavaSE 項目
（1） 創建服務提供者：訂單服務
A、新建 java project
項目名稱：link－orderservice－provider
設置 version 為 1．0．0
B、 maven pom．xml
C、 創建訂單實體類：Order
D、新建訂單服務接口：OrderService
E、 新建接口的實現類：OrderServiceImpl
F、創建 dubbo 配置文件
orderservce－provider．xml
G、測試配置文件
H、安裝本地 jar 到 maven 倉庫
服務接口中的方法要給消費者使用，消費者項目需要知道接口名稱和接口中的方法名稱、參數等。這些信息服務提供者才知道。需要把接口的 class 文件打包為 jar ．
服務接口項目的類文件打包為 jar， 安裝到 maven 倉庫，倉庫中的提供者 jar 可以被消費者使用。
使用 idea 的 maven 窗口執行 install
（2） 創建服務消費者：商品網站
A、新建 java project
項目名稱：link－main－web
B、 maven pom．xml
C、 創建購買商品接口
D、創建購買接口的實現類
E、 創建 dubbo 配置文件
shop－consume．xml
F、 執行消費者
六、dubbo 服務化最佳實踐
1．分包
建議將服務接口、服務模型、服務異常等均放在公共包中。
2．粒度
服務接口盡可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分布式事務問題，Dubbo 暫未提供分布式事務支持。
服務接口建議以業務場景為單位劃分，并對相近業務做抽象，防止接口數量爆炸。
不建議使用過于抽象的通用接口，如：Map query（Map），這樣的接口沒有明確語義，會給后期維護帶來不便。
3．版本
每個接口都應定義版本號，為后續不兼容升級提供可能，如：
＜dubbo：serviceinterface＝＂com．xxx．XxxService＂ version＝＂1．0＂ ／＞。
建議使用兩位版本號，要變更服務版本。先升級一半提供者為新版本，再將消費者全部升為新版本，然后將剩下的一半提供者升為新版本。
分享
請輸入評論內容...
請輸入評論/評論長度6~500個字
