微服务改造中解决跨库问题的思路

6,034 阅读3分钟


今年一直在和团队做微服务的架构改造(相关的一些详情,有兴趣的朋友,可以参见之前的这篇分享)。但是做过改造的朋友都知道 从“All-In-One” 到 “Micro-Service” 都需要迈过的一个坎,那就是垂直分库, 根据不同的子服务,将数据库拆分为不同的子服务库。

那么问题就来了,在开始做微服务改造前,我发现在摇旺的老系统中,有很多后台报表或者前端详情页所需的数据是通过SQL Join来完成的。但是,我们微服务改造后,每个服务背后的数据库已经在分布不同的实例中了,所以我们已经不能继续简单在SQL中使用join了,那么解决“跨库Join”就摆上了议事日程。


通过讨论和调研,垂直分库后,对于“跨库查询”的解决,可以采用以下几个思路:


1. 依赖字段较少:字段冗余


A库中的Tab1表需要关联B库中的Tab2表中的字段F, 我们就将字段F冗余到表Tab1中,那么查询时候,Tab1和Tab2就不需要做Join,单独查A库中的Tab1表就可以解决问题。

这是一个野路子,因为这是违反正常的范式设计的,但在依赖字段较少的情况下还是可以解决问题的,达到空间来换取时间的目的。不过这个方法最大的短板在于2点: 1. 依赖字段不能太多,2. 数据一致性问题。Tab2中的F字段一但改变,必须要同步到Tab1中,否则就会引起脏数据的问题。所以,需要在业务代码建立必要的同步机制,如果出错,还需要考虑引入人工补偿。


2. 依赖字段较多:表同步


在很多场景下,我们字段的依赖是很多的,乃至查询的时候可能需要跨多张表,这个时候方法1就无法直接用了,我们就需要进行表级别的数据同步,可以采用ETL工具来做到跨库的表同步。不过需要注意的是,数据同步不建议实时性过高,否则数据库的性能会受到比较大的影响。所以对于实时性不高的查询要求,表同步还是比较奏效的。


3. 静态字段依赖:数据字典表


对于不同库中的静态字段,可以建立一张数据字典表,可以将这类表在其他每个数据库中均保存一份,从而避免跨库join查询。如果静态数据表中的某些字段数据需要修改,可以采用一套脚本统一更新。


4. 服务层代码进行数据组装


通过各种服务查询到一个数据集,通过代码进行二次组装,然后生成我们需要返回给前端的对象。在实践过程中,对于处理过的查询集,我们可以将它们缓存在我们的分布式缓存中,减少服务间的RPC调用次数和数据库的查询压力。同时,注意设置好过期时间,把控好数据一致性和有效性。


以上就是4种应对跨库Join的思路,实战中,一定是将这4类方案进行组合使用的,同时,需要注意的是,相比这些解决思路,更重要的是表结构的合理设计。否则要彻底解决跨库是很困难的。


分布式事务的处理方式


除此之外,分库后,还有一个难题,就是分布式事务的处理。具体的事例,可以参见我之前的这两篇文章1文章2。里面会提到在微服务下,服务间事务回滚的几个思路,希望对大家有用。



扫描二维码或手动搜索微信公众号【架构栈】: ForestNotes

欢迎转载,带上以下二维码即可