如何使用 Dubbo 的直连和服务分组

此文基于 Dubbo 官方文档,结合实际项目讲解几个常用的知识点,建议先根据以下官方文档学习。

http://dubbo.apache.org/zh-cn/docs/user/preface/background.html

Dubbo 概念

Dubbo 是一个 RPC 框架,关于什么是 RPC,可看知乎的这个回答:

https://www.zhihu.com/question/25536695/answer/36197244

RPC 是指远程过程调用,也就是说两台服务器 A,B,一个应用部署在 A 服务器上,想要调用 B 服务器上应用提供的函数 / 方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。

为什么使用 Dubbo?对于我们公司项目来说,为了 业务复用(将不同的核心业务抽离成一个个单独的应用,供其他应用调用)。

了解 Dubbo 的架构,请看官方文档

图片来自官网文档

  • 服务提供者 (Provider 节点):常作为核心服务,向注册中心注册自己的服务,供其他应用调用。同时也可作为消费者,调用其他提供者。
  • 服务消费者 (Consumer 节点):向注册中心订阅自己的服务。同时也可作为提供者,供其他消费者调用。
  • 注册中心 (Register 节点):相当一个目录,负责服务地址的注册和查找。

直连

由于 Dubbo 采用负载均衡的策略,多次请求服务时总会有一次调用本地的服务 (如果本地服务者启动了),是随机的。为了方便 Dubbo 在本地开发和调试,我们在本地项目中采用直连的方式,直连就是服务提供者不向注册中心注册服务,服务消费者直连服务提供者。如何在项目中配置直连:

1. 参考以下修改 provider.xml

<dubbo:registry protocol="zookeeper" address="="10.20.153.10:9090" register="false"/>

主要起作用的配置是register=”false”,代表不向注册中心注册。

2. 增加默认直连的配置文件 (dubbo-resolve.properties)

Dubbo2.0 以上版本,直连时,会默认加载 ${user.home}/dubbo-resolve.properties 配置文件。${user.home} 为用户目录,例如:win10 的 Administrator 用户的目录:C:\Users\Administrator;mac 用户的目录 /Users/userName

配置文件的示例内容如下:

com.alibaba.dubbo.demo.DemoService=dubbo://localhost:20880

通过以上配置,服务消费者会默认去 dubbo://localhost:20880(本地提供者) 查找 DemoServixe,如果没有,再去注册中心查找。

服务分组 (Group)

提供者通过运行不同的配置文件成为个性化应用,配置文件中包含:数据库;个性化名称等。

服务消费者配置文件 (dev.properties) 中设置组名:

dubbo.group.core=group_core

consumer.xml

<dubbo:reference id="indexService" group="${dubbo.group.core}" interface="com.xxx.IndexService" />

服务提供者配置文件 (dev.properties) 中设置组名:

dubbo.group.core=group_core

provider.xml

<dubbo:service group="${dubbo.group.core}" interface="com.xxx.IndexService" />

当消费者使用 dev.properties 运行时,会根据 dubbo.group.core=group_core 来选择使用对应配置文件 (dev.properties) 运行的提供者。

我们常常在服务器将所有的配置文件均打包运行,当本地更改组名时,就会调用对应的提供者。

其他概念

Nexus 与 Maven

Nexus 是 Maven 仓库管理器,存放项目所需要的 jar 包。

Maven 的版本分为 snapshot 和 release。snapshot 按最新时间戳查找;release 按版本号查找。所以常常项目在开发时,版本为 snapshot;上线时会改为 release。

deploy

deploy:将最新代码打包,存放在 Nexus 中。

什么时候需要 deploy?

当项目使用 dubbo 开发时,如果项目是多人协作开发,当你修改了服务消费者 T(后文简写为 cT) 和服务提供者 C(后文简写为 pC) 接口的代码时,此时需要 deploy pC(可以不修改版本号,因为 Maven 版本为 snapshot 时,Maven 会根据最新时间戳下载 jar 包)。如果没有 deploy,另一个开发人员在本地编译 cT 最新代码时,就会报错。因为此时通过 maven 下载的 pT 的 jar 代码不是最新的,找不到对应 pC 接口代码。

两个问题

  1. 如果改了 pC 的接口代码,比如修改了 service 方法名。相应将 cT 调用方法名也改了。如果将 pC deploy 了,此时服务器是否需要重新部署 pC?

答:如果本地已经启动了 pC,则不需要。如果在本地没有启动,则需要,cT 编译时不报错,但运行时,如果调用修改的接口,就会报错。
因为服务器跟本地一样,cT 都是调用调用 Tomcat 中运行的代码,没有部署相当于没有本地修改代码了没有重启 Tomcat。

  1. 当修改了 pC 的版本号后,如:1.2.0->1.3.0。cT 没有同步修改,还是 1.2.0。cT 什么时候会报错?

答:cT 的 pom 文件中 pC 的版本号是 1.2.0,cT 会在 Neuxs 中下载 pC 原来 doploy 的 1.2.0 的 jar 包,所以项目编译的时候不会报错。当运行时,它就不是调用 jar 包了,它是在注册中心找相应的 service 名,注册中心找对应的部署了的、正在运行的 pC 的接口,如果没有这个接口,cT 报错。

  1. 当 pC 的的版本号为 2.2.0。将其改为了 1.15.0。此时 pC 重新部署了。如果将 cT 引用 pC 的版本号改为了 1.15.0,那么此时如果 1.15.0

官方文档

http://dubbo.apache.org/zh-cn/docs/user/demos/subscribe-only.html  // 只订阅

http://dubbo.apache.org/zh-cn/docs/user/demos/service-group.html // 服务分组

http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-registry.html //<dubbo:registry > 标签

结语

官网文档地址常常变化,如不能访问时,可访问 dubbo 的 GitHub 主页:https://github.com/apache/incubator-dubbo。再去 Dubbo 主页查找相关教程文档。)

传输的实体需要序列化

Depp Wang wechat
个人公众号