Dubbo Uncovered: Core Architecture, Roles, and Implementation

> Distributed Service Framework Design

(1) RPC Foundation Layer:

Includes low-level communication frameworks such as NIO, communication protocols, serialization and deserialization protocols, and wrappers that hide underlying communication details and serialization differences.

(2) Service Publishing/Consumption:

Service providers use Java reflection to invoke local implementation classes based on interface name, method name, and parameter list from consumer request messages. Service consumers wrap the provider’s interface into remote service calls.

(3) Service Call Chain:

The call chain includes monitoring and extensions such as load balancing, performance statistics, completion notifications, and retry mechanisms, implemented via chain-of-responsibility interceptors.

(4) Service Registry Center:

The registry handles service publishing and notification, supporting smooth online/offline transitions.

(5) Service Governance Center:

A visual module that provides analysis and maintenance of services, including runtime status, call relationships, and health metrics.

> Dubbo’s Design Roles

(1) System Roles

Provider: the service provider that exposes services. Consumer: the service consumer that invokes remote services. Registry: the registry for service registration and discovery. Monitor: the monitoring center that records call counts and durations. Container: the runtime container for services.

(2) Call Relationships

The service container starts, loads, and runs service providers. When a provider starts, it registers its services with the registry. When a consumer starts, it subscribes to required services from the registry. The registry returns a list of provider addresses; if changes occur, it pushes updates via long connections. Consumers select a provider from the address list using a soft load‑balancing algorithm; on failure they retry another provider. Both consumers and providers tally call counts and durations in memory and send statistics to the monitor every minute.

> How Dubbo Is Architected

Overall architecture diagram (omitted)

The layered architecture emphasizes design points for each layer:

Service Interface Layer (Service): Defines business‑related interfaces and implementations.

Configuration Layer (Config): External configuration API centered on ServiceConfig and ReferenceConfig, configurable via code or Spring.

Proxy Layer (Proxy): Transparent proxy generation for client stubs and server skeletons, centered on ServiceProxy with ProxyFactory extensions.

Registry Layer (Registry): Encapsulates service address registration and discovery, centered on service URLs; may operate without a separate registry.

Cluster Layer (Cluster): Handles routing and load balancing of multiple providers, centered on Invoker with extensions Cluster, Directory, Router, LoadBalance.

Monitor Layer (Monitor): Monitors RPC call counts and durations, centered on Statistics with MonitorFactory, Monitor, MonitorService.

Protocol Layer (Protocol): Core RPC invocation model centered on Invocation and Result, with Protocol, Invoker, Exporter interfaces; manages Invoker lifecycle.

Exchange Layer (Exchange): Wraps request/response patterns, supporting sync‑to‑async conversion, centered on Request and Response with Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer.

Transport Layer (Transport): Abstracts underlying transports (e.g., Mina, Netty) centered on Message with Channel, Transporter, Client, Server, Codec.

Serialization Layer (Serialize): Provides reusable serialization utilities, centered on Serialization, ObjectInput, ObjectOutput, ThreadPool.

> Dubbo’s Underlying Implementation

(1) Protocol Support

Dubbo supports multiple protocols, including Dubbo, Hessian, HTTP, RMI, WebService, Thrift, Memcached, and Redis. Choosing the appropriate protocol depends on service level requirements and network constraints; for example, RMI may be blocked by firewalls, so HTTP or Hessian are preferred for external communication.

(2) Default Dubbo Protocol

Connection count: single. Connection type: long‑lived. Transport protocol: TCP. Transport mode: NIO asynchronous. Serialization: Hessian binary. Suitable for small payloads (<100 KB), many consumers per provider, and scenarios where a single consumer cannot saturate a provider. Not recommended for large files or strings unless request volume is low.

(3) Dubbo Source Modules

Dubbo organizes its codebase into packages:

dubbo-common: common utilities and models.

dubbo-remoting: remote communication implementation (e.g., Dubbo protocol).

dubbo-rpc: abstract RPC protocols and dynamic proxies.

dubbo-cluster: clustering, load balancing, fault tolerance, routing.

dubbo-registry: registry abstraction and address distribution.

dubbo-monitor: monitoring of call counts, durations, and tracing.

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

dubbo-container: standalone container for launching services without a web container.

> Detailed Service Exposure and Consumption Process

(1) Provider Service Exposure

The main exposure flow:

ServiceConfig obtains the implementation reference (e.g., HelloWorldImpl) and uses ProxyFactory.getInvoker to create an AbstractProxyInvoker, converting the service to an Invoker. The Invoker is then transformed into an Exporter, which opens a socket listener and handles client requests. Dubbo’s export logic resides in DubboProtocol.export; RMI’s logic resides in RmiProtocol.export, leveraging JDK RMI.

(2) Consumer Service Consumption

The main consumption flow:

ReferenceConfig.init calls Protocol.refer to obtain an Invoker (the key step). The Invoker is then converted to the client‑side interface (e.g., HelloWorld).