当项目中遇到了一个新的框架、技术等,我们都是在不了解详细运行机制的基础上各种百度、搜索出一个博客,照搬过来,搭建测试跑通之后,然后深入点,踩了几个坑,通过同样的百度或者经过自己的解决后我们觉得我们算是深入了解了,等闲来无事时我们想再深入点,就只能看源码了,比如 nacos 配置文件:
大概就是配置向这个地址的 nacos 注册中心注册本工程服务。那如果就想知道向 nacos 发起请求 注册自己的代码在哪里呢?
搭眼一看:
我们感觉请求 nacos 注册自己的代码应该在 nacos-discovery.jar 中,因为正好感觉 nacos-config.jar 应该对应下图中的“配置”部分,那“发现”部分对应 nacos-discovery.jar 咯!
我们点进去发现文件、文件夹也是不少的:
如果像看小说一样逐个逐个翻看不知要看到何年何月,所以找到技巧是关键。
你想啊 “spring.cloud.nacos.discovery.server-addr” 引用的是 “spring.cloud.nacos.config.server-addr”,而 “spring.cloud.nacos.config.server-addr” 的值又为 “127.0.0.1:8848”,也就是 nacos 注册中心的地址,自己的服务启动后,肯定向此地址发起请求,只是具体请求协议不清楚罢了。于是我们尝试在 nacos-discovery.jar 中全局搜索 “spring.cloud.nacos.discovery.server-addr”,搜到了:
这个类感觉像是读取 nacos 服务发现相关配置的配置文件类,有点像我们自己的业务 mysql、redis 等配置类,我们猜想请求 nacos 肯定会使用此类获取配置的 nacos 地址,所以搜索此类的 “find useage”:
发现有太多地方用了:
找着也挺费劲的。
那有没有一种迅速的“直捣黄龙”式的搜索方式呢?于是想到了报错驱动式,我们如果把“spring.cloud.nacos.config.server-addr” 配置成一个错的,比如配置成 “127.0.0.1111.8848”,项目启动肯定会报错,我们根据报错信息或者报错的位置应该很大概率找到关键信息,因为报错的地方就是向此地址,也就是nacos地址发出请求的位置( 很像大奸臣赵高为了找到哪些人反对自己,就故意指鹿为马,相当于故意将配置改错,而电脑就相当于哪些正义的按照正确逻辑执行的低情商的忠臣,按照他们的逻辑肯定不认鹿是马的Bug,于是赵高就得逞了 )。
故意将 “spring.cloud.nacos.config.server-addr” 修改成错误地址后,重启工程:
我们从众多报错信息中找到了关键的报错信息:
Caused by: com.alibaba.nacos.api.exception.NacosException: failed to req API:/nacos/v1/ns/instance after all servers([127.0.0.111:8848]) tried: java.net.ConnectException: Connection refused: connect
at com.alibaba.nacos.client.naming.net.NamingProxy.reqApi(NamingProxy.java:556) ~[nacos-client-1.4.2.jar:na]
at com.alibaba.nacos.client.naming.net.NamingProxy.reqApi(NamingProxy.java:498) ~[nacos-client-1.4.2.jar:na]
at com.alibaba.nacos.client.naming.net.NamingProxy.reqApi(NamingProxy.java:493) ~[nacos-client-1.4.2.jar:na]
at com.alibaba.nacos.client.naming.net.NamingProxy.registerService(NamingProxy.java:246) ~[nacos-client-1.4.2.jar:na]
at com.alibaba.nacos.client.naming.NacosNamingService.registerInstance(NacosNamingService.java:212) ~[nacos-client-1.4.2.jar:na]
at com.alibaba.cloud.nacos.registry.NacosServiceRegistry.register(NacosServiceRegistry.java:74) ~[spring-cloud-starter-alibaba-nacos-discovery-2.2.6.RELEASE.jar:2.2.6.RELEASE]
... 27 common frames omitted
这里 “[127.0.0.111:8848]” 是个数组,如果 nacos 是集群模式则这里就是多个ip+端口的组合,这里是尝试向这个数组中所有的 nacos 节点发起 /nacos/v1/ns/instance 请求后都失败了。所以代码里肯定有 /nacos/v1/ns/instance,搜索一下试一试。或者直接搜索 MamingProxy 这个类:
发现既不是在 nacos-config也不是在 nacos-discovery中,但是从“at com.alibaba.cloud.nacos.registry.NacosServiceRegistry.register(NacosServiceRegistry.java:74) ~[spring-cloud-”可以看出请求入口确实是在 nacos-discovery中的 NacosServiceRegistry类中:
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)