分布式微服务下的跨库查询解决思路

参考文章：

https://mp.weixin.qq.com/s/_DPunClmcTDJLcC3S9Y4og 微服务架构下，解决数据库跨库查询的一些思路

看了文章后结合自己经验写的心得

由于微服务的流行，每个微服务都有自己的数据库，这样不可避免一个服务需要依赖另一个库的数据，如果需要获取的是单条的数据，直接通过RPC或者http调用其他微服务就够了。不过，更复杂的情况时，可能一个列表分页查询10条，每条又依赖另外一微服务库里面表数据。

文章中自己没有用过的思路

1. 聚合服务 适合放这种3不管的服务，就是这个服务放哪一方都不是很合理的情况下使用；同时，可能多个服务都只需要使用这个聚合服务就满足业务需求，不用关心这个聚合服务底层是具体调用了哪些服务，对使用方透明，也达到了解耦的作用。是一个比较好的思路。
2. 表视图查询，不同库的表创建一个视图，服务A直接查询视图就行了；但是不推荐，耦合比较大；
3. 分库分表中间件，感觉用这个有点大材小用了，增加了学习曲线

以往用过的一般情况的解决思路有

1. 冗余字段，建议冗余5个以下的字段，且字段内容不要是经常会变化的内容。如果字段内容有变动，需要有定时同步机制，否则就会有脏数据。
2. 远程调用，通过RPC如dubbo或者http如springcloud的feign调用，直接查询其他微服务的数据。这种对于一般的场景足够了；对于上面说的需要关联另一个库的表进行分页查询这种情况，可以先把A表分页10条的基础数据加id查询出来，然后如果是根据id关联，那么把10个id传递给服务B，B通过id查询一次把满足条件的10条数据(要附带着A的id)查询回来，然后代码中把2个集合中A的id相同的数据进行整合，最终10条数据就对应上了。这个思路对于不想写关联分页查询的场景都是适用的，缺点就是要查询2次数据，需要额外的代码支持这个功能。
3. 建立多数据源，切换到其他数据源，执行sql查询相关数据；这种耦合度较高，一般用于另一个数据源的库所属的微服务就是本开发团队开发的，团队人员对于数据库B的变更是非常清楚的；同时服务A需要服务B较多的接口功能，为了减少较多的接口功能在服务B开发，直接查服务B的库；或者大家约定，这个库的这些表是常年不会变动的（确定不会变动？）； 如果对服务B的库或者业务完全不熟悉，不用使用这种方式，否则服务B的库表一旦变动，直接就会导致服务调用报错，而且服务B的人员是不知道哪些服务直接查了他们的库表的
4. 建立数据库表数据自动同步机制，在本数据库创建一个一模一样的表B，然后订阅原来表A的binlog，比如用canal，把增删改同步到表B；这种和第3点相比，好处就是直接可以和表B进行各种关联查询了，甚至表A表结构变化也能同步到表B，代价就是架构更复杂了，表结构的变化如果没有告知到各个使用到的服务的相关人员，有可能导致各个依赖服务的查询出现问题。在大量需要此表进行各种关联查询的时候，可以考虑使用