[DISCUSS] Make flow control and circuit break separately in dubbo
- Dominant language
- Java
- Stars
- 23.1k
- Forks
- 8.1k
- PR merge metrics
- No merged PRs in 30d
Description
## Issue Description
In Sentinel, the resource is the base unit for both flow control and circuit break. It's fine in most cases. But let's image one situation in dubbo, as for one service, we have one consumer and 5 providers. One provider has IP strategy error and can not connect to down side service, which makes it always throw exceptions. Our degrade rule set the exception rate is 0.4. In such scene, the degrade can not be triggered because the exception rate keeps 0.2 and the client invoke the dubbo service will get one exception per 5 calls (in round robin load balance). we can make the rate lower to 0.1 to trigger the degrade and circuit break, but this is kind of waste because we have 4 health service out of 5.
### Describe what happened (or what feature you want)
I want to separate the statistic for flow control and circuit break. It is good idea to make statistic based on resource for flow control, on the other hand we should make circuit break decision on the statistic of one provider.
The things we should do is as follows:
1. separate the statistic for flow control and circuit break
2. if one provider trigger break, this should respond to the provider list in the client dubbo cache and make the exception provider 'unreachable'
3. when the break window time elapsed, the provider status in client dubbo cache should be converted to 'half open' or 'ready'
### Describe what you expected to happen
### How to reproduce it (as minimally and precisely as possible)
1.
2.
3.
### Tell us your environment
### Anything else we need to know?
Contributor guide
Research direction
No files, tests, or entry points are named. Start by tracing Sentinel's resource statistics and the Dubbo client provider list/cache, then clarify how flow-control and circuit-breaker statistics should differ. Done means a provider-specific break updates the client provider status and the status can return to half-open or ready after the break window.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100