从dubbo源码分析qosserver端口冲突问题

在这分布式系统架构盛行的时代，很多互联网大佬公司开源出自己的分布式RPC系统框架，例如：阿里的dubbo，谷歌的gRPC，apache的Thrift。而在我们公司一直都在推荐使用dubbo，今天就来讲讲在使用dubbo过程出现的qos-server端口冲突问题。

首先什么是dubbo的qos-server呢？qos是dubbo的在线运维命令，dubbo2.5.8新版本重构了telnet模块，提供了新的telnet命令支持，新版本的telnet端口与dubbo协议的端口是不同的端口，默认为22222，可以通过配置文件dubbo.properties修改。

在dubbo2.5.7版本之前是不支持注解配置的，因此公司框架Titans对dubbo做了二次封装，通过自定义注解@EnableDuubo来支持dubbo的注解配置，并简化了server provider，server consumer，server registry配置，开发人员只要在spring boot启动类中添加@EnableDuubo即可开始自己的业务代码开发，节省大量的时间。

最近在项目开发过程中由于需要调试，在本地同一台机器上开了两个运行实例，一个是dubbo provider实例，一个是dubbo consumer实例。首先启动provider实例没有任务问题，当启动consumer以后，控制台却抛出如下问题，

为了解决端口冲突，开始在项目中使用各种idea搜索快捷键搜索关键字qos-server和22222都没有搜索到任何信息。一般日志都会打印包名和类型，便于快速定位问题，然后这里日志打印根本没有输出包名和类，赶紧修改日志打印格式配置，终于得到如下错误信息

原来是这个错误是dubbo的com.alibaba.dubbo.qos.server的Server类中打印出来,查看Server类源码发现在方法start中调用了netty的初始化方法,并将port作为被外部访问的qos-server端口,代码如下

那么问题来了:

问题1. 什么时候会启用qos服务呢,端口是何时被赋值的呢?

在Server类中可以看到唯一为 port参数赋值的方法只有setPor()方法,查看发现也只有在QosProtocolWrapper中调用了setPort()方法，查看源码可以发现，在该类的startQosServer()方法中会首先从url中解析qos.enable参数,如果未获取到该参数值,则默认启动qos服务,同时服务端口也是从url中解析,默认使用22222。

问题2. 那么这个url到底是啥呢?

其实断点程序可以发现,该url就是项目中对dubbo的一些配置信息,例如注册中心地址,超时时间,超时重试次数等等,由于项目中没有对qos服务的配置,因此全部采用了默认配置,导致端口冲突。

问题3. 如何禁用qos服务呢？

虽然qos端口冲突并影响服务消费者消费服务，但是每次程序启动总是抛出端口冲突异常，有强迫证的程序肯定以为程序哪里出错了，总会有那么一点忐忑。而且大多数情况可能并不需要这个qos服务，默认开启浪费端口，浪费机器资源（虽然资源占用并不一定很多），如果你是 java 注解配置，可以通过如下代码禁用qos服务，

或者通过通过dubbo官网已经给出了文档来配置，文档地址 http://dubbo.apache.org/#!/docs/user/references/qos.md?lang=zh-cn

问题4. 为什么我独立搭建dubbo分布式服务的时候没有出现qos-server端口冲突呢？

原因在于qos-server 需要netty4版本的支持，默认情况下dubbo不会引用netty4的依赖包，（而项目中有依赖netty4，因此抛出端口异常，）因此在QosProtocolWrapper类中调用Server类的start()方法启动qos服务时,会抛出ClassNotFoundException,QosProtocolWrapper的startQosServer()方法仅仅try catch了异常,未做任何处理,因此根本没有抛出任何异常,这是极其反对的一种做法,至少打个日志啊。源码如下：

总结：

1. 开发过程中日志打印及日志打印格式是非常重要的,可能大大减少问题定位的时间,因此一定要注意有效的日志输出

2. 要学会解决问题的思路,端口冲突是一个很常见的问题,通过百度或者谷歌搜索可能几分钟就能解决,只是想借此来更多的了解框架的实现细节,知其然知其所以然。