乐趣区

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

jiezi

作者 | 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 可能无损调用。

配角（Arthas）退场

为了将 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 有奖征文正在进行中！

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

退出移动版