dubbo的直連模式
- 應用場景
多用於測試的時候，繞開註冊中心，方便排查錯誤。
- 配置
直連模式的配置不需要對provider端做任何更改，只需要對consumer端的spring.xml做出修改即可(如下紅色行)，兩端配置內容如下：
——provider端內容：
<!--註冊中心地址，當provider啓動的時候會將上面的工程名稱、接口名稱註冊到ZK-->
<dubbo:registry id="zk2181" address="zookeeper://127.0.0.1:2181"/>
<dubbo:registry id="zk2182" address="zookeeper://127.0.0.1:2182" default="false"/>
<!--dubbo提供的服務端口,也就是說dubbo通過該端口與consumer通信-->
<dubbo:protocol name="dubbo" port="20880"/>
<!-- 掃包，如果是多個包用逗號隔開-->
<context:component-scan base-package="cn.crm.service,cn.crm.dao"/>
<!--對consumer一端提供的接口名稱，因爲上面用掃包的方式創建對象，所以 ref的值默認是實現類的第一個字母小寫的名字-->
<dubbo:service interface="cn.crm.api.UserApi" ref="userService" registry="zk2181"/>
<dubbo:service interface="cn.crm.api.OrdersApi" ref="ordersService" registry="zk2181"/>
——consumer端內容：
<!--註冊中心-->
<dubbo:registry id="zk2182" address="zookeeper://127.0.0.1:2182" />
<!--要引用的接口-->
<dubbo:reference id="userApi" interface="cn.crm.api.UserApi" check="false"/>
<dubbo:reference id="ordersApi" interface="cn.crm.api.OrdersApi" url="dubbo://127.0.0.1:20880"/>
備註：
1）provider端的所有服務都註冊到了2181上，consumer端只聲明2182的註冊中心，然後檢測是否能訪問到OrdersApi服務?
2）因爲這時UserApi在2182中找不到，所以需要指定check="false"否則啓動tomcat時報錯，即使這樣，在訪問/getusers時也會報No provider的異常，原因同上。
3）如果需要直連多個地址，地址間用“,”號隔開。
- 測試
上述配置完成後，通過瀏覽器訪問http://localhost:8080/crmweb/getorders，成功。
- 優劣分析
1）接口和接口之間的配置互不影響，A用直連不影響B用註冊用心
2）可繞過註冊中心實現點對點連接，但使用場景有限，常用於測試時
3）無法支持集羣
4）服務的地址不再透明，需要對地址進行維護，不利於大規模服務情況
- 作業
1）直連成功後，啓動dubbo-admin查看2182註冊中心是否有提供者和消費者?
沒有提供者和OrdersApi消費者，但是有userApi消費者。
2）其他配置不變，刪除 url="dubbo://127.0.0.1:20880"後getorders是否可用？
不能，提示沒有provider.
3）其他配置不變，刪除 url="dubbo://127.0.0.1:20880"，再加上2181的註冊中心配置，getorders是否可用？如下所示：
<!--註冊中心-->
<dubbo:registry id="zk2181" address="zookeeper://127.0.0.1:2181" />
<dubbo:registry id="zk2182" address="zookeeper://127.0.0.1:2182" />
<!--要引用的接口-->
<dubbo:reference id="userApi" interface="cn.crm.api.UserApi" check="false"/>
<dubbo:reference id="ordersApi" interface="cn.crm.api.OrdersApi" check="false"/>
答：可用，因爲可通過2181的註冊中心找到相應的服務。
（完結）
關注下方公衆號發現更多精彩
獲取更多資源請關注微信公衆號：AKA程序王
原文出處：https://www.cnblogs.com/akachengxuwang/p/11715034.html