dubbo QOS运维命令

本篇主要介绍一下 Dubbo 运维命令的使用以及实现原理。平时我们的服务已经上线了之后出现问题怎么下线？如何知道我们上线的服务有哪些？通过 Dubbo QOS可以一一实现。

QOS使用

消费端和服务端启动的时候，Dubbo默认都会启动一个后台端口来监听运维命令，生产上不用建议关掉。通过以下配置可以对QOS功能进行自定义配置。

//是否启用QOS功能，默认true
dubbo.application.qos.enable=true
//启动QOS功能开启的端口，默认22222
dubbo.application.qos.port=8998
//QOS功能是否只能本机执行，默认false
dubbo.application.qos.accept.foreign.ip=true

目前 Dubbo的QOS命令主要有5种，看下面的表格

命令	含义
help	查看所有能用的命令
ls	查看暴露的服务以及引用的服务
offline	下线服务
online	上线服务
quit	退出控制台

我们来逐个使用看下以上命令，基于telnet方式来演示（QOS命令支持http协议以及telnet协议），这里我启动一个dubbo服务并且设置qos端口为8999，先通过控制台连接上去

telnet localhost 8999

结果如下图

说明已经连接成功了

• help
  先来使用一下 help 命令
  
  可以看到控制台列出了所有能用的命令，和我们上面表格列出来的一样，对于不同版本的 Dubbo，可能命名会有些不一样的，所以使用之前先通过 help 命令来看下有哪些可用。我们还可以通过 help 来查看某个命令是如何使用的，比如我要看 ls 命令如何使用

  help ls

  
  如果看 online 命令，则

  help online

  
  其他的命令使用以此类推

• ls
  这个命令比较单一，直接

  ls

  结果如图
  
  上面是 Provider 相关情况，下面是 Consumer 相关情况，PUB 指的是是否注册成功了，NUM 指的是有几个服务在注册中心

• offline
  将服务从注册中心移除，可以指定某个服务或者所有服务，可以使用正则匹配，默认所有服务
  举例：我现在启动一个服务端和一个消费者，先使用ls命令分别看下服务情况，
  服务端：
  
  消费端：
  
  此时可以看到有一个服务并且只有一个节点注册了，接着我们将该服务下线

  offline com.example.dubboprovider.rpc.CityService

  再看下服务情况
  
  可以看到此时服务已经被下线，注册中心也没有，不信你可以自己找一下注册中心中是否还存在，由于该服务从注册中心下线了，注册中心会通知消费端，导致消费端也移除了该服务，此时我们看下消费端的情况确认下
  
  可以看到消费端也没有任何可用的服务节点了，发起调用试下：
  
  和预期一样，抛出了没有服务可用的异常，看到这应该对于offline的功能了解了吧。当然你可以通过正则方式移除某类服务，默认是所有服务

  offline com.example.dubboprovider.rpc.*

• online
  和 offline 对应，这个命令是上线服务。接着刚才offline的例子，此时服务恢复了，我们需要上线。
  连接服务端执行

  online com.example.dubboprovider.rpc.CityService

  看下结果
  
  可以看到服务又有了，此时注册中心也有了该服务，消费端同样也收到了通知，所以我们再看下消费端的服务情况
  
  符合预期，和offline一样，也可以用正则匹配服务

• quit
  这个命名顾名思义，就是退出控制台的意思，直接执行试下

  quit

  

  原理

  QOS看起来是不是很神奇，我们居然可以直接用控制台进行控制（当然也可以用http方式，url + /ls，这个ls就是命令），Dubbo 是怎么做到的，我们来解析一下。
  首先我们需要看到一个很关键的类QosProtocolWrapper，该类也是 Protocol 的一种SPI扩展，我们知道在服务暴露和服务引用的过程中，会涉及到 Protocol 的 export 以及 refer，秉着SPI的有 wrapper 先 wapper 的原则，无论是 export 还是 refer，都会先走 QosProtocolWrapper 的 export 和 refer，来看下做了什么
  
  可以看到逻辑基本一样，就是启动了一个qos用的server，里面的逻辑比较简单，直接跟到这里org.apache.dubbo.qos.server.Server#start
  
  可以看到本质上就是使用netty启动了一个后台，也就是我们的操作实际上就是和这个后台的一个交互而已，这里加入了一个 QosProcessHandler，看下是怎么做的
  
  channel注册的时候会加入一个延时任务来输出控制台信息，也就是
  
  请求进来的时候会先进行请求协议判断，是http还是其他，可以看到协议的判断是基于魔数来的
  
  http 协议使用 HttpProcessHandler，否则使用 TelnetProcessHandler，他们两者的不同是对于请求内容的解析不同，最终还是调用 CommandExecutor 去执行命令
  
  可以看到这里使用了SPI机制，而 BaseCommand 刚好有5种实现，分别对于每种命令，非常灵活的扩展机制
  
  剩下的就看每个命名的具体实现，不再多做介绍。

  总结

  QOS整体实现还是比较简单的，就是一个后台，然后基于请求类型分别解析并处理返回，其实功能上也并不完善，只能处理简单的服务上下线，而且还得使用命令的方式（容易出错），所以实际上用的也不多，大多数情况下我们都用dubbo admin这类界面化的工具来操作，但是了解一下原理还是有必要的。