共计 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 这类界面化的工具来操作,然而理解一下原理还是有必要的。