关于dubbo:Arthas-定位-Dubbo-手动注册-Eureka-异常

55次阅读

共计 2642 个字符，预计需要花费 7 分钟才能阅读完成。

作者 | java_keith
起源 | 阿里巴巴云原生公众号

很久没有写技术分享博客，因为发现一个好的工具的确有点忍不住分享一下，毕竟独乐乐不如众乐乐。> 这里须要说的配角就是 Artahs。> Arthas 应用文档很具体，我这里次要记录一下应用 Arthas 的一点总结。

在一个大的团队外面，会因为很多历史起因或客观因素导致技术栈并不对立，咱们就遇到这么一个问题。老我的项目是应用 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 上 Ognl 如何查看 Load 实例中的非动态域，间接获取是无奈获取的，因为没有存在在 Arthas 上下文中，所以变通一下思路：通过 Main 的动态域获取实例，再通过实例变量获取非动态域的值。技术没有终止，愿你我一起提高。为开源奉献微薄的力量。若对细节有趣味的敌人，可留言交换。

为了让更多开发者开始用上 Arthas 这个 Java 诊断神器，往年 3 月 26 日，Arthas 社区联结 JetBrains 推出 Arthas 有奖征文活动： 聊聊这些年你和 Arthas 之间的那些事儿。 流动已进行至第七期，点击链接即可参加：http://alibabacloud.mikecrm.com/9khcRrs，欢送大家踊跃投稿，参加即有可能获奖！

正文完