Dubbo Architecture Overview

Dubbo is an open-source RPC framework. Its core roles are Provider, Consumer, Registry, and Monitor. Providers expose services and register with the Registry; Consumers discover providers and make calls. This article explains the architecture, protocols, service discovery, and load balancing with examples and a component table.

Overview

• Provider: Exposes service implementations, registers addresses with the Registry, and handles RPC calls from Consumers.
• Consumer: References remote services, gets provider lists from the Registry, selects one via load balancing, and issues calls.
• Registry: Service registration and discovery (Nacos, Zookeeper, Redis, etc.). Maintains service name → list of addresses.
• Monitor (optional): Tracks call count, latency, failure rate, etc. for monitoring and governance.
• Protocol: Transport (dubbo, rest, http, etc.). The dubbo protocol uses TCP long connections and binary serialization for performance.

Example

Example 1: Basic configuration

XMLCopy
<!-- Provider -->
<dubbo:service interface="com.example.UserService" ref="userServiceImpl"/>
<dubbo:protocol name="dubbo" port="20880"/>
<dubbo:registry address="nacos://127.0.0.1:8848"/>

<!-- Consumer -->
<dubbo:reference id="userService" interface="com.example.UserService"/>

• Provider exposes on port 20880 and registers with Nacos. Consumer discovers and calls through Nacos.

Example 2: Call flow

Plain textCopy
Consumer calls userService.getUser(1)
  → Get UserService provider list from Registry
  → Load balance selects one (e.g. 192.168.1.1:20880)
  → Serialize request, send via dubbo protocol
  → Provider deserializes, routes to implementation, executes, returns
  → Consumer deserializes, returns result to caller

Example 3: Version and group

XMLCopy
<dubbo:service interface="UserService" version="1.0" group="prod"/>
<dubbo:reference interface="UserService" version="1.0" group="prod"/>

• Version and group support multi-version deployment and isolation (e.g. canary, A/B).

Example 4: Core components

Component	Role
Registry	Service registration and discovery
Protocol	Transport and serialization (dubbo/rest/http)
Cluster	Load balancing, failover/failfast/failsafe
Filter	Call chain filters (logging, trace, auth)
ConfigCenter	Dynamic config (timeout, retry, routing rules)

Core Mechanism / Behavior

• Dubbo protocol: TCP, binary (Hessian2 by default), long connections. One connection per consumer-provider pair; multiplexed for concurrent calls.
• Registry: Providers register on startup and renew heartbeat. Consumers subscribe and receive updates when providers change. Registry outage can be mitigated with local cache.
• Cluster: Wraps multiple providers. Handles load balancing, failover (retry on failure), failfast (fail immediately), and similar policies.

Key Rules

• Registry should be highly available (multiple nodes, health checks). ConfigCenter can override local config for dynamic tuning.
• Align timeout, retry, circuit breaker with idempotency. Use version and group for canary and isolation.
• Integrate monitoring and tracing for call chain and performance analysis.

What's Next

See RPC Fundamentals, Load Balancing, Timeout/Retry, Service Versioning. See Serialization for protocol and serialization choices.