Unveiling Dubbo: Architecture, Startup Flow, and Design Patterns Explained

Overall Architecture

Dubbo integrates with Spring via XML configuration, allowing providers and consumers to be defined like Spring beans. It uses Spring’s extensible schema (DubboNamespaceHandler) to parse ServiceConfig, ReferenceConfig, and other elements.

JDK SPI Extension

Dubbo extends the JDK SPI mechanism by placing files named after interface fully qualified names under META-INF, containing key‑value pairs where the value is the implementation class name. ExtensionLoader reads these files, enabling three extensions: keyed implementation lookup, adaptive (dynamic proxy) implementation, and automatic wrapper implementations such as ProtocolFilterWrapper.

URL Bus Design

All inter‑layer communication parameters are passed via URL objects, e.g., the registry URL registry://0.0.0.0:9090?codec=registry&transporter=netty, which indicates a registry service bound to all IPs on port 9090 using Netty.

Dubbo Startup Process

Registry Center

Two main classes, RegistrySynchronizer and RegistryReceiver, start the registry. RegistrySynchronizer.start() loads configurations, persists registry info, and launches five timers (AutoRedirectTask, DirtyCheckTask, ChangedClearTask, AlivedCheckTask, ChangedCheckTask). RegistryReceiver.start() launches a Netty server on port 9090 and sets up the handler chain:

NettyHandler → NettyServer → MultiMessageHandler → HeartbeatHandler → AllDispatcher → DecodeHandler → HeaderExchangeHandler → RegistryReceiver → RegistryValidator → RegistryFailover → RegistryExecutor

Provider

Provider startup begins with ServiceConfig.export() and follows steps: expose locally (injvm), invoke RegistryProtocol.export, invoke DubboProtocol.export (default port 20880), create a RemoteRegistry, register service address, and subscribe to its own service.

Consumer

Consumer startup uses ReferenceConfig.get(): create a RemoteRegistry, build a RegistryDirectory to subscribe to services, and generate a proxy whose invocations go through InvokerInvocationHandler.

Actual Invocation Flow

When a consumer calls a service, the chain on the consumer side is:

InvokerInvocationHandler → MockClusterInvoker (if mock) → FailoverClusterInvoker → RegistryDirectory$InvokerDelegete → ConsumerContextFilter → FutureFilter → DubboInvoker

On the provider side the handling chain is:

NettyServer → MultiMessageHandler → HeartbeatHandler → AllDispatcher → DecodeHandler → HeaderExchangeHandler → DubboProtocol.requestHandler → EchoFilter → ClassLoaderFilter → GenericFilter → ContextFilter → ExceptionFilter → TimeoutFilter → MonitorFilter → TraceFilter → actual service implementation

Design Patterns Used in Dubbo

Factory Pattern

Dubbo obtains implementations via JDK SPI, e.g.,

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

This allows adding new implementations by placing a file in the classpath without modifying existing code.

Decorator (and Chain of Responsibility) Pattern

Provider invocation chains are built by ProtocolFilterWrapper.buildInvokerChain, stacking filters such as EchoFilter, ClassLoaderFilter, GenericFilter, etc. Some filters act as pure decorators, while others (e.g., EchoFilter) also implement responsibility‑chain behavior.

Observer Pattern

During provider startup, the service registers with the registry and subscribes to updates. The registry periodically checks for changes and notifies listeners via a NotifyListener, embodying the observer pattern.

Dynamic Proxy Pattern

The adaptive extension generated by ExtensionLoader.createAdaptiveExtensionClassCode creates a proxy that decides at runtime which implementation to invoke based on URL parameters.

Source: http://aliapp.blog.51cto.com/8192229/1325655