4. How are consumers calling
Let's first look at the configuration of the consumer
Then we return to the initial xml parsing process
Seeing that the consumer's reference tag corresponds to ReferenceBean, we open ReferenceBean
ReferenceBean is similar to serviceBean, except that it only implements the ApplicationContextAware and InitializingBean interfaces. The setApplicationContext method is very simple, so we can just look at the afterPropertiesSet method.
This method is relatively simple, similar to the serviceBean, mainly the initialization of some variable data. Then there is no need to open the netty service like the serviceBean, the variable initialization is just fine, I mainly focus on when the referenceBean is converted into an invoker to interact with the serviceBean when it is used. Then here we notice that referenceBean implements the FactoryBean interface, and then about the use of the factoryBean interface can refer to: https://blog.csdn.net/u013185616/article/details/52335864 . It basically means that the class that implements the interface of the factoryBean, when the getBean is adjusted later (if you don’t understand this method, you can look at the spring initialization process, which is probably the entrance used by all beans), the actual call is the getObject of this Bean Interface, so this understands, all the secrets of dubbo consumers are hidden in this getObject method.
Let's look at the getObject method
Follow the get method and find that the get method is in the parent class ReferenceConfig
It's also very simple. Open the init method directly.
Then look at the checkDefault method
The main thing is to initialize the consumer variable. The appendProperties method has been mentioned before. It takes the corresponding value from the jvm running variable and writes it to the consumer.
Then many of the init methods are initialization and verification codes. Similar to serviceBean, we will not analyze them in detail. Then there is a resolve code in the middle. I don’t know what to do, and it doesn’t matter. Let’s look directly at the core things. Is this createProxy(map)
In the case of map, it is the parameters and parameter values of all the previous related variables (the specific analysis is not detailed, mainly depends on the core code), and then I will analyze the following code first, which is to generate a consumerModel and put it in the ApplicationModel. This class has all Provider and comsumer, I don’t know why they are used. There is also serviceBean
Then we open createProxy
Then I didn’t read anything else, it’s the processing on some urls, mainly look at refprotocol.refer(interfaceClass, url)
You can see that a dubboProtocol was generated with SPI here. Then we open the dubboProtocol.refer method:
We see here mainly to create a dubboInvoker instance, and then we look at dubboInvoker
Mainly look at the doInboke method, you can see that the input parameter used here is the RpcInvocation defined by dubbo itself, and the return interface is the RpcResult object.
Let's take a look at RpcInvocation
You can see that this is the method name, parameter type, and specific parameters are all here, indicating that what really needs to be serialized and then transmitted is this RpcInvocation.
Then RpcResult
RpcResult is also very simple, and the result is still abnormal. It's also very clear.
Then we won't look at how to get the client and how to call the network connection, just walk the main process once.
Then look at the end of the createProxy method, getProxy
Then spi defaults to JavassistProxyFactory, continue to open
Then see that getProxy is a typical JavassistProxy creation process of dynamic proxy, and then look at InvokerInvocationHandler
Here you can see that what the agent actually executes is the invoke method of dubboInvoker, and then transmits the method and parameter list.
Then dubboInvoker is responsible for the actual network communication to find the exposed exporter, then execute the actual method, and return the result. Then we are responsible for the balance module, and the module that interacts with the registry will not be looked at.
The specific principle of his interaction, I think it should be through dubboinvoker to find the corresponding exporter based on the same interface, and then execute the actual logic on the exporter side.
Of course, the actual situation is definitely much more complicated, we don't care about it, and it is estimated that we will not change these things.
to sum up:
Let's look back at what technologies dubbo uses. First, he customized the spring tag parser and customized the new bean. Then used SPI, dynamic proxy, serialization and other technologies in the code. Netty is used at the network level to synchronize non-blocking network io services. It is more suitable for scenarios where the amount of data is small, the amount of concurrency is high, and the consumer is much larger than the provider. Then the zookeer is used in the distributed coordination technology, and the zookeer is related: https://www.cnblogs.com/felixzh/p/5869212.html . There are also layers of encapsulation and inheritance of all classes in dubbo. Encapsulation and inheritance personally think that understanding is the main thing. After all, if you really need to implement it yourself, the business and the scene may be different, so the defined classes and interfaces may be different. The key is to integrate the entire dubbo basic technology Just learn. If you let yourself write, you can also write a basic function.
The above is all my process of reading dubbo source code, thank you!