在这分布式系统架构盛行的时代,很多互联网大佬公司开源出自己的分布式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服务,有些版本可能没有提供该API,如下是dubbo 2.6.2中的API
或者通过dubbo官网已经给出了文档来配置,文档地址 http://dubbo.apache.org/zh-cn/docs/user/references/qos.html
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. 要学会解决问题的思路,端口冲突是一个很常见的问题,通过百度或者谷歌搜索可能几分钟就能解决,只是想借此来更多的了解框架的实现细节,知其然知其所以然。