如何使用 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 接口代码。

两个问题

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

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

当修改了 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 报错。

当 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 主页查找相关教程文档。）

传输的实体需要序列化