telnet 命令演示 以及 Dubbo常见错误解决方法

一、telnet命令

dubbo服务发布之后，我们可以利用telnet命令进行调试、管理。

1、预备工作

代码：Dubbo入门Demohttps://github.com/MiaoPlus/dubbodemo.git

a、启动 zookeeper 注册中心

双击 zookeeper/bin 目录下的 zkServer.cmd

b、启动服务提供者

2、连接服务

打开cmd，测试Dubbo服务对应的 IP 和 端口号 是否能成功连接

如下所示即为连接成功，进入Telnet窗口：

3、查看服务列表

命令

ls

显示服务列表。

ls -l

显示服务详细信息列表。

ls XxxService

显示服务的方法列表。

ls -l XxxService

显示服务的方法详细信息列表。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

a、查看服务

b、查看服务接口

c、查看服务接口详细信息

4、调用服务接口

invoke XxxService.xxxMethod({"prop": "value"}): 调用服务的方法
invoke xxxMethod({"prop": "value"}): 调用服务的方法(自动查找包含此方法的服务)
1
2

5、查看服务状态

count XxxService: 统计 1 次服务任意方法的调用情况
count XxxService 10: 统计 10 次服务任意方法的调用情况
count XxxService xxxMethod: 统计 1 次服务方法的调用情况
count XxxService xxxMethod 10: 统计 10 次服务方法的调用情况
1
2
3
4

二、Dubbo常见错误解决方法

1、地址找不到：No provider available

找不到服务，这时候可能有这么几种情况：

• Provider 服务没启动，或者注册中心（比如 ZooKeeper，Nacos，Consul）宕机了。

• Dubbo 的服务配置有误差，必须保证服务名，组别(默认是 Dubbo )，version 三者都正确。

• 访问的环境有误：通常我们会有开发环境、测试环境、线上生产环境等多套环境。有时候发布的服务到了测试环境，而访问调用时却走了开发环境。

排查步骤

• 访问注册中心的 Ops 系统，查询对应的服务是否有提供者列表；同时检查调用者应用所在服务器的日志(一般每种注册服务的客户端都会有对应的日志记录)，查看是否有地址信息的推送/拉取记录。

• 如无，则表明发布者发布服务失败，检查发布者的应用启动是否成功。

• 如有服务，则检查调用者应用所连接的注册中心，确认跟预期的环境要匹配。

• 如上述都没有问题，检查是否配置了路由过滤的规则等。

2、调用超时：client-side timeout

一般超时是调用端发生在请求发出后，无法在指定的时间内获得对应的响应。原因大概有以下几种情况：

• 服务端确实处理比较慢，无法在指定的时间返回结果，调用端就自动返回一个超时的异常响应来结束此次调用。

• 服务端如果响应的比较快，但当客户端 Load 很高，负载压力很大的时候，会因为客户端请求发不出去、响应卡在 TCP Buffer 等问题，造成超时。因为客户端接收到服务端发来的数据或者请求服务端的数据，都会在系统层面排队，如果系统负载比较高，在内核态的时间占比就会加长，从而造成客户端获取到值时已经超时。

• 通常是业务处理太慢，可在服务提供方机器上执行：jstack [PID] > jstack.log 分析线程都卡在哪个方法调用上，这里就是慢的原因。如果不能调优性能，请调高 timeout 阈值。

排查和解决步骤

• 两边可能有 GC ,检查服务端和客户端 GC 日志，耗时很长的 GC，会导致超时。超时的发生很可能意味着调用端或者服务端的资源(CPU，内存或者网络)出现了瓶颈，需要检查服务端的问题还是调用端的问题来排除GC抖动等嫌疑。

• 检查服务端的网络质量，比如重传率来排除网络嫌疑。

• 借助链路跟踪的分析服务（比如阿里的ARMS，开源的OpenTracing系的实现Zipkin、SkyWalking等）来分析下各个点的耗时情况。

3、服务端的线程资源耗尽：Thread pool is EXHAUSTED

Dubbo 服务端的业务线程数是 200 个，如果多个并发请求量超过了 200，就会拒绝新的请求，抛出此错误。这种问题有这么几种解决办法：

排查和解决步骤

• 调整 Provider 端的 dubbo.provider.threads 参数的大小，调大一些即可。

• 调整 Consumer 端的 dubbo.consumer.actives 参数的大小，调小一些即可。

• 增加 Provider 服务的数量，分担压力。

4、Hessian 序列化失败：HessianRuntimeException

• 检查服务方法的传入传出参数是否实现 Serializable 接口。

• 检查服务方法的传入传出参数是否继承了 Number、Date、ArrayList、HashMap 等 Hessian 特殊化处理的类。

5、启动时 Configuration problem: Unable to locate Spring NamespaceHandler for XML schema

表示 Spring 找不到 dubbo:... 配置的解析处理器。通常是 Dubbo 的 jar 包没有被引入，请添加对 Dubbo 的依赖；或者是 ClassLoader 隔离，查看是否有使用 OSGI 或其它热加载机制。

参考文章：https://mp.weixin.qq.com/s/kCCjcAQjioJZO3wVD-0R8A

https://www.cnblogs.com/feiqihang/p/4387330.html