In today’s microservices prevailing environment, the design of a high concurrency, high scalability, automatic fault tolerance and high availability of distributed system is undoubtedly inseparable from a set of excellent RPC framework. Dubbo is an open source RPC framework of Alibaba. It is the most popular RPC framework in the market, and companies are rushing to embrace and use it.

Architecture diagram of Dubbo

Dubbo website

role The role that
Provider The service provider that exposes the service
Container Service run container
Consumer Service consumer that invokes the remote service
Registry A registry for service registration and discovery
Monitor A monitoring center that collects statistics on service invocation times and invocation time
Provider Metadata (IP/ port, etc.) is registered with the registry at startup, and consumers subscribe to the registry at startup (the first subscription removes all data). When data changes occur in the registry, they are pushed to subscribing consumers. You can do this after obtaining the metadata from the serverRPCA call,RPCAfter the invocation, statistics (such as the number of concurrent calls and the invoked interface) are reported to the monitoring center, where developers can see how the service is being invoked.
Dubbo’s layering and core components

Level of Ming role
Service The business layer. The business code that we implement.
config Configuration layer. It mainly revolves around ServiceConfig (the location of the exposed service) and ReferenceConfig (the location of the referenced service) two implementation classes to initialize the configuration information. It is understood that this layer manages the configuration of the entire Dubbo.
proxy Service broker layer. In Dubbo, the framework generates a proxy class for both producers and consumers, and the whole process is transparent to the upper layer. When invoking a remote interface as if invoking a local interface, the proxy automatically makes the remote call and returns the result, leaving the business layer completely unresponsive to the remote call.
registry Registered layer. Responsible for service registration and discovery of the Dubbo framework. When a new service joins or an old service goes offline, the registry senses and notifies all subscribers, without human involvement.
cluster Cluster fault tolerance layer. Responsible for fault tolerance policies (retry failures, quick failures, etc.) when remote calls fail. Select load balancing policies (such as random and consistent Hash) for specific node invocation, and routing policies for special invocation paths (for example, a consumer will only use producers of a certain IP address).
monitor Control layer. Mainly responsible for monitoring the number and time of call statistics.
protocol Remote invocation layer. Encapsulating the RPC call details, Protocol is the main functional entry for Invoker exposure (publishing a service for others to call) and reference (applying a remote service locally), which manages the entire lifecycle of Invoker. Invoker is the core model of Dubbo, to which all other models in the framework converge or transform, and which represents an executable. It is possible to invoke a call to him, which could be a local interface implementation, a remote call, or a cluster implementation.
exchange Information exchange layer. Establish a request-response model to encapsulate the Request Response pattern, such as converting synchronous requests into asynchronous ones.
transport Network transport layer. Abstract network traffic into the same interface, such as Mina and Netty, which have different interfaces, but Dubbo encapsulates the same interface on them. Users can also add more network transport modes based on other extension interfaces.
Serialize Serialization layer. If the data is sent over the network, you need to serialize and program binary streams first. The serialization layer is responsible for managing serialization/deserialization of the entire framework network transport.
Dubbo overall call procedure

  1. You start with a Proxy, which holds an Invoker object and triggers an Invoke call.
  2. During an Invoke call, a Cluster is used, which is fault-tolerant and retries if the call fails. The Cluster gets a list of all invokers of remote services that can be invoked from Directory before invoking them.
  3. Then select an Invoker that can be called through load balancing. The Invoker passes through a chain of filters before being called, usually for context processing, limiting, counting, and so on.
  4. Data is then transmitted through a client, such as the Netty client. Some proprietary protocol construction needs to be done before transmission, and the Codec interface is used. Once constructed, the packets are serialized and delivered to the service provider. When the service provider receives the packet, it will also use Codec to process the protocol header and some half-packets, sticky packets, etc. After processing, the complete data message is deserialized.
  5. The Request is then allocated to the thread pool for processing. Server handles these requests and finds its counterpart, which has an Invoker in-house, based on the Request.
  6. Finally get the real implementation of the interface and call, and then return the call result in the original way.

This is a complete remote call.