dubbo 本地调试的三种方法

缺乏、安全感 2022-11-20 08:19 1355阅读 0赞

### 背景 ###

在开发Dubbo服务时，可能是多个人同时开发，但是都公用一个Zookeeper注册中心，这时就会出现同一个服务会有多个提供者（如果每个开发者都运行了提供者服务），这时如果某个开发者通过消费者服务在调用提供者服务时，可能调到别的同事机器上了，此时无法进行调试。为了解决这个问题，dubbo 可以有三种方法来解决。

#### 方法一 ####

修改服务提供者和服务消费者的版本号，比如修改服务提供者需要本地调试的某个API的版本号

@Service(interfaceClass = CcbBankServiceApi.class,version = "0.0.2")

同时需要修改消费者此API的版本号

#### 方法二 ####

在启动本地的服务时加入全局版本号的参数

-Ddubbo.service.version=test

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyNDI2NTc_size_16_color_FFFFFF_t_70_pic_center]  
同时需要修改消费者侧API的版本号

#### 方法三 ####

本机服务提供者不去zookeeper 注册中心注册，这样别人将调不了你的服务。需要修改配置

dubbo.registry.register=false                            (properties)

dubbo:
        registry:
          protocol: zookeeper
          address: 192.168.0.1                                (yml)
          register: false

由于本地的服务提供者没有注册到注册中心，所以服务消费者需要指定本地服务提供者url地址，配置如下：

<dubbo:reference id="xxxxxApi" interface="xxxxxxApi" version="0.0.1"  timeout="15000" url="dubbo://localhost:8136"/>

三种方法对比

<table> 
 <thead> 
  <tr> 
   <th>方法</th> 
   <th>服务提供者配置</th> 
   <th>消费者配置</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>第一种方法</td> 
   <td>需要</td> 
   <td>需要</td> 
   <td>此方法的弊端在于别的服务消费者请求仍然有可能会打到本机服务，但是本地的版本可能不符合服务消费者的需求。比如 服务消费者需要A版本，而本地是B版本</td> 
  </tr> 
  <tr> 
   <td>第二种方法</td> 
   <td>不需要</td> 
   <td>需要</td> 
   <td>此方法可以避免方法一的问题，方法一是局部改变服务提供者的版本号，而方法是全局改变 本地服务提供者的版本号。</td> 
  </tr> 
  <tr> 
   <td>第三种方法</td> 
   <td>需要</td> 
   <td>需要</td> 
   <td>此方法由于没有注册到注册中心，所以也可以避免方法一的问题，但是服务提供者和消费者都需要改配置，容易出错</td> 
  </tr> 
 </tbody> 
</table>

综合以上的对比，个人强烈建议采用第二种方法，即在本地服务提供者启动时，加入VM参数 -Ddubbo.service.version=test ，这样可以不用改服务提供者的配置，避免上线配置忘记改过来的问题。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyNDI2NTc_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/b210cb3e1988415486ebac541a09b76a.png