共计 2259 个字符，预计需要花费 6 分钟才能阅读完成。
本篇次要介绍一下 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 这类界面化的工具来操作，然而理解一下原理还是有必要的。