Mastering Dubbo: Architecture, Features, and Advanced Usage

1. Dubbox Overview

Dubbox extends Dubbo with several improvements, including REST‑style remote calls (HTTP + JSON/XML) via JBoss RestEasy, high‑performance serialization using Kryo and FST, JSON serialization via Jackson, an embedded Tomcat HTTP remoting system, upgraded Spring (3.x) and ZooKeeper clients, pure Java configuration without XML, and various bug fixes.

2. Dubbo Architecture

Dubbo’s runtime architecture consists of three node roles:

1. Provider: service provider exposing services.
2. Consumer: service consumer invoking remote services.
3. Registry: service registration and discovery center.
4. Monitor: monitors service call counts and latency.
5. Container: service runtime container.

The interaction flow is: the provider registers services with the registry; the consumer subscribes to needed services; the registry returns provider addresses and pushes updates via long‑connections; the consumer selects a provider using a soft load‑balancing algorithm; both provider and consumer report call statistics to the monitor.

3. Dubbo Features

Key features include connectivity through a lightweight registry, optional monitoring, high availability via long‑connections, optional direct consumer‑to‑provider connections, health‑aware monitoring, scalability with dynamic registry and provider clusters, and upgradeability for large‑scale deployments.

4. Invocation Types

Asynchronous invocation using NIO non‑blocking parallel calls.

Local (in‑JVM) invocation via the injvm protocol, which bypasses network communication but still executes Dubbo filters.

<dubbo:protocol name="injvm"/>
<dubbo:provider protocol="injvm"/>
<dubbo:service protocol="injvm"/>
<dubbo:consumer injvm="true" .../>

5. Supported Registries

Multicast

Zookeeper

Redis

Simple

Zookeeper provides distributed naming, state synchronization, cluster management, and configuration services, supporting both standalone and clustered modes.

6. Remote Communication Frameworks

Mina

Netty

Grizzly

7. Remote Call Protocols

Dubbo

Hessian

HTTP

RMI

WebService

Thrift

Memcached

Redis

Choosing a protocol depends on factors such as firewall restrictions and performance requirements.

8. Cluster Fault Tolerance and Load Balancing

Fault tolerance strategies:

Failover (default): retry on other servers.

Failfast: single attempt, immediate error.

Failsafe: ignore exceptions.

Failback: record failures and retry later.

Forking: parallel calls, return on first success.

Broadcast: invoke all providers.

Load‑balancing algorithms:

Random

RoundRobin

LeastActive

ConsistentHash

<dubbo:service interface="..." loadbalance="roundrobin"/>

9. Source Code Structure

Dubbo organizes modules by package:

dubbo-common: utilities and common models.

dubbo-remoting: remote communication implementations.

dubbo-rpc: abstract protocol handling and dynamic proxies.

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

dubbo-registry: registry abstractions.

dubbo-monitor: monitoring services.

dubbo-config: public API for configuration.

dubbo-container: standalone container for launching services.

10. SPI Mechanism

Dubbo uses a micro‑kernel + plugin architecture based on Java’s ServiceLoader SPI. Interfaces annotated with @SPI are discovered via META‑INF/services files, allowing multiple vendor implementations to be loaded at runtime.

package com.example;
public interface Spi {
    boolean isSupport(String name);
    String sayHello();
}

Example implementations (SpiAImpl, SpiBImpl) are listed in META‑INF/services/com.example.Spi and loaded with ServiceLoader.load(Spi.class). A factory can select the appropriate implementation based on isSupport.

public class SpiFactory {
    private static ServiceLoader<Spi> spiLoader = ServiceLoader.load(Spi.class);
    public static Spi getSpi(String name) {
        for (Spi spi : spiLoader) {
            if (spi.isSupport(name)) {
                return spi;
            }
        }
        return null;
    }
}

11. SPI Annotation Example

public @interface SPI {
    String value() default ""; // default extension name
}

Only interfaces annotated with @SPI are scanned for extensions in directories such as META‑INF/dubbo/internal, META‑INF/dubbo, and META‑INF/services.