Introduction and Quick‑Start Guide to the Dubbo Distributed Service Framework

Dubbo Overview

Dubbo is Alibaba's core SOA service governance framework, providing high‑performance transparent RPC and service governance, supporting billions of calls daily for thousands of services.

What is Dubbo?

Dubbo is a distributed service framework offering high‑performance RPC and SOA governance. It is only needed when a system requires distributed service calls.

Core components include:

1. Remote communication: abstraction over NIO frameworks, thread models, serialization, request‑response exchange. 2. Cluster fault‑tolerance: interface‑based remote calls, multi‑protocol support, soft load‑balancing, failure handling, routing, dynamic configuration. 3. Automatic discovery: registry‑based service lookup, dynamic addition/removal of providers.

What can Dubbo do?

1. Transparent remote method invocation like local calls, simple configuration, no API intrusion. 2. Soft load‑balancing and fault‑tolerance, replace hardware load balancers. 3. Automatic service registration and discovery, dynamic provider address lookup.

Dubbo Architecture

Node role description

Node

Role Description

Provider

Service provider that exposes services

Consumer

Service consumer that calls remote services

Registry

Service registration and discovery center

Monitor

Monitors call count and latency

Container

Service runtime container

Dubbo provides three key functions: interface‑based remote call, fault‑tolerance & load‑balancing, and automatic service registration & discovery.

Call relationship description

1. Service container starts, loads, runs providers. 2. Provider registers itself to registry at startup. 3. Consumer subscribes to needed services at startup. 4. Registry returns provider address list, pushes changes via long connection. 5. Consumer selects provider via soft load‑balancing; retries on failure. 6. Consumer and provider aggregate call count and time, send stats to monitor each minute.

Dubbo Features

Dubbo architecture features connectivity, robustness, scalability, and upgradeability.

Connectivity

Registry handles service address registration and lookup; providers and consumers only interact with the registry at startup; registry does not forward requests, keeping pressure low.

Monitor aggregates call counts and latency, reports every minute.

Provider registers services and reports call time (excluding network overhead).

Consumer obtains provider list from registry, calls directly with load‑balancing, reports call time (including network overhead).

All three nodes maintain long connections; monitor is an exception.

Registry detects provider failure and pushes events to consumers immediately.

If registry and monitor both fail, running providers and consumers continue using cached provider lists.

Registry and monitor are optional; consumers can connect directly to providers.

Robustness

Monitor failure does not affect usage, only loses some sampling data.

If database fails, registry can still serve cached service lists but cannot register new services.

Registry forms a peer cluster; any node failure triggers automatic switch.

If all registry nodes fail, providers and consumers continue communication via local cache.

Providers are stateless; any single node failure does not affect usage.

If all providers fail, consumers cannot operate and will keep reconnecting until providers recover.

Scalability

Registry is a peer cluster; new instances can be added dynamically and clients discover them automatically.

Providers are stateless; new instances can be added dynamically, and registry pushes new provider info to consumers.

Upgradeability

When service cluster size grows, the architecture supports dynamic deployment and fluid computing without resistance. The diagram below shows a possible future architecture.

Node role description

Node

Role Description

Deployer

Local agent that automatically deploys services

Repository

Repository for storing service application packages

Scheduler

Scheduler adjusts provider count based on traffic pressure

Admin

Unified management console

Registry

Service registration and discovery center

Monitor

Monitors call count and latency

Quick Start

Dubbo uses full Spring configuration, transparent integration, no API intrusion; just load Dubbo configuration via Spring.

Environment Installation

Choose one:

CentOS 7.3 with ZooKeeper‑3.4.9 single node CentOS 7.3 with ZooKeeper‑3.4.9 cluster

GitHub Code

Code is on GitHub, import the spring-boot-dubbo project.

github https://github.com/souyunku/spring-boot-examples/tree/master/spring-boot-dubbo

Maven Dependency

Add Dubbo dependency:

<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>dubbo</artifactId>
  <version>2.5.6</version>
</dependency>

Define Service Interface

Project:

dubbo-api

public interface DemoService {
    String sayHello(String name);
}

Service Provider

Project: dubbo-provider, implement the interface.

@Service("demoService")
public class DemoServiceImpl implements DemoService {
    @Override
    public String sayHello(String name) {
        System.out.println("[" + new SimpleDateFormat("HH:mm:ss").format(new Date()) + "] Hello " + name + ", request from consumer: " + RpcContext.getContext().getRemoteAddress());
        return "Hello " + name + ", response from provider: " + RpcContext.getContext().getLocalAddress();
    }
}

Load Dubbo configuration:

@Configuration
@PropertySource("classpath:dubbo.properties")
@ImportResource("classpath:dubbo/*.xml")
public class PropertiesConfig {}

Add service exposure in XML:

<dubbo:service interface="io.ymq.dubbo.api.DemoService" ref="demoService"/>

Service Consumer

Project: dubbo-consumer, consume remote method.

@Service("consumerDemoService")
public class ConsumerDemoService {
    @Autowired
    private DemoService demoService;

    public void sayHello(String name) {
        String hello = demoService.sayHello(name);
        System.out.println(hello);
    }
}

Load Dubbo configuration (same as provider).

Add reference in XML:

<dubbo:reference id="demoService" check="false" interface="io.ymq.dubbo.api.DemoService"/>

Remote Service Dubbo Configuration

Both provider and consumer use the same dubbo.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
         http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
         http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd
         http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
    <!-- Application info -->
    <dubbo:application name="${spring.application.name}"/>
    <!-- Registry -->
    <dubbo:registry protocol="zookeeper" address="${zookeeper.connect}" file="${dubbo.cache}"/>
    <!-- Protocol -->
    <dubbo:protocol name="dubbo" port="${dubbo.protocol.port}" threadpool="${dubbo.protocol.threadpool}" threads="${dubbo.protocol.threads}"/>
    <!-- Provider defaults -->
    <dubbo:provider connections="${dubbo.provider.connections}" timeout="${dubbo.provider.timeout}" retries="${dubbo.provider.retries}" version="${dubbo.provider.version}"/>
    <!-- Consumer defaults -->
    <dubbo:consumer version="${dubbo.provider.version}"/>
    <!-- Monitor -->
    <dubbo:monitor protocol="registry"/>
</beans>

Dubbo properties file (example):

#########################################################
# dubbo config
# expose service port
 dubbo.protocol.port=20880
# provider timeout (ms)
 dubbo.provider.timeout=10000
# provider version
 dubbo.provider.version=1.0
# connections (5 long connections)
 dubbo.provider.connections=5
# thread pool (fixed)
 dubbo.protocol.threadpool=fixed
# number of threads
 dubbo.protocol.threads=500
# retries (default 0)
 dubbo.provider.retries=0
# dubbo cache file
 dubbo.cache=/data/dubbo/cache/dubbo-provider
# zookeeper config
 zookeeper.connect=127.0.0.1:2181

Test Dubbo

The interface must be packaged separately and shared by provider and consumer.

The consumer hides the implementation.

IoC injection can also be used.

Start ZooKeeper

/opt/zookeeper-3.4.9/bin/zkServer.sh start

Start Provider Service

package io.ymq.dubbo.provider.run;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.ComponentScan;

/**
 * Description: start provider service
 */
@SpringBootApplication
@ComponentScan(value = {"io.ymq.dubbo"})
public class Startup {
    public static void main(String[] args) {
        SpringApplication.run(Startup.class, args);
    }
}

Test Consumer Remote Service

package io.ymq.dubbo.test;
import io.ymq.dubbo.consumer.service.ConsumerDemoService;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@SpringBootTest(classes = Startup.class)
public class ConsumerTest {
    @Autowired
    private ConsumerDemoService consumerDemoService;

    @Test
    public void sayHello() {
        consumerDemoService.sayHello("Peng Lei");
    }
}

Response example:

[15:54:00] Hello Peng Lei, request from consumer:/10.4.82.6:63993

Code is on GitHub: spring-boot-dubbo project.

github https://github.com/souyunku/spring-boot-examples/tree/master/spring-boot-dubbo

Contact

Author: Peng Lei

Source: http://www.ymq.io

Email: [email protected]

GitHub: https://github.com/souyunku

Segment Fault: http://sf.gg/blog/souyunku

All rights reserved, please credit the author when reproducing.

WeChat: follow the public account “搜云库”.