How Dubbo’s Provider‑Consumer Architecture Powers Scalable RPC Calls

1. Architecture Diagram Overview

1. Architecture Diagram

2. Roles

Provider: Service provider that exposes services.

Consumer: Service consumer that calls remote services.

Registry: Service registry and discovery center.

Monitor: Monitoring center that records call count and latency.

Container: Service runtime container.

3. Call Flow

0 The service container starts, loads, and runs the service provider.

1 Upon startup, the provider registers its services with the registry.

2 Upon startup, the consumer subscribes to required services from the registry.

3 The registry returns a list of provider addresses; if changes occur, it pushes updates via long‑living connections.

4 The consumer selects a provider based on a soft load‑balancing algorithm; if the call fails, it retries another provider.

5 Both consumer and provider aggregate call count and latency in memory and send statistics to the monitor every minute.

2. Key Analysis

What may be most confusing is the distinction between producer and consumer. The service provider is the producer, and the service consumer is the consumer. When others need to call our service (method), we write it in the Provider; when we need to call other services, we use a Consumer.

1. Detailed Process of Service Provider Exposing a Service

Conversion from Service to Invoker First, ServiceConfig obtains the actual implementation class (e.g., HelloWorldImpl) and uses ProxyFactory’s getInvoker method to create an AbstractProxyInvoker instance. Invoker to Exporter Conversion Dubbo implementation: In DubboProtocol’s export method, the Invoker is turned into an Exporter, which opens a socket to listen for requests and handles communication internally. RMI implementation: In RmiProtocol’s export method, the Invoker is turned into an Exporter using Spring, Dubbo, or JDK to implement RMI; the underlying JDK handles communication, reducing work.

2. Detailed Process of Service Consumer Consuming a Service

The init method of ReferenceConfig calls Protocol’s refer method to generate an Invoker instance (highlighted in red in the diagram), which is the key step for service consumption. The Invoker is then converted into the client‑side interface (e.g., HelloWorld).

3. In‑Depth Explanation of Invoker

Invoker is a crucial concept in Dubbo’s domain model; many design ideas revolve around it, making it pervasive throughout the code and potentially confusing for newcomers. The specific service class is wrapped into an AbstractProxyInvoker instance, and a new Exporter instance is created. When the consumer invokes the service, user code calls the corresponding Invoker (DubboInvoker, HessianRpcInvoker, InjvmInvoker, RmiInvoker, WebServiceInvoker, etc.). The Invoker communicates via the network layer to locate the matching Exporter, which then calls the associated AbstractProxyInvoker, ultimately invoking the provider’s code for remote service execution.

Summary

Through this study we understand Dubbo’s architecture, how services are provided and consumed, but the purpose of registration remains unclear; upcoming sections will explain Zookeeper’s role.