mybatis-plus中多数据源切换@DS注解到底放在哪一层合适？？？

Question

问题：如果系统配置了多数据源的话，频繁的切换数据源肯定是会对系统性能有很大影响的，尤其是高并发时。比如我们的项目时传统的三层结构：controller、service、mapper,如果用到多数据的话@DS数据源切换注解放在那一层合适呢？

Controller层肯定时不会做数据源切换的，所以只有在service、mapper层来做选择。
假设1：如果放在service层，可能会出现当一个接口请求需要用到两个数据源的数据时，需要分别调用两个server，这样的话可能就需要把业务代码上移到controller层了，在controller层把两个service获取的数据取出来。

然后在controller层做处理，如果是这样的话，显然我们也是不推荐的，一般controller层只做接口的暴露，不会写太多的业务逻辑。所以不建议把数据源写在service层

假设2：如果放在mapper层，我们都知道mybatis-plus都是一张表对应一个mapper的，如果把切换数据源的@DS注解放在这一层，势必会造成频繁的数据源切换操作，因为可能一个接口需要查多张表，但是多张表都在同一个数据源下，这样就会造成不必要的数据源切换，影响性能？

因此，我觉得要是项目使用多数据源的话，还应该在传统的三层结构：controller、service、mapper中再加一层，比如manage层，把切换数据源的@DS注解放在manage层，这样就可以避免场景1出现的问题，同时也可以大大减少场景2出现的问题

大家对此有什么看法，可以说说！！！！

Answer 1

个人思路：

1. 不做数据源切换，直接拆俩项目
2. 不做数据源切换，直接配置好哪些数据库操作使用哪些数据源
3. 想放哪里放哪里，理由充分就行

Answer 2

还是推荐写到service上的，
第一点，难道切换aop加在service上面，service相互调用就不能切换数据源了?（mybatis + 事务的场景暂时不考虑，不管你在哪里加aop，都需要你改造一些源码才能切换数据源）
特别是有事务的情况，你可以控制你的切换数据源的aop是不是早于事务aop（决定了第一次绑定到ThreadLocal中的connection）
第二点就避免了，一张表对应一个mapper 然后是一个service，这就省去了一大堆切换的操作了（都是同一个库的操作，切换没必要）