Dubbo Overview: Core Features, Configuration, Protocols, and Common Troubleshooting

Dubbo is a distributed RPC framework that enables transparent remote method invocation with features like cluster fault tolerance, multi‑protocol support, soft load balancing, address routing, dynamic configuration, and automatic service discovery via a registry.

It allows developers to call remote services as if they were local methods with simple configuration, providing soft load balancing and fault‑tolerance mechanisms that can replace hardware load balancers, and supports automatic registration and discovery of services through registries such as Zookeeper, Multicast, Redis, or Simple.

Communication framework: By default Dubbo uses Netty (with Mina as an alternative) for NIO‑based long connections. Service calls are blocking by default but can be made asynchronous.

Registry options: Zookeeper is the recommended registry; others include Multicast, Redis, and Simple registries. Zookeeper uses a hierarchical node structure to store service metadata.

Serialization options: The default is Hessian, with alternatives like Dubbo’s own serialization, FastJson, and Java’s built‑in serialization. Hessian uses binary HTTP POST requests, placing auxiliary information in HTTP headers and transmitting method calls and parameters as byte streams.

Core configuration tags:

dubbo:service/

dubbo:reference/

dubbo:protocol/

dubbo:registry/

dubbo:application/

dubbo:provider/

dubbo:consumer/

dubbo:method/

The default protocol is the Dubbo protocol, but other supported protocols include RMI, WebService (CXF), HTTP, Hessian, Memcached, and Redis, each with its own use‑case and trade‑offs.

Load‑balancing strategies: Random, RoundRobin, LeastActive, and ConsistentHash are provided, allowing selection based on request distribution and provider health.

Security: Dubbo can use token‑based authentication, black‑white lists, and registry‑managed authorization to prevent unauthorized direct connections.

Common issues and solutions:

When both XML and properties configurations are present, properties are ignored; ensure only one configuration type is used.

Disable the startup dependency check (check="false") to avoid initialization failures during testing.

Set dubbo:registry register="false" to prevent development services from registering globally.

Avoid calling applicationContext.getBean() inside service implementations to prevent Spring initialization deadlocks; alternatively set dubbo:provider delay="-1" to expose services after container startup.

Verify that required JARs are on the classpath and that network connectivity to the registry is functional.

For RpcException "No provider available", check registry address, provider registration, and provider health.

Message‑send failures often stem from non‑serializable method parameters.

Timeout handling: By default Dubbo retries twice on failure; to disable retries and set a custom timeout, configure the provider as follows:

<dubbo:provider delay="-1" timeout="6000" retries="0"/>

Adjusting retries and timeout values should be balanced with overall service quality and load‑balancing considerations.