1. Explanation of the basic concepts of Duboo
Dubbo is a distributed service framework. Webservice is also a service framework, but webservice is not a distributed service framework. It needs to combine F5 to achieve load balancing. Therefore, in addition to providing services, dubbo can also achieve soft load balancing. It also provides two functions Monitor monitoring center and calling center. These two are optional and need to be configured separately.
Dubbo's counting architecture diagram is as follows:
We explain the following architecture diagram:
Consumer service consumers, Provider service providers. Container service container. Consumption is of course the invoke provider. The solid line of invoke is of course synchronized according to the description in the figure. One more thing, in the actual invocation process, the location of the provider is transparent to the consumer. The last time the service was invoked The location (IP address) and the location of the next call to the service are indeterminate. This is where the soft load is implemented.
The service provider starts start first, and then registers the register service.
Consumers subscribe to the subscribe service. If it does not subscribe to the service it wants to obtain, it will continue to try to subscribe. After new services are registered in the registry, the registry will notify consumers of these services.
Monitor is a monitoring. The dotted line in the figure indicates that the Consumer and the Provider send messages to the Monitor in an asynchronous manner. The Consumer and the Provider will store the information on the local disk, and the information will be sent once an average of 1 minute. Monitor is optional in the entire architecture (the dotted line in the figure does not mean optional), and the Monitor function needs to be configured separately. If it is not configured or configured, Monitor hangs up and will not affect service calls.
2. The principle of dubbo
The content of this blog is generally abstract. If a student wants to use dubbo right away, the effect of reading this blog is not very good. This blog does not describe how to use and configure dubbo. Next, I will write another one. Getting started with dubbo includes a blog with demos.
I. Details of the initialization process:
The first step in the above figure, start, is to load the service into the container, and then prepare to register the service. Similar to the startup process in Spring, when spring starts, when the bean is loaded into the container, the bean must be parsed first. So dubbo also reads the configuration file parsing service first.
Resolution service:
1) Based on the Meta-inf/spring.handlers configuration in dubbo.jar, when spring encounters the dubbo namespace, it will call back the DubboNamespaceHandler class.
2) All dubbo tags are parsed uniformly with DubboBeanDefinitionParser, and based on one-to-one attribute mapping, XML tags are parsed into Bean objects.
Source code screenshot:
When initializing ServiceConfig.export or ReferenceConfig.get, convert the Bean object to url format, and convert all bean properties into url parameters.
Then pass the URL to the Protocol extension point. Based on the Adaptive mechanism of the extension point, according to the protocol header of the URL, the services of different protocols are exposed and referenced.
Expose services:
a. Only expose service ports
In the case where the registry is not used, this situation is generally applicable in the development environment. The service call is provided on the same IP, and only the port of the service needs to be opened. That is, when the format of the URL parsed by the
configuration or ServiceConfig is: Dubbo://service-host/com.xxx.TxxService?version=1.0.0 Based on the Adaptiver mechanism of the extension point, through the "dubbo://" protocol of the URL Header identification, directly call the export() method of DubboProtocol to open the service port.
b. Expose services to the registry:
The difference from the previous one: the IP and port of the service need to be exposed to the registry together.
The url format parsed by ServiceConfig is:
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0 .0”)
Based on the Adaptive mechanism of the extension point, it is identified by the "registry://" protocol header of the URL, and the export method of the RegistryProtocol is called to first register the provider URL in the export parameter with the registry, and then re-pass it to the Protocol extension point for exposure:
Dubbo://service-host/com.xxx.TxxService?version=1.0.0
Citation Services:
a. Direct reference service:
In the case of a direct connection provider without a registry,
the URL format parsed by ReferenceConfig is:
Dubbo://service-host/com.xxx.TxxService?version=1.0.0
The Adaptive mechanism based on the extension point is identified by the "dubbo://" protocol header of the url, and the refer method of the DubboProtocol is called directly to return the provider reference.
b. Discover the reference service from the registry:
At this time, the format of the URL parsed by ReferenceConfig is:
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode(“consumer://consumer-host/com.foo. FooService?version=1.0.0")
The Apaptive mechanism based on the extension point, identified by the "registry://" protocol header of the URL, will call the refer method of the RegistryProtocol, and query the provider URL based on the total conditions of the refer parameters, such as:
Dubbo://service-host/ com.xxx.TxxService?version=1.0.0
Based on the Adaptive mechanism of the extension point, identified by the "dubbo://" protocol header of the provider URL, the refer() method of DubboProtocol will be called to get the provider reference.
The RegistryProtocol then returns multiple provider references through the Cluster extension point, disguised as a single provider.
3. Remote call details:
The detailed process of the service provider exposing a service:
The above figure is the main process of the service provider exposing the service:
First, the ServiceConfig class gets the actual class ref that provides services to the outside world, and then the getInvoker method of the ProxyFactory class uses the ref to generate an AbstractProxyInvoker instance, to This step completes the conversion of specific services to invokers. The next step is the process of converting Invoker to Exporter.
The key to Dubbo's handling of service exposure is the process of converting Invoker to Exporter. Let's illustrate with the implementation of two typical protocols, Dubbo and rmi:
Dubbo implementation:
The Invoker of Dubbo protocol is converted to Exporter in the export method of the DubboProtocol class. , which mainly opens the socket listening service and receives various requests from the client. The communication details are implemented by dubbo itself.
Implementation of Rmi:
The Invoker of the RMI protocol is converted to the Exporter in the export method of the RmiProtocol class. It implements the service through Spring, Dubbo or JDK, and the communication details are implemented by the bottom layer of the JDK.
The detailed process
of a service consumer consumes a service The above figure shows the main process of service consumption:
first, the init method of the ReferenceConfig class calls the refer method of the Protocol to generate an Invoker instance. Next, convert Invoker to the interface required by the client