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

参考文章:

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,代价就是架构更复杂了,表结构的变化如果没有告知到各个使用到的服务的相关人员,有可能导致各个依赖服务的查询出现问题。在大量需要此表进行各种关联查询的时候,可以考虑使用

     

 

 

 

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐