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

结果如下图
dubbo QOS运维命令_第1张图片
说明已经连接成功了

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

    help ls

    dubbo QOS运维命令_第3张图片
    如果看 online 命令,则

    help online

    dubbo QOS运维命令_第4张图片
    其他的命令使用以此类推

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

    ls

    结果如图
    dubbo QOS运维命令_第5张图片
    上面是 Provider 相关情况,下面是 Consumer 相关情况,PUB 指的是是否注册成功了,NUM 指的是有几个服务在注册中心

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

    offline com.example.dubboprovider.rpc.CityService

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

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

    online com.example.dubboprovider.rpc.CityService

    看下结果
    dubbo QOS运维命令_第11张图片
    可以看到服务又有了,此时注册中心也有了该服务,消费端同样也收到了通知,所以我们再看下消费端的服务情况
    dubbo QOS运维命令_第12张图片
    符合预期,和offline一样,也可以用正则匹配服务

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

    quit

    dubbo QOS运维命令_第13张图片

    原理

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

    总结

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

你可能感兴趣的