Sentinel
Sentinel copied to clipboard
alibaba
A powerful flow control component enabling reliability, resilience and monitoring for microservices. (面向云原生微服务的高可用流控防护组件)
### Describe what this PR does / why we need it add gateway cluster flow control ### Does this pull request fix one issue? ### Describe how you did it...
dubbo 使用sentinel，因为不能全局设置，只能一个个接口去新增，使用flowRule.setResource（） 参数可以定义为多个接口吗？如何写
## Issue Description Type: *bug report* or *feature request* ### Describe what happened (or what feature you want) ### Describe what you expected to happen ### How to reproduce it...
自定义了RequestOriginParser类，同一个资源的限流规则始终还是使用的default的规则，自定义的没有生效； 假设 资源 /api/test limitApp :default qps限制 1 第二个同名的：/api/test limitApp :app1 qps限制 10 结果通过origin=app1时，还是受到了 qps=1的限制，说明limitApp生效范围没用， 求解。
## Issue Description Type: *bug report* or *feature request* ### Describe what happened (or what feature you want) [2022-07-09T21:30:28.393Z] "POST /envoy.service.ratelimit.v3.RateLimitService/ShouldRateLimit HTTP/2" 200 - via_upstream - "-" 69 0 1...
1.Sentinel是否支持gateway的集群操作 2.如果支持我需要怎么使用 3.关于Sentinel + gateway + nacos 的持久化操作，在项目初始化时只拉取了数据到内存，但未生效
source的读取是可以自定义json库读取的 但是在sentinel-transport-common中是依赖fastjson的 这里能否替代掉 或者可适配其他json库
fix: //version -> /version ### Describe what this PR does / why we need it ### Does this pull request fix one issue? ### Describe how you did it ###...
## Issue Description 我的用法是这样的，服务A调用服务B（服务C、D、E、F....都可能会调用B），在服务B中用了 `SphU.entry(resourceName,ResourceTypeConstants.COMMON_RPC, EntryType.IN)`，这本身没有问题。但近期给B服务的其他组件也加上了Sentinel，比如调用DB、redis、甚至是调用其他服务的时候（都在B里面）。上线之后内存增长非常快，基本上高峰期10分钟就会一次full gc，young gc的频次也变得频繁了。  Type: *bug report* or *feature request* ### Describe what happened (or what feature you want) 我看了一下，具体的原因，应该是有多个上游的时候，origin数量过多，导致MetricNode数量过多。但感觉里面有一些设计不太合理的地方，比如以下链路，A->B->redis、DB、....等其他资源。按照我的理解，B有多个上游，通过设置origin进行区分，问题不大。但是B去调用其他资源的时候，由于属于A->B的子链路，会导致B->redis、B->DB也会带上origin，但事实上，这些子链路（EntryType.OUT的时候）的origin应该是自己，这个时候去区分origin没有任何意义，反而会增加统计的成本。 ### Describe what you expected...
这个注解功能已经实现，讨论下有没有必要合并进来。 1、被注解保护的资源，可以通过解析orgin方法提取出入参中的某个值作为资源标识。 2、被注解保护的资源，可以通过解析resource name的方法从入参中提取资源名称。 我们的场景： 注解可以灵活的定义资源名称和origin，给使用注解的业务系统提供了很大的灵活性；例如某个service的接口，提供给多个调用方（a/b/c），可以直接通过提取资源名称的方法，把resource绑定到对应的调用方上(serviceApi_a,serviceApi_b,serviceApi_c)，分别对其进行限流规则配置。也可以通过解析orgin方法，统一为一个资源，分别配置不同的origin进行规则配置。 关于origin只在最外层生效和统一拦截器冲突问题： origin仅会在入口处生效，假设web系统有统一的filter处理入口请求并且加上了sentinel限流保护，那么注解中的origin也就不生效了。我是这么想的。 1、对于统一filter，可以制定统一的规范提取某个字段作为origin的标识。 2、让filter可配置开闭让用户选择；解决filter定义的统一origin提取规范对某些业务系统来说改造成本过高问题(比如业务系统有一些历史包袱，识别调用者身份的字段所处的位置千奇百怪) 3、注解支持了origin解析，同时具备了灵活性，未必所有的入口都需要限流保护。
