Issue Description
Type: discussion
Describe what happened (or what feature you want)
Related to #2943
Sentinel 2.0 将进行流量治理全面升级,其中会带来很多流量治理的新能力,如流量路由、流量染色、权重调整等。这些能力对应的代码与模块结构有不同的安置方式,社区需要进行讨论。
选择一:新流量治理能力置于 sentinel-core
模块中。
考虑的问题:不同的团队分别使用流控与路由能力,同个依赖 不同版本的情况,可能导致冲突;
选择二:新流量治理能力置于新的模块中,比如 sentinel-traffic-core
。
考虑的问题:与 sentinel-core
共用的一些模块的处置问题
3条答案
按热度按时间mxg2im7a1#
选择一解决方案: 在
sentinel-core
中仅引入 新流量治理的接口/SPI定义
, 而后根据实际需要,单独引入对应实现的版本。缺点:
sentinel-core
功能显得混乱,对于整体项目的结构的可读性上会产生歧义。选择二解决方案:将 公用模块单独提取成模块,类似
sentinel-core-base
或sentinel-core-common
等,在不同的core
中单独依赖缺点:
sentinel-traffic-core
形式来进行命名,那么原先的sentinel-core
最好也同样改成sentinel-flowrule-core
之类的,但这样用户从低1.x
升级到2.x
时,需要更改依赖的 pom 坐标5ssjco0h2#
推荐方案二,能力之间无强关联性,可利于单独发展,降低用户升级门槛。
neskvpey3#
推荐方案二,首先流量治理这一块不是sentinel强依赖的模块(理论上应该属于微服务治理方向),属于可选方案,很多公司在流量治理,流量染色,灰度等等都有自己的一套实现方案,可以让把选择权交由客户去选择,实现按资源规则按需集成流量治理模块。