在这分布式系统架构盛行的时代，很多互联网大佬公司开源出自己的分布式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版本之前是不支持注解配置的，因此公司框架对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服务，有些版本可能没有提供该API，如下是dubbo 2.6.2中的API
或者通过dubbo官网已经给出了文档来配置
dubbo2.6.8 的配置项
dubbo.application.qos-port=2222
dubbo.application.qos-enable=true
dubbo.application.qos-accept-foreign-ip=false
问题4
为什么我独立搭建dubbo分布式服务的时候没有出现qos-server端口冲突呢？
原因在于qos-server 需要netty4版本的支持，默认情况下dubbo不会引用netty4的依赖包，（而项目中有依赖netty4，因此抛出端口异常，）因此在QosProtocolWrapper类中调用Server类的start()方法启动qos服务时，会抛出ClassNotFoundException，QosProtocolWrapper的startQosServer()方法仅仅try catch了异常，未做任何处理，因此根本没有抛出任何异常，这是极其反对的一种做法，至少打个日志啊。
源码如下：
总结
1.开发过程中日志打印及日志打印格式是非常重要的，可能大大减少问题定位的时间，因此一定要注意有效的日志输出
2.要学会解决问题的思路，端口冲突是一个很常见的问题，通过百度或者谷歌搜索可能几分钟就能解决，只是想借此来更多的了解框架的实现细节，知其然知其所以然。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持编程网。
