开局先总结一下:现在很多厂都进行了微服务的开发模式,但是呢,业务的拆分的时候如果存在交叉是一件非常头大的事情,所以大家写微服务尽量不要交叉的写,比如新增用户如果已经存在在userservice里面了那么就不要再出现再authservice里面。OK,然后还有一个问题,就是本文的问题,微服务一旦拆分以后,那么相应的数据库一般也会进行拆分,防止存在交叉的情况,但是有时候有些需求又避免不了交叉的关联查询那么这个时候怎么办呢?这就是本文探讨的方案,我这篇文章也是抄袭的,不过看起来感觉都不大权威,唯一可行性大一点的就是聚合封装查询,重新起一个微服务。其他的感觉或多或少都存在问题。当然我自己也想到了一种解决方案,那就是聚合,通过类似maxwell之类的工具把所有的表聚合到一起,不过这又与微服务拆分有点矛盾了,所以有时候方案没有完美的,只能是不断尝试。
前言
在服务做微服务改造后,原先单库join查询已经不能满足要求,每个拆分的微服务对应一个数据库实例,而且部署在不同的服务器上,那么解决“跨库查询”就势在必行了。
以笔者实战经历来看,以下几个思路仅供参考:
表字段冗余
想必大家已经很熟悉,几乎每天都会打交道,不用多讲。
需要指出的是冗余字段不能太多,建议控制在2-4个左右。否则会出现数据更新不一致问题,一旦冗余字段有改动,极容易产生脏数据。
解决思路
建立同步机制,必要时采取人工补偿措施。
所以,合理的字段冗余是润滑剂,减少join关联查询,让数据库执行性能更高更快。
二、聚合服务封装查询
聚合服务
简单来说,就是把不同服务的数据统一组装在一个新的服务里做聚合,对外提供统一入口API接口查询。
笔者曾经开发新闻报表查询接口时,需要用到用户,新闻、用户标签、登录记录等数据。但是用户、新闻、登录记录在不同的数据库,而且还不在同一台服务器上。经笔者分析,把代码写在用户微服务或者新闻微服务都不合适,最后只能自己单独写了一个聚合服务来解决跨查询数据问题。
聚合服务的数据组装是以API接口调用来实现,一般不建议直连数据库连表查询。这样做的好处是减少服务间调用次数以及查询库表压力。
在实际的业务开发中,我们经常碰到类似的需求,而聚合服务不失为一种较彻底的服务解耦实现方式。
三、表视图查询
如果涉及到不同数据库表之间的join查询,可以在其中某一数据库的表上建立视图(view)关系,这种方式非常高效,只需要开发一个简单接口对外提供服务就可以了,而且省去聚合服务带来调用、查询、聚合的复杂性。
前提条件
数据库需要部署在同一台服务器上
数据库账户密码必须相同,也就是在同一个schema下
另外表视图查询这种方式,是一种紧耦合的设计方式,不利于程序扩展,除非你很确定将来业务变动不大,可以考虑使用。以笔者经验来看,不适合大规模使用。
四、多数据源查询
这种方式是一种比较技术化的思路,简单来说就是一个微服务配置多个数据库源(DataSource),进行数据源来回切换进行库表查询,以达到获取不同数据的目的。
实现思路
利用DynamicDataSource
利用Spring的AOP动态切换数据源
利用Spring的依赖注入方式管理Bean数据源对象
具体实现方式,网上例子很多很成熟的实现方案。
五、分库分表:使用数据库中间件
Sharding-Shpere
想必做过分库分表的同学对他一定不陌生,其出身来至当当开源项目sharding-jdbc。非常有限的跨库查询解决方案,目前在京东内部已经广泛使用。sharding-jdbc创始人张亮已加入京东,sharding-jdbc还在不停的迭代,目前更名为sharding-shpere,已经入Apache顶级项目,进行孵化,非常看好它
高可用架构图
官网传送门
https://shardingsphere.apache.org/document/current/cn/quick-start/
Mycat
一个彻底开源的,面向企业应用开发的大数据库集群,支持事务、ACID、可以替代MySQL的加强版数据库;一个可以视为MySQL集群的企业级数据库,用来替代昂贵的Oracle集群;一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server;结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品;一个新颖的数据库中间件产品。
高可用架构图
Mycat关键特性
遵守Mysql原生协议,跨语言,跨平台,跨数据库的通用中间件代理。
支持单库内部任意join,支持跨库2表join,甚至基于caltlet的多表join。
支持通过全局表,ER关系的分片策略,实现了高效的多表join查询。
从mycat特性来说,其天生就支持分库分表以及跨库查询,具体不多说,有兴趣的同学,可以去官网了解mycat的原理。
-----------------------------------
微服务架构下,解决数据库跨库查询的一些思路
https://blog.51cto.com/u_10180481/2998223