Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "how to solve the Arthas positioning Dubbo manual registration Eureka exception". In the operation of the actual case, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Use background

In a large team, we encounter such a problem that the technology stack is not unified due to many historical reasons or objective factors. The old project is to use the Dubbo protocol of the Dubbo framework for service interaction, while the new project is to use the Http protocol of the Feignclient framework of the Springcloud system for interaction. Then there are two problems that need to be solved.

Problem 1 is that Dubbo services need to support both Dubbo and Http protocols.

Problem 2 is that the Feignclient framework can call the Http protocol of Dubbo service without loss (lossless means that Dubbo can dynamically perceive the service to the Feignclient caller, and the load balancer does not need to do secondary development).

Solution idea

With the above goals, we need to find a way to solve the problem. The first problem is relatively easy to solve. The Http protocol provided by Dubbo itself is leaked. That is to say, the problem of upgrading and configuring the old project Dubbo is solved.

But for question 2, we can make a list of the problems encountered. The Dubbo registration uses the zk registry, and the Springcloud project uses the Eureka registry. By the way, I would like to praise the Feignclient framework. The threshold for Feignclient access service is very low, which is compatible with the differences brought by many languages, environments, etc., that is, as long as it is the interface of http protocol, Feignclient can be called. In fact, it is possible to directly call the Http protocol interface of Dubbo service exposure through Feignclient, but it is impossible to achieve load balancing, failover and other capabilities. After all I've said, let's sum up.

Now the Http protocol of the Feignclient directly connected Dubbo framework project can be implemented normally.

In a distributed environment, we need to solve the disadvantages of direct connection (unable to load balance, fail to transfer, unable to dynamically expand capacity, etc.). Fortunately, after analyzing the Eureka source code, Eureka opens another door. Eureka is actually an independent component and provides manual registration service (even without modifying the source code). The solution now is to introduce Eureka components into the Dubbo project and manually register the service with Eureak so that Feignclient can invocate without loss.

The protagonist (Arthas) enters the stage

In order to provide the Dubbo framework project with the ability to register for Eureka, and to be able to go online and offline gracefully. We mainly rely on the Container extension in Dubbo's Spi extension capability. The code is as follows:

Class EurekaDubboContainer implements Container {...}

One more important thing to do with the above code is to declare the full path of the Container. META-INF/dubbo/org.apache.dubbo.container.Container:xxx=com.xxx.XxxContainer, we configured the code spring=com.xxx.EurekaDubboContainer here at that time. When everything was ready, we started the project and found that there was no abnormal output and the process was perfect. But Deignclient cannot be called in any way. The most important thing is that there is no abnormal output during startup, and after a lot of argumentation, I was ecstatic when I found that Arthas,Arthas could check the property values of objects in memory and how to execute objects. Through the previous source code analysis of the Dubbo registration process:

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);}

During the Dubbo startup process, the Container configured in the configured META-INF is scanned from the Jar package. When loading, the exception is directly stored in the domain of the Loader class. It is speculated that the exception is not thrown to solve the Container isolation. The current main goal is to analyze why the extension I defined is easy not to start. After deploying Arthas, I began the road of analysis.

Sc-d * .EurekaDubboContainer found that the class has been loaded normally, indicating that it has been loaded by Load.

Jad *. EurekaDubboContainer found that the loaded class code is also normal (excluding the possibility that the package is incorrect).

Ognl'# loader=@com.alibaba.dubbo.container.Main@loader,#loader.cachedInstances' found a problem here. If it is normally Load, the Container will be stored in the CachedInstances domain of ExtensionLoader (the default Spring,log4j exists), but my custom Container can not be found.

Ognl'# loader=@com.alibaba.dubbo.container.Main@loader,#loader.exceptions' found all the reasons why the load did not succeed, which is stated in Exceptions.

From the above analysis, the problem is very obvious, and the Key specified in META-INF is repeated. I still don't have a deep understanding of the meaning of 'xxx'' on the Spi document in Dubbo. After modifying the Key here, everything goes according to plan.

"Arthas location Dubbo manual registration Eureka exception how to solve" content is introduced here, thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.