apache / apache/dubbo

[Feature] Dubbo Distributed Tester

Open
#15,836 1 comment 0 reactions 0 assignees View on GitHub
type/enhancement type/proposal
Dominant language
Java
Stars
41.6k
Forks
26.4k
Avg merge
15h 13m
Merged PRs (30d)
4

Description

### Pre-check

- [x] I am sure that all the content I provide is in English.

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar feature requirement.

### Apache Dubbo Component

Java SDK (apache/dubbo)

### Descriptions

## Pre-check
I am sure that all the content I provide is in English.

## Search before asking
I had searched in the issues and found no similar feature requirement.

## Apache Dubbo Component
Java SDK (apache/dubbo)

## Descriptions

### Background
Apache Dubbo currently lacks standardized benchmark testing capabilities for load balancing algorithms in multi-service scenarios. To address this gap, we propose a dedicated benchmark testing framework for Dubbo load balancing algorithms, which enables systematic testing of different load balancing strategies under configurable multi-consumer and multi-provider environments. This framework will:
- Support comprehensive testing of mainstream Dubbo load balancing algorithms (AdaptiveLoadBalance, ConsistentHashLoadBalance, etc.)
- Enable configurable test modes (fixed count/duration) and service cluster scale (custom number of consumers/providers)
- Provide real-time collection and storage of test metrics (RPC status, system indicators, response time, etc.)

### Overview
This proposal outlines a Dubbo load balancing benchmark testing framework built on **shell scripts + Docker Compose + Netty-based agent architecture**. The framework core consists of an Agent service (central control) + multi-instance Consumer/Provider clusters, with Nacos as the service registry. It supports parsing user-defined test commands, executing load balancing tests, and collecting comprehensive test results to quantify the performance of different load balancing algorithms.

### Features
#### 1. Configuration Options & Test Modes
##### Test Mode Configuration
- `TEST_MODE`: Test execution mode (optional: `FIXED_COUNT`/`DURATION`, default: `FIXED_COUNT`)
- `FIXED_COUNT`: Execute RPC calls for a specified number of times per consumer
- `DURATION`: Execute RPC calls continuously for a specified time period (unit: second)

##### Cluster Scale Configuration
- `CONSUMER_NUM`: Number of consumer instances (customizable, e.g., 2)
- `PROVIDER_NUM`: Number of provider instances (customizable, e.g., 4)
- `CONSUMER_PORT_`: Port for each consumer instance (auto-assigned or user-specified)
- `PROVIDER_PORT_`: Port for each provider instance (auto-assigned or user-specified)

##### Registry Configuration
- `NACOS_HOST`: Nacos server host (default: `localhost`)
- `NACOS_PORT`: Nacos server port (default: `8848`)

##### Load Balancing Algorithm Configuration
- `TEST_LOADBALANCE`: Target load balancing algorithm (supports: `adaptive`/`consistenthash`/`leastactive`/`random`/`roundrobin`/`shortestresponse`)
- **Algorithm-Specific Parameters** (auto-injected based on selected algorithm):
- AdaptiveLoadBalance: Memory usage, system load, weight, timeout
- ConsistentHashLoadBalance: Virtual node count, hash parameter index
- LeastActiveLoadBalance: Active connection count, weight
- RandomLoadBalance: Weight, timestamp
- RoundRobinLoadBalance: Weight, last update time
- ShortestResponseLoadBalance: Response time, active connection count

#### 2. Core Functionality
##### Interactive Test Initialization (Shell Script)
- Guide user to input test mode, cluster scale, Nacos configuration via command line
- Auto-generate Docker Compose files and instance configuration based on user input
- One-click startup of Nacos registry, Agent service, consumer/provider clusters

##### Agent Service (Central Control Core)
- `AgentNettyHandler`: Parse status commands from consumers/providers, dispatch instructions to Instruction Analyzer
- `ResultController`: Collect test results (RPC status, response time, system metrics) and heartbeat information
- `TestManager`: Process user commands, generate test state data, and trigger load balancing test execution

##### Consumer Service
- `ConsumerHandler`: Custom Netty handler for processing consumer-side message communication
- `TestExecutor`: Execute provider RPC calls according to test configuration (load balancing algorithm, test mode)
- `NettyConsumer`: Netty client starter for consumer instance initialization

##### Provider Service
- `NettyProvideService`: Netty server starter for provider instance initialization
- `ProvideHandler`: Netty handler for processing provider-specific status and test requests
- `TestServiceImpl`: Core test method implementation (simulate business logic for RPC response)

##### Data Collection & Storage
- Collect real-time metrics for each load balancing algorithm (system indicators, application indicators, RPC status, sliding window statistics)
- Store test results in persistent volume (`./results`) for post-test analysis

### Implementation Details
#### 1. Environment Initialization
1. Shell script parses user input → generates dynamic Docker Compose template
2. Start Nacos in standalone mode → initialize Agent service (HTTP port 8080, Netty port 8888)
3. Launch consumer/provider instances (number/ports as per user config) with Nacos/Agent dependency

#### 2. Test Execution Flow
1. User inputs test commands via shell script → commands sent to Agent's TestManager
2. Agent parses commands via Instruction Analyzer → distributes test configuration to all consumers
3. Consumers initialize Netty client → register to Nacos and subscribe to provider list (per load balancing algorithm)
4. TestExecutor executes RPC calls (fixed count/duration mode) → providers return responses via TestServiceImpl
5. Agent collects real-time metrics via ResultController (heartbeat, response time, active connections, etc.)
6. State Manager receives registration info (consumer/provider) and updates internal state

#### 3. Load Balancing Algorithm Adaptation
- For each algorithm, inject required parameters (e.g., virtual node count for ConsistentHashLoadBalance)
- Collect algorithm-specific data sources (e.g., sliding window statistics for ShortestResponseLoadBalance)
- Ensure no conflict with Dubbo's native load balancing logic (non-intrusive integration)

### Impact
- New feature addition (benchmark testing framework for load balancing algorithms)
- No breaking changes to existing Dubbo core functionality
- Dependencies: Nacos (service registry), Docker/Docker Compose (environment orchestration), Netty (inter-service communication)
- Requires Dubbo's native load balancing algorithm support (no modification to core algorithm logic)

### Alternatives Considered
- Manual testing without standardized framework (low efficiency, poor reproducibility)
- Using third-party testing tools (JMeter/Gatling) with custom scripts (lack of Dubbo-specific load balancing adaptation)
- Hardcoding test parameters (low flexibility for multi-algorithm/multi-scale testing)

### References
- Dubbo Load Balancing Documentation
- Dubbo Triple Protocol Specification (for reference on service communication)
- Nacos Official Documentation (service registration/discovery)
- Netty User Guide (inter-service communication)

## Related issues
No response

## Are you willing to submit a pull request to fix on your own?
Yes I am willing to submit a pull request on my own!

## Code of Conduct
I agree to follow this project's Code of Conduct

### Related issues

_No response_

### Are you willing to submit a pull request to fix on your own?

- [x] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Contributor guide

Open the contributing guide

Research direction

No repository files or tests are named. Start by locating the existing load-balancing implementations and the proposed AgentNettyHandler, ResultController, TestManager, TestExecutor, and TestServiceImpl entry points; the work is done when configurable multi-consumer/provider benchmarks run through Docker Compose and persist the stated RPC and system metrics.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, docker-compose, java, shell
Domain
backend-api-design, devops, distributed-systems, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.