zzl12222 opened a new issue, #15836:
URL: https://github.com/apache/dubbo/issues/15836

   ### 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_<n>`: Port for each consumer instance (auto-assigned or 
user-specified)
   - `PROVIDER_PORT_<n>`: 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?
   
   - [ ] 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)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to