[DISCUSSION] Module and package structure of nouveau traffic routing | 新流量治理代码与模块结构

[sczyh30]

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 共用的一些模块的处置问题

[jnan806]

选择一解决方案： 在 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 坐标

[pengten]

推荐方案二，能力之间无强关联性，可利于单独发展，降低用户升级门槛。

[liaomengge]

推荐方案二，首先流量治理这一块不是sentinel强依赖的模块（理论上应该属于微服务治理方向），属于可选方案，很多公司在流量治理，流量染色，灰度等等都有自己的一套实现方案，可以让把选择权交由客户去选择，实现按资源规则按需集成流量治理模块。

[bert82503]

支持多个数据源，请问有计划支持多个遥测数据导出器吗？