一、dubbo 概述

Apache Dubbo （incubating） ｜?d?b??｜ 是一款高性能、輕量級的開源 Java RPC 框架，它提供了三大核心能力：面向接口的遠程方法調(diào)用，智能容錯和負載均衡，以及服務自動注冊和發(fā)現(xiàn)。 Dubbo 是一個分布式服務框架，致力于提供高性能和透明化的 rpc遠程服務調(diào)用方案、服務治理方案。

特性：

面向接口代理：調(diào)用接口的方法，在 A 服務器調(diào)用 B 服務器的方法，由 dubbo 實現(xiàn)對 B 的調(diào)用，無需關(guān)心實現(xiàn)的細節(jié)，就像 MyBatis 訪問 Dao 的接口，可以操作數(shù)據(jù)庫一樣。不用關(guān)心 Dao 接口方法的實現(xiàn)。這樣開發(fā)是方便，舒服的。

二、基本架構(gòu)

服務提供者（Provider）：暴露服務的服務提供方，服務提供者在啟動時，向注冊中心注冊自己提供的服務。

服務消費者（Consumer）： 調(diào)用遠程服務的服務消費方，服務消費者在啟動時，向注冊中心訂閱自己所需的服務，服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調(diào)用，如果調(diào)用失                          敗，再選另一臺調(diào)用。

注冊中心（Registry）：注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者

監(jiān)控中心（Monitor）：服務消費者和提供者，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心

三、dubbo 支持的協(xié)議

支持多種協(xié)議：dubbo ， hessian ， rmi ， http， webservice ， thrift ， memcached ， redis。

dubbo 官方推薦使用 dubbo 協(xié)議。dubbo 協(xié)議默認端口 20880

使用 dubbo 協(xié)議，spring 配置文件加入：

＜dubbo：protocol name＝＂dubbo＂ port＝＂20880＂ ／＞

四、電商平臺需求

某電商平臺系統(tǒng)需求，用戶瀏覽商品；選擇商品下訂單，訂單系統(tǒng)需要獲取用戶信息中的送貨地址；向支付系統(tǒng)請求完成付款。

五、直連方式 dubbo

點對點的直連項目：消費者直接訪問服務提供者，沒有注冊中心。消費者必須指定服務提供者的訪問地址（url）。

消費者直接通過 url 地址訪問固定的服務提供者。這個 url 地址是不變的。

1．實現(xiàn)目標

用戶訪問 －－－－－－＞【商品網(wǎng)站服務】訪問－－－－－＞ 【訂單服務】

2．實現(xiàn)方式

以 JavaSE 為例，服務提供者，服務消費者都是 JavaSE 項目

（1） 創(chuàng)建服務提供者：訂單服務

A、新建 java project

項目名稱：link－orderservice－provider

設置 version 為 1．0．0

B、 maven pom．xml

C、 創(chuàng)建訂單實體類：Order

D、新建訂單服務接口：OrderService

E、 新建接口的實現(xiàn)類：OrderServiceImpl

F、創(chuàng)建 dubbo 配置文件

orderservce－provider．xml

G、測試配置文件

H、安裝本地 jar 到 maven 倉庫

服務接口中的方法要給消費者使用，消費者項目需要知道接口名稱和接口中的方法名稱、參數(shù)等。這些信息服務提供者才知道。需要把接口的 class 文件打包為 jar ．

服務接口項目的類文件打包為 jar， 安裝到 maven 倉庫，倉庫中的提供者 jar 可以被消費者使用。

使用 idea 的 maven 窗口執(zhí)行 install

（2） 創(chuàng)建服務消費者：商品網(wǎng)站

A、新建 java project

項目名稱：link－main－web

B、 maven pom．xml

C、 創(chuàng)建購買商品接口

D、創(chuàng)建購買接口的實現(xiàn)類

E、 創(chuàng)建 dubbo 配置文件

shop－consume．xml

F、 執(zhí)行消費者

六、dubbo 服務化最佳實踐

1．分包

建議將服務接口、服務模型、服務異常等均放在公共包中。

2．粒度

服務接口盡可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分布式事務問題，Dubbo 暫未提供分布式事務支持。

服務接口建議以業(yè)務場景為單位劃分，并對相近業(yè)務做抽象，防止接口數(shù)量爆炸。

不建議使用過于抽象的通用接口，如：Map query（Map），這樣的接口沒有明確語義，會給后期維護帶來不便。

3．版本

每個接口都應定義版本號，為后續(xù)不兼容升級提供可能，如：

＜dubbo：serviceinterface＝＂com．xxx．XxxService＂ version＝＂1．0＂ ／＞。

建議使用兩位版本號，要變更服務版本。先升級一半提供者為新版本，再將消費者全部升為新版本，然后將剩下的一半提供者升為新版本。