Alanxtl opened a new issue, #3336:
URL: https://github.com/apache/dubbo-go/issues/3336
### 背景
dubbo-go 现在已经有一套自适应限流能力，主要包括：
- provider 侧的 `filter/adaptivesvc`
- consumer 侧的 `cluster/adaptivesvc`
- `p2c` load balance
- consumer 本地 metrics
- Hill Climbing 自适应并发控制算法
这套能力可以在 provider 侧根据实时请求情况动态调整并发上限，同时让 consumer 根据 provider 返回的剩余容量选择更合适的节点。
下一步我们希望对这块能力做一次系统梳理，并考虑把它迁移到 `dubbo-go-extensions`，让 dubbo-go 主仓库更加轻量。
### 要做的事情
1. **检查 dubbo-go 当前自适应限流能力**
需要先梳理当前已有能力，包括：
- provider 侧自适应限流 filter
- method 级别 limiter
- Hill Climbing 算法
- consumer 侧 adaptiveService cluster
- P2C 如何使用 provider 返回的 `remaining` 信息
- 当前配置入口和使用方式
- 已知限制和潜在问题
2. **做压力测试，看看能力上限**
需要补一组压测，验证当前实现的实际效果，比如：
- 高并发下是否能保护 provider
- RTT 升高时是否会自动缩容
- 服务恢复后是否会自动扩容
- 多 provider 场景下 P2C 是否能把流量打到更健康的节点
- reject 行为是否符合预期
- 当前硬编码参数是否存在瓶颈
压测结果需要形成简单报告，说明现有能力上限和发现的问题。
3. **把自适应限流插件迁移到 dubbo-go-extensions**
为了让 dubbo-go 主仓库更轻量，计划将自适应限流相关能力迁移到 `dubbo-go-extensions`。
迁移范围可以包括：
- `filter/adaptivesvc`
- `filter/adaptivesvc/limiter`
- `cluster/cluster/adaptivesvc`
- 相关 tests
- 必要文档
同时需要确认哪些基础能力应该继续留在主仓库，比如 `p2c`、`cluster/metrics`、相关 constants 等。
4. **给自适应限流补 dubbo-go-samples**
在 `dubbo-go-samples` 里增加一个可以直接运行的 sample，展示如何使用自适应限流。
sample 可以包括：
- server 开启 adaptive service
- client 使用 adaptiveService cluster 和 p2c
- 模拟慢请求 / 高并发 / reject 场景
- README 说明启动方式、配置方式和预期效果
5. **如果发现问题或瓶颈，可以继续升级**
如果压测或迁移过程中发现现有能力有明显问题，可以顺手进行升级，比如：
- limiter 参数配置化
- consumer metrics 增加 TTL
- 错误类型优化，避免依赖 error string
- 增加观测指标
- 支持更多 limiter 算法
- 优化多 consumer 场景下的行为
### 预期产出
- 当前自适应限流能力说明
- 压测结果和能力上限结论
- `dubbo-go-extensions` 中的 adaptive service 插件
- `dubbo-go-samples` 中的可运行示例
- 如有必要，提交能力增强 PR
---
## English Version
### Background
dubbo-go already has an adaptive service throttling mechanism, mainly
including:
- provider-side `filter/adaptivesvc`
- consumer-side `cluster/adaptivesvc`
- `p2c` load balance
- local metrics on the consumer side
- Hill Climbing based adaptive concurrency control
This mechanism can dynamically adjust the concurrency limit on the provider
side, and let the consumer choose a better provider based on the remaining
capacity returned by each provider.
As the next step, we would like to review this feature, test its capability,
and consider moving it to `dubbo-go-extensions` to keep the main dubbo-go
repository lighter.
### Tasks
1. **Review the current adaptive throttling capability in dubbo-go**
We need to check what is currently supported, including:
- provider-side adaptive service filter
- method-level limiter
- Hill Climbing algorithm
- consumer-side adaptiveService cluster
- how P2C uses the `remaining` capacity returned by providers
- current configuration and usage
- known limitations and potential issues
2. **Run pressure tests to understand its capability limits**
We need to add pressure tests to verify how the current implementation
behaves, for example:
- whether it can protect the provider under high concurrency
- whether it shrinks the concurrency limit when RTT increases
- whether it expands again after the provider recovers
- whether P2C sends more traffic to healthier providers
- whether reject behavior works as expected
- whether the current hardcoded parameters become bottlenecks
The result should be summarized in a simple report.
3. **Move the adaptive service plugin to dubbo-go-extensions**
To make the main dubbo-go repository lighter, we plan to move the
adaptive service related implementation to `dubbo-go-extensions`.
Possible migration scope:
- `filter/adaptivesvc`
- `filter/adaptivesvc/limiter`
- `cluster/cluster/adaptivesvc`
- related tests
- required documentation
We also need to decide which shared components should stay in the main
repo, such as `p2c`, `cluster/metrics`, constants, etc.
4. **Add dubbo-go-samples for adaptive service**
Add a runnable sample in `dubbo-go-samples` to show how to use adaptive
service throttling.
The sample may include:
- server with adaptive service enabled
- client using adaptiveService cluster and p2c
- simulated slow requests / high concurrency / reject scenarios
- README with startup steps, configuration, and expected behavior
5. **Upgrade the feature if we find issues or bottlenecks**
If we find obvious problems during pressure testing or migration, we can
improve the feature as part of this work, for example:
- make limiter parameters configurable
- add TTL for consumer-side metrics
- improve error types instead of relying on error strings
- add observability metrics
- support more limiter algorithms
- improve behavior in multi-consumer scenarios
### Expected Outputs
- A summary of the current adaptive service capability
- Pressure test results and capability limit analysis
- Adaptive service plugin in `dubbo-go-extensions`
- Runnable adaptive service sample in `dubbo-go-samples`
- Enhancement PRs if needed
--
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]
