Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the service citation process of Dubbo". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the service citation process of Dubbo".

General process of service reference

We have learned that Provider exposes its services and registers with the registry, while Consumer simply gets the information of Provider from the registry through a wave of operations, and then encapsulates a calling class to communicate deeply with Provider.

In previous articles, I have mentioned that an executable in Dubbo is Invoker, and all calls should be closer to Invoker, so we can infer that we should become an Invoker, and then because the framework needs to develop in a direction that does not invade the business code, then our Consumer needs to invade the remote interface without awareness, so we need to set up a proxy class to shield the underlying details.

The overall process is as follows:

When the service is introduced, the introduction of the service is the same as the exposure of the service, it is also parsed through the spring custom tag mechanism to generate the corresponding Bean,Provider Service corresponding to parsing ServiceBean and Consumer Reference corresponding to ReferenceBean.

As we analyzed in the previous article, the timing of service exposure begins to be exposed after the Spring container is refreshed, and there are two opportunities for the introduction of services, the first is hungry Chinese, and the second is lazy.

The hungry Han style implements the afterPropertiesSet method in the InitializingBean interface of Spring, and the container introduces the service when calling the afterPropertiesSet method of ReferenceBean.

Lazy style is to start the introduction process only when the service is injected into other classes, that is, to start the service introduction when it is used.

By default, Dubbo uses lazy Chinese style to introduce services. If you need to use hungry Chinese style, you can enable it by configuring the init attribute of dubbo:reference.

We can see that ReferenceBean has also implemented the FactoryBean interface. Here is a pilot project about Spring. I'll take you to analyze it.

BeanFactory 、 FactoryBean 、 ObjectFactory

These are the three things. I'll take them out separately. Literally, we can see that BeanFactory and ObjectFactory are factories and FactoryBean is Bean.

BeanFactory is actually an IOC container, there are a variety of implementation classes I will not analyze, to put it simply, the Bean in Spring belongs to it, and FactoryBean is also Bean, so it is also managed by BeanFactory.

So what kind of Bean is FactoryBean? It actually encapsulates the Bean you really want, and when you really want to get the Bean, the container will call the FactoryBean#getObject () method, and in this method you can do some complex assembly operations.

This method encapsulates the complex process of creating the object you really want.

As a matter of fact, it is very clear here, that is, when the creation of the Bean you really want is relatively complex, or when some third-party Bean is difficult to modify, FactoryBean is used to encapsulate a layer, shielding the details of the creation of the underlying layer, so as to facilitate the use of Bean.

ObjectFactory, which is used to delay lookup, is an ordinary factory. When you get an ObjectFactory object, it means that Bean has not been created, and only when the getObject () method triggers the life cycle such as Bean instantiation.

It is mainly used to obtain a Bean Holder object temporarily. If you load it prematurely, it may cause some unexpected situations. For example, when Bean A depends on Bean B, if you initialize A prematurely, then the state in B may be an intermediate state, and using An at this time can easily lead to some errors.

To sum up, BeanFactory is an IOC container, FactoryBean is a special Bean, which is used to encapsulate complex objects, while ObjectFactory is mainly used to delay search scenarios and delay instantiation of objects.

Three ways to introduce services

The introduction of services is divided into three types, the first is local introduction, the second is direct connection to introduce remote services, and the third is the introduction of remote services through the registry.

Local introduction I don't know if you still have an impression. In the previous service exposure process, each service will follow the injvm protocol by making a local exposure (of course, if you scope = remote, there will be no local reference), because there is a situation in which the server is both Provider and Consumer, and then it is possible to call its own service, so it makes a local introduction, which avoids the overhead of remote network calls.

Therefore, the introduction of services will first go to the local cache to see if there are any local services.

Direct connection remote introduction service, which is actually used in the case of daily testing. There is no need to start the registry. Consumer directly configures the address of the dead Provider, and then connects directly.

The registry introduces remote services, which is the key point. Consumer learns the relevant information of Provider through the registry, and then introduces the service. This also includes the case of multiple registries and multiple providers of the same service, how to choose how to encapsulate, how to load balance, how to tolerate faults and make users unaware. This is a technical activity.

This article uses a single registry to introduce remote services. Let's take a look at how Dubbo does it.

Service introduction process parsing

The default is lazy, so the entry into the service is the getObject method of ReferenceBean.

As you can see, it's simple to call the get method, and execute the init method if you don't already have this reference.

A small problem on the official website.

In the if (ref = = null) line, in fact, an old brother found that the ref was not equal to null when debugging, so he could not enter the init method to debug. Later, he found that it was because IDEA would obtain the corresponding information of the object through the toString method in order to display the object information.

ToString calls AbstractConfig#toString, and this method invokes the getObject method of ReferenceBean through reflection, triggering the incoming service action, so when it comes to breakpoints, ref! = null.

You can see that the reflection call is made through the method name, and getObject starts with get, so it is called.

So this guy mentioned a PR, but at first it was not accepted. A Member thought that it was not bug, and idea would have set it not to call toString.

However, another Member thought the PR was good, and the second-generation head of the Dubbo project, Beiwei 30, also spoke, so the PR was accepted.

At this point, we already know about this small problem, and then the official website actually wrote very clearly.

But there is a small problem. I mentioned in the article that my source code version is 2.6.5, which is in the releases of github. In fact, I knew about this tostring problem a long time ago. I was thinking about my 2.6.5 stable batch, who knew it was flipped over.

When I debug, I did not enter the init method because ref is not equal to null, so I was surprised. I went inside to take a look at the toString method, and version 2.6.5 was not modified. The getObject was not filtered, so it was called anyway.

I opened the 2.7.5 version of the code and found that it was a modified judgment.

I deliberately put down the 2.6.6 version of the code, and found that it was also modified, so this change is not released with 2.6.5, but 2.6.6, unless I am under a fake package, this is what I call a small problem, but the impact is not significant.

In fact, what I mainly want to talk about in this paragraph is that PR, as an exporter of open source software, many details are also very important, this problem actually affects the debugging of the source code, because if you are not familiar with the code, you will certainly look confused. Who knows which background thread has been introduced asynchronously?

The brother who mentioned this PR took two hours to figure out the real reason, so although this is not a bug, it has a great impact on those students who want to understand the internal structure of Dubbo deeply. This scheme of changing the configuration to adapt is not advisable. Fortunately, the ultimate solution is to change the code.

All right, let's get back to today's topic, and then we'll analyze the init method that won't let me in.

Source code analysis

The init method is long, but most of it is to check the configuration and build the configuration into map, which I won't analyze, but let's just take a look at what the built map looks like.

Then go to the key method createProxy, which you can get from the name is a proxy to be created, because the code is very long, I will analyze it piece by piece.

If it is local, then directly build a URL based on the local protocol and then introduce the service, that is, refprotocol.refer. This method will be analyzed later, and the local introduction is not in-depth, that is, you can get the service from the exporterMap exposed by the previous service.

If it is not local, it must be remote. The next step is to determine whether it is a point-to-point direct connection to provider or to get the provider information through the registry and then connect to provider. Let's analyze the situation where url is configured. If url is configured, it is either a directly connected address or the address of the registry.

Then there is the case that url is not configured, and what we must go here is the registry to introduce remote services.

The final spliced URL looks like this.

You can see that this part is actually based on a variety of parameters to assemble URL, because our adaptive extensions need to be based on the parameters of URL.

At this point, I would like to draw a picture and sort it out for you.

In fact, this is the whole process. In a brief description, we first check the configuration, build a map through configuration, then use map to build URL, and then call the corresponding protocol.refer through the protocol on URL to get the corresponding invoker.

When there are multiple URL, first traverse to build the invoker, then encapsulate it by StaticDirectory, and then merge through cluster, exposing only one invoker.

Then build the proxy, encapsulating the invoker to return the service reference, and then Comsumer invokes this proxy class.

I believe that through the figure and the summary above, we already know the general service introduction process, but there are still a lot of details, such as how to get the address of Provider from the registry, what is it like in invoker? Don't worry, let's keep looking.

From the previous screenshot, we can see that the protocol at this time is registry, so it is RegistryProtocol#refer. Let's take a look at this method.

The main thing is to get the registry instance and then call doRefer for the real refer.

This method is very critical, you can see that the directory generated RegistryDirectory clogs the registry instance, and it also implements the NotifyListener interface, so the registry snooping is actually handled by this guy.

Then register its own information with the registry, and subscribe to the registry for providers nodes, configurators nodes and routers nodes. After subscribing, RegistryDirectory will receive the information under these nodes, which will trigger the generation of DubboInvoker, that is, Invoker for remote calls.

The Invoker is then re-wrapped through cluster, so a service may have multiple providers, and eventually record this information in ProviderConsumerRegTable and return Invoker.

So we know that Conusmer registers its own information with the registry in RegistryProtocol#refer and subscribes to some information about Provider and configuration. Let's take a look at what the subscription returns.

After getting the information of Provider, you can trigger DubboProtocol# refer by listening (which protocol is called or depends on the protocol of URL. Here is the dubbo protocol). I will not follow the whole trigger process one by one, and it will be clear if you look at the call stack.

Finally, we got the information of the remote Provider from the registry, and then introduced the service.

The focus here is on getClients, because after all, you have to make network calls with the remote service, and getClients is used to obtain the client instance, the instance type is ExchangeClient, the underlying layer relies on Netty for network communication, and you can see that the default is shared connection.

GetSharedClient I will not analyze, that is, through the remote address to find client, this client also has the function of reference counting, if the remote address does not have client, then call initClient, let's take a look at the initClient method.

And this connect finally returns HeaderExchangeClient, which encapsulates NettyClient.

Then the final Invoker is like this. You can see a lot of recorded information, basically everything you should have. What I am going through here is the case where there is only one url for the corresponding service, and multiple url is nothing more than using directory and cluster to encapsulate another layer.

Eventually return (T) proxyFactory.getProxy (invoker) will be called; a proxy object will be returned and this will not be analyzed.

At this point, the whole process is over. I don't know if everyone is clear. I would like to add the previous figure, to a complete process for you to go through again.

Thank you for your reading. the above is the content of "what is the service reference process of Dubbo". After the study of this article, I believe you have a deeper understanding of what the service reference process of Dubbo is, and the specific usage needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.