Understanding Dubbo: Core Design Roles, Architecture, and Service Lifecycle

1. Dubbo's Design Roles

System roles

Provider: service provider exposing services.

Consumer: service consumer invoking remote services.

Registry: service registration and discovery center.

Monitor: monitoring center for call count and time.

Container: service runtime container.

Call relationship

Service container starts, loads, and runs service providers.

Providers register themselves with the registry at startup.

Consumers subscribe to needed services from the registry at startup.

Registry returns provider address list; pushes changes via long connection.

Consumers select a provider using soft load balancing; retry on failure.

Consumers and providers aggregate call count and time, sending stats to monitor each minute.

2. How Dubbo Is Architected

Dubbo's layered architecture includes the following design points:

Service Interface layer (Service) : defines business‑related interfaces and implementations.

Config layer (Config) : external configuration via ServiceConfig and ReferenceConfig, can be instantiated directly or via Spring.

Proxy layer (Proxy) : transparent proxy generating client Stub and server Skeleton, centered on ServiceProxy and ProxyFactory.

Registry layer (Registry) : encapsulates service address registration and discovery, centered on service URL with RegistryFactory, Registry, and RegistryService.

Cluster layer (Cluster) : encapsulates routing and load balancing of multiple providers, bridges the registry, centered on Invoker with Cluster, Directory, Router, and LoadBalance.

Monitor layer (Monitor) : monitors RPC call count and time, centered on Statistics with MonitorFactory, Monitor, and MonitorService.

Protocol layer (Protocol) : encapsulates RPC invocation, centered on Invocation and Result with Protocol, Invoker, and Exporter; manages Invoker lifecycle.

Exchange layer (Exchange) : request‑response model, synchronous to asynchronous, centered on Request and Response with Exchanger, ExchangeChannel, ExchangeClient, and ExchangeServer.

Transport layer (Transport) : abstracts Mina and Netty as unified interfaces, centered on Message with Channel, Transporter, Client, Server, and Codec.

Serialize layer (Serialize) : reusable utilities, centered on Serialization, ObjectInput, ObjectOutput, and ThreadPool.

3. Dubbo's Underlying Implementation

(1) Protocol support Dubbo supports multiple protocols such as Dubbo, Hessian, HTTP, RMI, WebService, Thrift, Memcached, and Redis. Choosing the right protocol depends on service level and quality requirements; for example, RMI may be blocked by firewalls, so HTTP or Hessian is preferred for external communication.

(2) Default Dubbo protocol Uses a single long TCP connection with NIO asynchronous transport and Hessian binary serialization. Suitable for small payloads (<100 KB), many consumers relative to providers, and regular remote method calls; not recommended for large files or video streams.

(3) Dubbo source module diagram

Key modules:

dubbo-common: common logic, utilities, and models.

dubbo-remoting: remote communication, implements Dubbo protocol.

dubbo-rpc: abstracts various protocols and dynamic proxies, handles single calls.

dubbo-cluster: clusters multiple providers, provides load balancing, fault tolerance, routing.

dubbo-registry: abstracts registry interactions and cluster address distribution.

dubbo-monitor: monitors call counts, times, and tracing.

dubbo-config: public API for configuration, hides internal details.

dubbo-container: standalone container that loads Spring, avoiding need for web containers.

4. Detailed Process of Service Exposure and Consumption

(1) Service provider exposing a service

ServiceConfig obtains the implementation reference, ProxyFactory creates an AbstractProxyInvoker, which is then converted to an Exporter. In Dubbo, DubboProtocol.export opens a socket to listen for client requests; in RMI, RmiProtocol.export relies on the JDK implementation.

(2) Service consumer consuming a service

ReferenceConfig.init calls Protocol.refer to obtain an Invoker, which is then converted to the client interface for the service.