cdfive

以前老版本的dubbo-admin，在服务治理菜单，有服务、应用、机器、提供者、消费者等菜单，方便直观看到有哪些应用、机器、提供者、消费者。 新版本的服务治理菜单里没有这些，它同级上面只有1个服务查询菜单。 比如想看系统里一共有多少个dubbo应用，分别是哪些应用，每个应用下有哪些服务是提供者、消费者，这是一个很基础的需求，请问有什么方法吗？ 通过应用、服务来搜索，或者按提供者、调用者、机器IP等维度来查询，也是一个很常用的需求。 希望能像老版本dubbo-admin那样方便实用

> 如果一个服务里面没有配置provider都是consumer，那么dobbo-admin是无法查询到该服务信息的。 这种情况下，除了服务无法查询到，搜索框右边按应用也查不到应用信息，其实是有1个Dubbo应用注册到注册中心了的。 在实际项目中，某个服务仅作为消费方（比如网关或者提供RestAPI的接入层），它本身不作为Dubbo服务提供者，只是调用不同Dubbo服务提供的方法，这个场景是比较常见的。

组织：文轩在线 地点：中国成都 联系方式：[email protected] 场景：dubbo服务、网关应用流控和熔断需求，服务稳定性保障

> 服务A调用服务B（服务C、D、E、F....都可能会调用B 是Dubbo服务用的sentinel-dubbo-adapter吗 > 2.当resource规则没有配置时，是否可以不记录MetricNode 这个社区有同学提到过，可参考 #2169

> 具体的原因，应该是有多个上游的时候，origin数量过多，导致MetricNode数量过多。但感觉里面有一些设计不太合理的地方，比如以下链路，A->B->redis、DB、....等其他资源。按照我的理解，B有多个上游，通过设置origin进行区分，问题不大。但是B去调用其他资源的时候，由于属于A->B的子链路，会导致B->redis、B->DB也会带上origin，但事实上，这些子链路（EntryType.OUT的时候）的origin应该是自己，这个时候去区分origin没有任何意义，反而会增加统计的成本。 origin是通过`ContextUtil.enter(resourceName, origin);`设置的，在`ClusterBuilderSlot`里创建了新的origin的Node。 可参考sentinel-dubbo-adapter中的`SentinelDubboProviderFilter`和`SentinelDubboConsumerFilter`， 注意只在Provider端调用了`ContextUtil.enter`，Consumer端没有； 如：A->B->redis，这个链路，B作为provider端，调用了`ContextUtil.enter(resourceName, origin);`，其中origin是通过A传过来的，即origin是A；接着B作为consumer端调redis的时候，也就是OUT的场景，在`SentinelDubboConsumerFilter`里并没有调`ContextUtil.enter`产生新的origin，即复用当前的context，origin还是A。 你是不是在B->redis的时候也调用了`ContextUtil.enter(resourceName, origin);`？所以产生了新的origin。 目前公司项目我们部门所有微服务都接入了sentinel，也存在一个服务被多个服务调用的情况，没有出现内存增长特别快或者gc频繁的情况。

> 比如有10个origin，按照我的理解就会有20*(10+1) = 220 我理解是1个origin仅会创建1个`StatisticNode`，entry个数只跟资源名有关，这个理解对吗？请@sczyh30 帮忙看看

> XxxRuleManager is used for managing rules (update / get rules), not for rule checking Maybe it's better to move all checkXxx methods to each slot. Oh, I see. Previously...

> Could you please resolve conflicts? Conflicts has been resolved. A demo for `sentinel-datasource-redis` module is added, which is used for demonstrate and test using `RedisDataSource` and persistent rules in...

> 加入了 -Dcsp.sentinel.app.type=1 ，成为一个网关的服务 > 抛出异常：CommandNotFoundException: /gateway/getApiDefinitions 记得没有修改网关规则处理，理论上不影响使用，只是规则是存在内存里的。 这个异常提示是缺少相关command的处理包，看看应用端是否有加sentinel-gateway-adapter相关的依赖，比如使用SpringCloudGateway的`sentinel-spring-cloud-gateway-adapter`, Zuul1的`sentinel-zuul-adapter`, Zuul2的`sentinel-zuul2-adapter`。网关command的处理是在它们的父依赖包`sentinel-api-gateway-adapter-common`下。 网关规则的持久化暂时还没实现，因为跟其它规则有些不同，有API分组和网关流控规则，还不太确定之前的抽象能否满足，还有集群流控规则也还没实现，社区看看一起讨论设计下哈，如果项目中有使用问题请多反馈和讨论。

@sczyh30 Sorry for late. Merged from master and the conflicts have been resolved, please check.