[Feature] Dubbo Distributed Tester
- 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
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