Whether it’s Dubbo or Dubbox, including in the previous talk about Dubbo I: Why do you choose “described in other frameworks, its essence is a remote invocation framework, and the demand for remote call if not distributed, is actually don’t need to use such a heavy framework, only in a distributed, have Dubbo such demand of distributed service framework, namely a remote service invocation of distributed framework, the key lies in the distributed governance. What core capabilities does a framework like Dubbox bring to distributed governance?
1 Dubbo core functions
- Remoting: Provides abstract encapsulation of various NIO frameworks, including “synchronous to asynchronous” and “request-response” modes of information exchange.
- Cluster: a service framework that provides transparent remote procedure calls based on an interface approach, including multi-protocol support, and Cluster support such as soft load balancing, failure tolerance, address routing, and dynamic configuration.
- Registry: service Registry, based on the Registry directory services, so that service consumers can dynamically find service providers, make address transparent, so that service providers can smoothly add or reduce machines.
For the above three core functions, what component roles are involved in Dubbo to collaborate on distributed governance?
2 Role of Dubbo component
| Component role | instructions |
|---|---|
| Provider | Expose the service provider of the service |
| Consumer | The service consumer that invokes the remote service |
| Registry | A registry for service registration and discovery |
| Monitor | A monitoring center for counting service invocation times and invocation times |
| Container | Service run container |
Description of the calling relationship:
- The service Container starts, loads, and runs the service provider.
- At startup, a service Provider registers its services with a registry.
- At startup, a Consumer subscribes to the registry for the services he or she needs.
- The Registry returns a list of service provider addresses to the consumer, and if there are changes, the Registry will push the change data to the consumer based on the long link.
- Service Consumer, from the list of provider addresses, based on the soft load balancing algorithm, select one provider to call, if the call fails, select another call.
- The service Consumer and the Provider accumulate the number of calls and the call time in the memory, and periodically send statistical data to the monitoring center every minute.
3 Overall Dubbo architecture
What has been described above is an abstract level of component relationship, so to speak, a vertical analysis of components in a service model. In fact, Dubbo’s greatest feature is that it is structured in a hierarchical way, which allows the various layers to be decoupled (or loosely coupled) to the maximum extent possible. So, let’s take a horizontal look at Dubbo’s architecture in a hierarchical way, as shown in the figure below:
The Dubbo framework design is divided into 10 layers, with the top Service layer being the interface layer for the developers who actually want to develop distributed services using Dubbo to implement the business logic. In the figure, the interfaces used by the service consumer are on the blue background on the left, the interfaces used by the service provider are on the green background on the right, and the interfaces used by both parties are on the central axis.
Below, in combination with the official Dubbo documentation, let’s take a look at the design points of each layer in the framework hierarchy:
- Service interface layer (Service) : Related to the actual business logic, according to the Service provider and Service consumer business design corresponding interface and implementation.
- Configuration layer (Config) : External configuration interface, centered around ServiceConfig and ReferenceConfig, can be directly new configuration classes, or Spring can parse configuration to generate configuration classes.
- Proxy layer: Transparent Proxy for the service interface. It generates the client Stub and server Skeleton of the service. The ServiceProxy is the center and the extended interface is ProxyFactory.
- Service Registry: Encapsulates the registration and discovery of service addresses, centering on the service URL and extending interfaces to RegistryFactory, Registry, and RegistryService. There may be no service registry, in which case the service provider exposes the service directly.
- Cluster layer: Encapsulates routing and load balancing for multiple providers and Bridges the registry, centered around Invoker and extending interfaces to Cluster, Directory, Router, and LoadBalance. Combine multiple service providers into a single service provider to achieve transparency to service consumers, interacting with only one service provider.
- Monitor: Monitors the number and time of RPC calls. The Statistics layer is the center. The extended interfaces are MonitorFactory, Monitor, and MonitorService.
- Protocol: Encapsulates RPC calls, centred on Invocation and Result, and extends the interfaces to Protocol, Invoker, and Exporter. Protocol is the service domain, which is the main functional entry for Invoker exposure and reference, and it is responsible for the lifecycle management of Invoker. Invoker is the entity domain, which is Dubbo’s core model to which other models invoke or convert. It represents an executable to which an invoke call can be made. It may be a local implementation, a remote implementation, or a cluster implementation.
- Exchange layer: Encapsulates Request and Response mode, transfers synchronization to asynchronous, centers on Request and Response, and extends interfaces such as Exchange channel, Exchange SERVER, and ExchangeServer.
- The Network Transport layer: Mina and Netty are abstract unified interfaces, which are messe-centric and extend to Channel, Transporter, Client, Server, and Codec.
- Serialize: Reusable tools that extend interfaces to Serialization, ObjectInput, ObjectOutput, and ThreadPool.
As you can see from the figure above, Dubbo provides service providers and service consumers with interfaces that they need to care about and extend from each of the 10 layers of the framework to build the entire service ecosystem (service providers and service consumers are themselves service-centric).
According to the official description of the relationship between the above layers, it is as follows:
- In RPC, Protocol is the core layer, that is, as long as there is Protocol + Invoker + Exporter, you can make a non-transparent RPC call, and then Filter the interception point on the main procedure of Invoker.
- Consumer and Provider in the diagram are abstract concepts, just to let the viewer more intuitive understanding of which categories belong to the client side and server side. The reason for not using Client and Server is that Dubbo uses Provider, Consumer, Registry, and Monitor to divide logical top nodes in many scenarios to maintain a unified concept.
- Cluster is a peripheral concept, so the purpose of Cluster is to disguise multiple invokers as one Invoker, so that other people can only focus on the Protocol layer Invoker, adding Cluster or removing Cluster will not affect the other layers. Because when there is only one provider, there is no need for a Cluster.
- Proxy layer encapsulates transparent proxies of all interfaces, while other layers are centered on Invoker. Only when exposed to users, Proxy is used to turn Invoker into interface, or interface implementation into Invoker. In other words, RPC can be Run without Proxy layer, but it is not so transparent. It doesn’t look like you’re calling a remote service like you’re calling a local service.
- If you choose RMI, all Remoting will not be used. The Transport layer is divided into the Exchange layer. The Transport layer is only responsible for one-way message transmission. The Exchange layer encapsulates request-response semantics on top of the transport layer.
- Registry and Monitor are not really a layer, but separate nodes, drawn together as layers for the overall overview.
4 Service invocation process
5 Register/Deregister services
For the role of the service provider, the registration and deregistration of services is the sequence diagram, as shown in the figure:
6 Subscribe/Cancel services
To meet application requirements, a service consumer may need to subscribe to a service published by a specified service provider from a service registry and invoke the service directly when notified of its availability. Conversely, if a service is no longer needed, you can cancel it. Take a look at the corresponding sequence diagram, as shown in the figure below:
7 References and recommended reading
- dubbo.io
- Dubbo architecture design in detail