deBug|黑马传智健康|com.alibaba.dubbo.rpc.RpcException

​简述：黑马传智健康项目day2中，给的资料是有错误的，在health_service_provider模块中的web.xml文件加载spring容器的配置命令出错了，classpath*:applicationContext*.xml是错误的，应当是classpath*:spring*.xml。

下面这张图才对

这是由于配置文件名称都被设计成了如下如：

• 具体异常描述：

com.alibaba.dubbo.rpc.RpcException: No provider available from registry 120.25.85.89:21 81 for service com.itheima.service.CheckItemService on consumer 192.168.60.1 use dubbo version 2.6.0, may be providers disabled or not registered ?

• 背景：

是这样的，我在做传智健康项目day2，当我把业务代码实现了，打算测试一下程序，发现无法实现需求，后来找到大致原因，报了这个异常，有点意外，因为我基本上都是cv的，遂开始找bug出在哪里。

这个项目是分布式项目，是由dubbo实现的，也就是说服务之间的通讯由dubbo负责。

• debug过程：
  本次debug用时约4小时，流程如下：

我想实现的功能是通过表单增加一个检查项，也就是往数据库增加一条信息，但是一直失败，无法增加数据进入数据库；

刚开始的时候我还不知道是RpcException这个异常，因为会报错的地方被try-catch了，且没有打印异常！后面排错的时候才发现这个问题的，才让我debug之路走了下去。

因为我不懂前端，所以直接把教程的前端页面cv过来，因此我认为错误不是出在前端，于是我认为错误出在了后端，那就从后端逻辑最开始地方开始排查，看看是不是controller搞错了，然后检查了controller的一些基本要求——注释，映射地址，代码逻辑，逐一看下来，都没有错，再看看细节吧，看看包有没有引错，毕竟重名的包那么多，发现没也没问题。
我的头大起来了，然后展开分析

大约思考了半分钟，我突然想到了什么，我竟然忘记了最重要也最好用的工具——debug！断点一打，绿色小甲虫启动，让我看看哪里除了幺蛾子，逐一走下来，发现原来是controller那里边除了问题，指令以进入到方法里，就报错，然后这个try-catch竟然还没有打印错误！

但凡try-catch一定要打印异常，方便后续检查，减少寻找bug的时间

太让人吃惊了，try-catch竟然不打印错误，这不是坑人是啥。。。遂补上打印语句
System.out.println(e);
e.printStackTrace();
一句不够清楚，我要看两句（其实没必要），于是乎问题出来了，是
com.alibaba.dubbo.rpc.RpcException
emmm？一看描述:
com.alibaba.dubbo.rpc.RpcException: No provider available from registry 120.25.85.89:21 81 for service com.itheima.service.CheckItemService on consumer 192.168.60.1 use dubbo version 2.6.0, may be providers disabled or not registered ?
虽然我没有见过这玩意，但是看描述感觉和大名鼎鼎的空指针异常有异曲同工之妙——都是找不着。
意思是提供服务的那个小程序（就是另一个module）找不到，没法提供服务，然后就报错了。至于错在哪，不知道，我思考了一分钟，没有头绪，于是乎开始求助于搜索引擎。
因为了有异常和异常描述的助力，我的搜索有了方向——我把异常名称及描述输入搜索框，出来了很多种解决方案：

1. 同名导包异常（我已排除）
2. 事务与远程调用不能同时开启（尝试了一下，没用）
3. 没有开启zookeeper，或zk错误启动（学了半个小时zk，发现启动正常，排除该项）
4. dubbo的包扫描未开启or包扫描开启位置错误（检查过了，无误）

其实看到报错，正确的做法应该是解读报错，我当时（2022.5）做这个项目的时候能力不够，导致无法把报错解读的很好，只是暴力的去搜索相关内容去解决bug，这样会导致我解决问题的速度很慢，如今这个项目做完一年了，我回过头来看，发现当时的分析不切要害，以下是我当下的分析：
这个错误的意思是，CheckItemService没办法找到地址是120.25.85.89的服务，请求是从CheckItemService发出的，向120.25.85.89注册的服务请求服务，但是找不到。
在报错中也提到了，导致这个错误的有两个原因——地址错误了或者是没有这个服务。而没有这个服务可能是因为服务没有发布，而导致服务没有发布的原因可能是服务配置错误。
因此要做的事情是去检查地址是否正确，查看服务是否正确发布。而问题实际上就是出现在服务没有正确配置上面，只要把服务配置好，这个问题就解决了。
解决这个bug其实关键在于是否了解dubbo，知道rpc是什么，显然当时我只懂按照文档配置dubbo，并不知道配置的内容具体的含义是什么，这样照猫画虎的去做项目，出了bug去调试时要花费更多的时间与精力，而且也不会使技术能力精进
-2023年8月11日 增加

搜了一圈，发现常见回答无法解决这个问题，然后我想起来了这个项目b站应该是有视频的，而根据b站良好的氛围，往往有意想不到的收获。

下面的评论区一般会把本项目，特别是同样的教程资料中的常见问题提出来，以避免后人踩坑，互助精神！

果然，在评论区下发现了有人指出

资料里web是xxxapplicationxxxx.xml 而项目里是springxxx.xml 改成 classpath*:spring*.xml就行。

！！我怎么都没想到，教程竟然会在如此低级地方出错

回过神来，我反思自己debug的过程，发现自己许多不足的地方：

1. 寻找bug没有章法。在排除代码和逻辑错误时花费太多时间，在花费了半个多小时想起debug这个工具，找到RpcException的时间花费太多了。正确的做法应当是：扫一眼代码和逻辑，看是否有明眼可见的错误，这个过程一定要快，不必细究，然后直接进入debug环节，寻找真正的问题出在哪里。
2. 在选择项目前没做好准备。dubbo和zookeeper都是我之前没接触过的技术，我再怎么样也要花上一两个小时读下入门教程再开始项目，这样我对项目的整体流程才能有更清晰的认识和了解，不然在debug的时候再去学习，很影响心情。
3. 对WebE基本常识和流程不够熟悉。不然检查肯定从容器注入开始了，我把其他的配置文件检查了那么多遍，唯独没有检查web.xml，原因很多：spring全家桶用惯了，对配置文件生疏了；JavaWeb的基础流程记忆不够清晰。

我觉得2,3是这个bug找了4个小时才找到的主要原因，对框架的实现流程和配置文件背后的含义认识不够，这方面往后要补上，也是接触新技术时要着重学习的。