[FEATURE] Migrate and Enhance Adaptive Service Throttling in dubbo-go 迁移并增强 dubbo-go 自适应限流能力

[Alanxtl]

背景

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

[nagisa-kunhah]

Hello, I'm interested in this issue. Could you assign it to me?

[Alanxtl]

Hello, I'm interested in this issue. Could you assign it to me?

sure @nagisa-kunhah , thank you for your interest

dubbo-go-extensions is the extension repository for the dubbo-go ecosystem. It is mainly used to host useful but non-core features, so the main dubbo-go repository can stay lighter and more focused. It is still under construction.

For this issue, the idea is to move the current adaptive service throttling implementation out of the main dubbo-go repo and turn it into an independent extension plugin. Users who need this feature can import it from dubbo-go-extensions, while users who do not need it won’t carry extra complexity in the core framework.

For the usage of dubbo-go-extensions u can refer to https://github.com/apache/dubbo-go-samples/tree/main/filter/hystrix

In short:

• dubbo-go: core framework
• dubbo-go-extensions: optional extension components
• This issue: migrate adaptive service throttling into an extension and keep improving it there.