Some suggestions && questions
- Dominant language
- Java
- Stars
- 23.1k
- Forks
- 8.1k
- PR merge metrics
- No merged PRs in 30d
Description
## 命名问题
无论是类命名,或者是参数命名,都存在晦涩难懂的地方,至少是不问就不知道它代表什么含义。例如
- SphU
- 以及这个帖子提到的:https://github.com/alibaba/Sentinel/issues/107
## 侵入性改良
主页推荐的使用方式,SphU.entry("HelloWorld");一系列代码包住业务方法体,这种做法侵入性太大,一般用户最多接受加注解的方式。建议如下几种做法
- 注解支持加在接口上或者实现类上。加在接口上,主要是为支持一个接口可能有多个实现类,实现Feature Toggle的功能,避免一一在多个实现类上重复工作
- 注解应该可以加在接口或者实现类的方法体上,也可以加在他们的类头部(全局生效)。有些业务接口可能有几十个方法,一一加上去,也是一件痛苦的事情
- 注解甚至可以不加,默认整个微服务下所有接口类都启用了Sentinel规则。如果判断接口类的作用范围,比如对Spring Cloud来说,加了@RestController作为判断依据。
- 上述所有方式,可以通过一个总开关和配置方式来支持,例如@EnableSentinel,不过这种做法可能要和Spring耦合在一起了
## DataSource某些参数不要写死,可以从用户层面传入
- ZookeeperDataSource中的RETRY_TIMES, SLEEP_TIME
- NacosDataSource的DEFAULT_TIMEOUT
## 配置文件
- 从Demo示例来看,每个规则文件对应一个规则,而Sentinel内置应该有三种规则,Authority,Degrade,Flow,如果我的业务服务上全部启动三个规则,我是否要对应配置三个规则文件?
- extension模块的datasource建议更往业务层一些,例如
- 基于服务来配置,比如我可以一个服务对应一个规则集群
- 基于服务集群来配置,比如服务A下面有三个实例,我不希望重复配置三次规则
- 甚至基于集群组来配置,比如一个集群组代表一个完整的业务线,我只需要改动一个规则配置文件,下面所有的微服务的规则批量生效
## 推送模式增加Rest方式
当运行中的服务要改规则,需要依托远程配置中心,但如果用户不愿意上配置中心,那么还有种方式,通过Rest或者Spring Cloud里Endpoint方式改变规则
上述问题,属于一家之言,有些较理想,请选择采纳之。谢谢!
Contributor guide
Research direction
This issue combines naming concerns, annotation-based usage, configurable ZookeeperDataSource and NacosDataSource parameters, rule-file organization, service-level configuration, and REST-based rule updates. Start by reviewing SphU.entry, the linked issue 107, the extension module, the demo configuration, and the named data sources. Done would require splitting these proposals into separately scoped decisions with explicit acceptance criteria.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend, cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100