本篇内容介绍了“Arthas定位Dubbo手动注册Eureka异常怎么解决”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
创新互联于2013年创立，是专业互联网技术服务公司，拥有项目网站建设、成都网站建设网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元赣州做网站,已为上家服务,为赣州各地企业和个人服务,联系电话:18980820575
在一个大的团队里面，会因为很多历史原因或客观因素导致技术栈并不统一，我们就遇到这么一个问题。老项目是使用 Dubbo 框架的 Dubbo 协议进行服务交互，有新的项目是使用 Springcloud 体系的 Feignclient 框架的 Http 协议进行交互。那么就需要解决两个问题。
问题 1 是 Dubbo 服务需要支持 Dubbo 协议又需要支撑 Http 协议。
问题 2 是 Feignclient 框架能够无损调用 Dubbo 服务的 Http 协议（无损指的是 Dubbo 对 Feignclient 调用方能够做到服务动态感知，负载均衡不需要做二次开发）。
有了以上的目标，我们就需要想办法解决问题。解决第一个问题倒是比较容易，Dubbo 本身就提供的 Http 协议暴漏。也就是将老工程 Dubbo 升级、配置两种协议问题一就这么解决了。
但是针对问题 2，我们可以罗列一下遇到的问题。Dubbo 注册使用的是 zk 注册中心，Springcloud 工程使用 Eureka 注册中心。这里顺带也要赞美一下 Feignclient 框架，Feignclient 接入服务的门槛很低，这样兼容了很多语言、环境等带来的差异，也就是说只要是 http 协议的接口 Feignclient 就能调用。到这里实际上通过 Feignclient 直接调用 Dubbo 服务暴漏的 Http 协议接口是能够走的通，只不过没法做到负载均衡，失败转移等能力。说了这么多总结一下吧。
现在通过 Feignclient 直连 Dubbo 框架工程的 Http 协议能够正常执行。
分布式环境下需要解决直连的弊端（无法负载均衡，无法失败转移，无法动态扩容等等） 好在通过分析了 Eureka 源码以后打开了另一个大门，Eureka 实际上是独立的组件，而且提供手动注册服务的能力（即使没有修改源码就有了）。现在解决思路就是在 Dubbo 工程里面引入 Eureka 组件，手动将服务注册到 Eureak 以便 Feignclient 能够无损调用。
为了将 Dubbo 框架工程提供注册 Eureka 的能力，并且能够做到优雅上线和下线。我们主要是借助了 Dubbo 的 Spi 扩展能力中的 Container 扩展。代码如下：
class EurekaDubboContainer implements Container {...}有了以上代码还需要做一件重要的事情，就是声明 Container 的全路径。META-INF/dubbo/org.apache.dubbo.container.Container：xxx=com.xxx.XxxContainer，当时我们配置这里的代码 spring=com.xxx.EurekaDubboContainer，当所有准备好了以后我们启动工程，发现无异常输出，进程完美。但是 Deignclient 怎么也无法调用。最主要是启动过程中没有任何异常输出，经过大量论证后，就在快绝望的时候，我发现了 Arthas，Arthas 可以查看内存中对象属性值以及执行对象的方法，我欣喜若狂。通过之前对 Dubbo 注册过程源码分析：
com.alibaba.dubbo.common.extension.ExtensionLoader#loadFile
} catch (Throwable t) {
IllegalStateException e = new IllegalStateException("Failed to load extension class(interface: " + type + ", class line: " + line + ") in " + url + ", cause: " + t.getMessage(), t);
exceptions.put(line, e);
}在 Dubbo 启动过程，会从 Jar 包中扫描配置的 META-INF 中配置的 Container，在加载的时候这个异常是直接存放在了 Loader 类的域中，猜测可能是为了解决 Container 隔离所以异常并没有抛出。当前主要目标还是分析为啥我定义的扩展容易没有启动。部署 Arthas 以后我开始了分析之路。
sc -d *.EurekaDubboContainer 发现类已经正常加载，说明有被 Load 加载。
jad *.EurekaDubboContainer 发现加载的类代码也是在正常（排除包不对的可能）。
ognl '#loader=@com.alibaba.dubbo.container.Main@loader,#loader.cachedInstances' 这里发现了问题，如果是正常被 Load 的 Container 会被存在到 ExtensionLoader 的 CachedInstances 域中（默认的 Spring，log4j存在），但是我自定义的 Container 竟然没找到。
ognl '#loader=@com.alibaba.dubbo.container.Main@loader,#loader.exceptions' 这里发现了之所有没有加载成功的原因，在 Exceptions 中有声明。
通过以上分析，问题非常明显了，在 META-INF 中指定的 Key 重复了。还是没深入理解 Dubbo 中的 Spi 文档上的‘xxx’是自定义的意思。到这里修改 Key 以后一切按照计划执行。
“Arthas定位Dubbo手动注册Eureka异常怎么解决”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！