Learn Dubbo from scratch - Basics -Dubbo architecture design

Here it is mainly composed of four parts:

Provider: exposes the service Provider of the service
- Protocol is responsible for Protocol interaction data between providers and consumers
- Service Real business Service information can be understood as interfaces and implementations
- Running environment of Container Dubbo
Consumer: Service Consumer that invokes the remote service
- Protocol is responsible for Protocol interaction data between providers and consumers
- The Cluster is aware of the list of providers
- Proxy can be understood as a provider’s service invocation Proxy class that takes over the interface invocation logic in the Consumer
Registry: A Registry where both providers and consumers register for work such as service discovery and routing configuration
Monitor: Data statistics for providers and consumers, such as call frequency, number of successes and failures, and so on.

The provider side startup container is responsible for loading the Service information and registering it with the registry through Protocol
The consumer starts by listening to the provider list to sense the provider information and notifies the consumer through the registry when the provider changes
The consumer initiates a request and uses the Cluster module to select the actual provider information to be sent through the Proxy module
The Protocol in the Consumer sends the information to the provider
The provider also needs to process the consumer’s information through the Protocol module
The final processing is done by the actual Service provider, Service

The consumer makes method calls through the Interface and the Proxy on the consumer end creates Proxy objects through the ProxyFactory using JDK Javassist technology
Give the Filter module a unified Filter request
Next comes the main Invoker call logic
1. Configure the newly read information through Directory and finally get all invokers through the list method
2. The Cluster module selects the Invoker list according to the specific routing rules
3. The LoadBalance module selects a specific Invoker based on the load balancing policy to process our request
4. If an error occurs during execution and the retry mechanism is configured in the Consumer phase, the execution is retried
Continue through Filter to perform the function before and after the encapsulation Invoker select the specific execution protocol
The client encodes and serializes and then sends the data
The received data arriving at the Server in the Provider is de-encoded and deserialized here
Use the Exporter select actuator
Pass a provider-side Filter to the Filter to the Invoker executor
Invoke the concrete implementation of the interface through Invoker and return

Basically the same as the overall call link diagram, from vertical to horizontal, and richer content.

In the figure, the interfaces used by the service consumer on the left with a light blue background, the interfaces used by the service provider on the right with a light green background, and the interfaces used by both parties on the central axis.
The figure is divided into ten layers from bottom to top, and each layer is one-way dependency. The black arrow on the right represents the dependency relationship between layers. Each layer can be stripped of the upper layer and reused, among which Service and Config layers are API, and other layers are SPI.
In the figure, the green blocks are extension interfaces and the blue blocks are implementation classes. The figure only shows the implementation classes used to associate each layer.
In the figure, the dotted blue line is the initialization process, that is, the assembly chain at startup, the solid red line is the method call process, that is, the run-time call chain, the purple triangle arrow is the inheritance, you can regard the subclass as the same node of the parent class, and the text on the line is the method called.

The Service business layer includes our business code such as interface implementation classes directly to the developer

The Config layer provides external configuration with ServiceConfig ReferenceConfig as the core, which can directly initialize the configuration class or parse the configuration file
Proxy service proxy layer either producer or consumer framework will generate a proxy class and the whole process is transparent to the upper layer, that is, the business layer is not sensitive to remote calls
The registry layer encapsulates the registration and discovery of service addresses centered on the SERVICE URL
The Cluster routing layer (cluster fault tolerance layer) provides routing and load balancing for multiple providers and it Bridges registries with Invoker at their core
The information related to RPC calls at the monitor layer, such as the success or failure of calls, and the call time, is completed at this layer
The Protocol remote call layer encapsulates RPC calls. Both the exposure of the service and the reference to the service are the main entry point in the Protocol responsible for the entire life cycle of the Invoker. All models in Dubbo resemble Invoker

The Exchange information exchange layer encapsulates request and response patterns such as converting requests from synchronous to asynchronous
Transport Unified network transport interfaces such as NetTY and MINA are unified into one network transport interface
The Serialize data serialization layer manages the serialization and deserialization of data transfers across the framework

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.