背景闡述
前幾天，有位同學問我一個關於 Dubbo 的問題。他的訴求是這樣子的：
訴求一
第一個訴求是本地開發的時候想自己呼叫自己的服務，比如自己在改 A 服務，然後出問題了，本地再啟動一個 B 服務，A 服務呼叫 B 服務直接排查問題。
目前的問題是用的同一個註冊中心，所以會呼叫到其他的服務例項。
還有就是去網上找了一些文章的資料，按照資料上的配置沒有效果，也就是在@Reference 配置 url 來指定呼叫的服務地址。
配置如下：
@Reference(url="dubbo://localhost:20880")
訴求二
目前他們的測試環境沒有使用 Docker 來部署，而且每個服務只部署了一個例項。問題就是當一個專案並行開發時有多個分支，這些分支得合併後一起部署測試。經常會出現程式碼衝突等問題。
還有就是快要上線時，需要下掉其他的分支做迴歸測試。但是會出現其他團隊也要同一天上線，就只能協商等待來解決。
最好的方式就是可以實現一個分支部署一個例項，對於他們目前的這個規模和投入這個暫時做不了。所以他向我請教，有沒有什麼更好更快的方式。
解決方案
既然找了我，我還是給出一些建議吧，不一定很好，僅供參考。
訴求一解決方案
@Reference
在@Reference 中指定 url 是可以的，只是那位同學配置的地址有問題，在地址後面應該加上介面和版本的資訊。
@Reference(url="dubbo://localhost:20880/com.xxx.xxx:1.0")
本地配置檔案
在@Reference 中指定 url 不好的方式就是跟程式碼耦合了，很容易出現將這種程式碼提交的情況。所以我們介紹另一種方式。
在自己電腦的使用者目錄下建一個 dubbo-resolve.properties 檔案，路徑是 ${user.home}/dubbo-resolve.properties ，然後檔案裡配置好需要直連的服務資訊，不需要修改本地工程的其他配置資訊。
dubbo-resolve.properties
com.xxx.xxx=dubbo://localhost:20880/com.xxx.xxx:1.0.0
com.xxx.xxx 是介面的全路徑，等於號後面就是服務的地址了。
訴求二解決方案
既然短時間內不太可能去改造部署系統，那麼可以先簡單的處理。目前他們就兩個團隊共用一套測試環境，我認為可以再新增一套環境來進行團隊間的隔離。
對於入口處的 Web 程式或者閘道器，可以弄兩個域名解決。主要是內部服務的呼叫需要進行隔離，比如我 A 團隊部署的服務不能讓 B 團隊呼叫到，因為分支不一樣會出問題。
註冊隔離
註冊隔離指的是在服務註冊的時候就將兩個團隊的測試服務分別註冊，比如各自使用一個獨立的註冊中心。
獨立的註冊中心肯定可以解決問題，但是完全沒必要這麼麻煩。他們註冊中心用的 Nacos，可以使用 Nacos 的 namespace 來隔離即可。
-Ddubbo.registry.address=nacos://api.nacos.beta.xxx.com:8848?namespace=xxx
本地配置檔案
同樣也可以用本地配置檔案的方式來指定呼叫的服務，這個方式的前提是部署的機器是獨立的，不能共用。如果新增了新的介面需要修改配置檔案。
控制 Dubbo 路由或者負載均衡
控制路由或者負載均衡都是為了實現同樣的效果，也就是把所有的服務提供者資訊給你，你自己選擇一個去呼叫。
官方文件：
http://dubbo.apache.org/zh-cn/docs/dev/impls/router.html
http://dubbo.apache.org/zh-cn/docs/dev/impls/load-balance.html
總結
對於訴求一的解決方案，建議使用本地配置檔案的方式。不需要改動程式碼，比較方便。
對於訴求二的解決方案，建議使用註冊隔離的方式。這是最徹底的方式，用了註冊隔離，也就不用在想辦法去控制路由了，因為註冊上來的服務就是我這套環境需要的，不需要的要註冊資訊在另一個名稱空間裡面，相互不影響。
關於作者：尹吉歡，簡單的技術愛好者，《Spring Cloud 微服務-全棧技術與案例解析》, 《Spring Cloud 微服務 入門 實戰與進階》作者, 公眾號 猿天地 發起人。