分布式微服务系统的跨库查询/操作的解决思路(关系型数据库)

标签: 分布 微服务 系统 | 发表时间:2023-01-16 18:34 | 作者:守望时空33
出处:https://juejin.cn/backend

在后端开发过程中,我们绕不开的就是数据结构设计以及关联的问题。

然而在传统的单体架构的开发中,解决数据关联的问题并不难,通过关系型数据库中的关联查询功能,以及MyBatis的级联功能即可实现。

但是在分布式微服务中, 整个系统都被拆分成了一个个单独的模块,每个模块也都是使用的单独的数据库。这种情况下,又如何解决不同模块之间数据关联问题呢?

事实上,分布式微服务是非常复杂的,无论是系统架构,还是数据结构设计,都没有一个统一的方案,因此根据实际情况进行确定即可,对于数据关联的跨库查询,事实上也有很多方法,在网上有如下思路:

  • 数据冗余法
  • 远程连接表
  • 数据复制
  • 使用非关系型数据库
  • ...

今天,我就来分享一个简单的分布式微服务跨库查询操作,大家可以参考一下。

我们还是从 一对多多对多的角度来解决这个问题。

1,学习前需要了解

在继续往下看之前,我想先介绍一下这次的示例中所使用的组件:

  • Spring Cloud 2022.0.0和Spring Cloud Alibaba 2022.0.0.0-RC1
  • MyBatis-Plus作为ORM框架
  • Dynamic Datasource作为多数据源切换组件
  • Nacos作为注册中心
  • MySQL数据库
  • OpenFeign远程调用

因此,在往下看之前,需要先掌握上述这些组件的使用,本文不再赘述。

之前都是使用MyBatis作为ORM框架,而MyBatis-Plus可以视作其升级版,省去了我们写繁杂的Mapper.xml文件的步骤,上手特别简单。

将上述所有前置内容掌握之后,再来往下看最好。

2,跨库操作解决思路

我们从数据的联系形式,即 一对多多对多这两个角度依次进行分析。

(1) 一对多

一对多事实上比较好解决,这里我使用 字段冗余 + 远程调用的方式解决。

这里以**订单( Order) 用户( User)**为例,订单对象中通常要包含用户关系,一个用户会产生多个订单,因此用户和订单构成了一对多的关系。

单体架构中,我们很容易想到设计成这样:

image.png

这样,在查询订单的时候,可以通过关联查询的方式得到用户字段信息。

但是在分布式微服务中,用户和订单模块被拆分开来,两者的数据库也分开了,无法使用关联查询了,怎么办呢?

这时,我们可以在订单类中, 冗余一个 userId字段,可以直接从数据库取出,再通过 远程调用的方式调用用户模块,用这个 userId去得到用户对象, 最后组装即可。

image.png

这样, 订单服务查询订单对象,可以分为如下几步:

  1. 先直接 从数据库取出订单对象,这样上述 Order类中的 idnameuserId都可以直接从数据库取出
  2. 然后拿着这个 userId的值去 远程调用用户服务得到用户对象,填充到 user字段

与此同时,我们还可以注意一下细节:

  • Order对象返回给前端时, 可以过滤掉冗余字段 userId,节省流量,通过 Jackson注解可以实现
  • 前端若要将 Order对象作为参数传递给后端,则 无需带着 user字段内容,这样前端传来后可以直接丢进数据库,并且更加简洁

(2) 多对多

我们知道,多对多通常是以搭桥表方式实现关联。

在此我们增加一个 商品类( Product),和订单类构成多对多关系,即需要查询一个订单中包含的所有商品,还需要查询这个商品被哪些订单包含。

在传统单体架构中,我们如下设计:

image.png

那么在分布式微服务中,数据库分开的情况下, 这个搭桥表 order_product放在哪呢?

可以将其单独放在一个数据库中,这个数据库在这里称之为 搭桥表数据库

image.png

这样,比如说 订单服务查询订单的时候,可以分为如下几步:

  1. 先直接从 订单数据库查询出订单信息,这样 Order类中的 idnameuserId就得到了
  2. 然后从 搭桥表数据库去查询 和这个订单关联的商品 id,这样就得到了一个商品 id列表
  3. 用这个商品 id列表去 远程调用商品服务,查询到每个 id对应的商品对象得到一个 商品对象列表
  4. 将商品列表组装到 Order中的 products字段中

那么反过来,商品服务也是通过一样的方式得到订单列表并组装。

可见,这两个多对多模块,有下列细节:

  • 需要用到两个数据库,因此需要配置 多数据源
  • 两者需要暴露批量 id查询的接口,但是批量 id查询的时候,要注意死循环问题,这个我们在下面代码中具体来看

(3) 总结

可见上述解决数据关联的方式,都是要通过远程调用的方式来实现,这样符合微服务中职责单一原则,不过缺点是网络性能不是很好。

但是,这种方式解决规模不是特别复杂的项目已经足够了。

整体的类图和数据库如下:

image.png

image.png

那么下面,我们就来实现一下。

3,代码实现

(1) 环境配置

在写代码之前,我们先要在本地搭建并运行好MySQL和Nacos注册中心,这里我已经在本地通过Docker的方式部署好了,大家可以先自行部署。

image.png

然后在这里,整个工程模块组织如下:

image.png

  1. 存放全部实体类的模块,是普通Maven项目,被其它模块依赖
  2. 远程调用层,是普通Maven项目,其它服务模块依赖这个模块进行远程调用
  3. 订单服务模块,是Spring Boot项目
  4. 商品服务模块,是Spring Boot项目
  5. 用户服务模块,是Spring Boot项目

我们知道服务提供者和服务消费者在整个分布式微服务中是非常相对的概念,而服务消费者是需要进行远程调用的,这样每个服务消费者都要引入OpenFeign依赖并注入等等,因此我们可以 单独把所有的消费者的远程调用层 feignclient抽离出来,作为这个远程调用模块。

在最后我会给出项目的仓库的地址,大家可以在示例仓库中自行查看每个模块的配置文件和依赖配置。

(2) 数据库的初始化

在MySQL中通过以下命令,创建如下数据库:

  create database `db_order`;
create database `db_product`;
create database `db_user`;
create database `db_bridge`;

上述 db_bridge就是专门存放搭桥表的数据库。

然后依次初始化三个数据库。

db_order数据库:

  -- 订单数据库
drop table if exists `order_info`;

create table `order_info`
(
`id`      int unsigned auto_increment,
`name`    varchar(16)  not null,
`user_id` int unsigned not null,
primary key (`id`)
) engine = InnoDB
  default charset = utf8mb4;

-- 测试数据
insert into `order_info` (`name`, `user_id`)
values ('订单1', 1), -- id:1~4
   ('订单2', 1),
   ('订单3', 2),
   ('订单4', 3);

db_product数据库:

  -- 商品数据库
drop table if exists `product`;

create table `product`
(
`id`   int unsigned auto_increment,
`name` varchar(32) not null,
primary key (`id`)
) engine = InnoDB
  default charset = utf8mb4;

-- 初始化测试数据
insert into `product` (`name`)
values ('商品1'), -- id:1~3
   ('商品2'),
   ('商品3');

db_user数据库:

  -- 用户数据库
drop table if exists `user`;

create table `user`
(
`id`       int unsigned auto_increment,
`username` varchar(16) not null,
primary key (`id`)
) engine = InnoDB
  default charset = utf8mb4;

-- 初始化数据
insert into `user` (`username`)
values ('dev'), -- id:1~3
   ('test'),
   ('admin');

db_bridge数据库:

  -- 多对多关联记录数据库
drop table if exists `order_product`;

-- 订单-商品多对多关联表
create table `order_product`
(
`order_id`   int unsigned,
`product_id` int unsigned,
primary key (`order_id`, `product_id`)
) engine = InnoDB
  default charset = utf8mb4;

-- 初始化测试数据
insert into `order_product`
values (1, 1),
   (1, 2),
   (2, 1),
   (2, 2),
   (3, 2),
   (3, 3),
   (4, 1),
   (4, 2),
   (4, 3);

(3) 实体类的定义

所有的实体类存放在 db-entity模块中。

首先我们还是定义一个结果类 Result<T>专用于返回给前端:

  package com.gitee.swsk33.dbentity.model;

import lombok.Data;

import java.io.Serializable;

/**
 * 返回给前端的结果对象
 */
@Data
public class Result<T> implements Serializable {

/**
 * 是否操作成功
 */
private boolean success;

/**
 * 消息
 */
private String message;

/**
 * 数据
 */
private T data;

/**
 * 设定成功
 *
 * @param message 消息
 */
public void setResultSuccess(String message) {
this.success = true;
this.message = message;
this.data = null;
}

/**
 * 设定成功
 *
 * @param message 消息
 * @param data    数据
 */
public void setResultSuccess(String message, T data) {
this.success = true;
this.message = message;
this.data = data;
}

/**
 * 设定失败
 *
 * @param message 消息
 */
public void setResultFailed(String message) {
this.success = false;
this.message = message;
this.data = null;
}

}

然后就是数据库对象了。

1. 用户类

  package com.gitee.swsk33.dbentity.dataobject;

import com.baomidou.mybatisplus.annotation.IdType;
import com.baomidou.mybatisplus.annotation.TableId;
import lombok.Data;

/**
 * 用户类
 */
@Data
public class User {

/**
 * 用户id
 */
@TableId(type = IdType.AUTO)
private Integer id;

/**
 * 用户名
 */
private String username;

}

2. 商品类

  package com.gitee.swsk33.dbentity.dataobject;

import com.baomidou.mybatisplus.annotation.IdType;
import com.baomidou.mybatisplus.annotation.TableField;
import com.baomidou.mybatisplus.annotation.TableId;
import lombok.Data;

import java.util.List;

/**
 * 商品表
 */
@Data
public class Product {

/**
 * 商品id
 */
@TableId(type = IdType.AUTO)
private Integer id;

/**
 * 商品名
 */
private String name;

/**
 * 所有购买了这个商品的订单(需组装)
 */
@TableField(exist = false)
private List<Order> orders;

}

可见这里用了 @TableField注解将 orders字段标注为非数据库字段,因为这个字段是我们后续要手动组装的多对多字段。

3. 订单类

  package com.gitee.swsk33.dbentity.dataobject;

import com.baomidou.mybatisplus.annotation.IdType;
import com.baomidou.mybatisplus.annotation.TableField;
import com.baomidou.mybatisplus.annotation.TableId;
import com.baomidou.mybatisplus.annotation.TableName;
import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import lombok.Data;

import java.util.List;

/**
 * 订单类
 */
@Data
@JsonIgnoreProperties(allowSetters = true, value = {"userId"})
@TableName("order_info")
public class Order {

/**
 * 订单id
 */
@TableId(type = IdType.AUTO)
private Integer id;

/**
 * 订单名
 */
private String name;

/**
 * 关联用户id(一对多冗余字段,不返回给前端,但是前端作为参数传递)
 */
private Integer userId;

/**
 * 关联用户(需组装)
 */
@TableField(exist = false)
private User user;

/**
 * 这个订单中所包含的商品(需组装)
 */
@TableField(exist = false)
private List<Product> products;

}

可见这里使用了 @JsonIgnoreProperties过滤掉了冗余字段 userId不返回给前端。

(4) 各个服务模块

基本上每个服务模块仍然是Spring Boot的四层架构中的三层, daoserviceapi。因此这里只讲关键性的东西,其余细节可以在文末示例仓库中看代码。

来看订单模块,定义数据库操作层 OrderDAO如下:

  package com.gitee.swsk33.dborder.dao;

import com.baomidou.dynamic.datasource.annotation.DS;
import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import com.gitee.swsk33.dbentity.dataobject.Order;
import org.apache.ibatis.annotations.Delete;
import org.apache.ibatis.annotations.Insert;
import org.apache.ibatis.annotations.Select;

import java.util.List;

public interface OrderDAO extends BaseMapper<Order> {

/**
 * 添加关联记录
 *
 * @param orderId   订单id
 * @param productId 商品id
 * @return 增加记录条数
 */
@Insert("insert into `order_product` values (#{orderId}, #{productId})")
@DS("bridge")
int insertRecord(int orderId, int productId);

/**
 * 根据订单id查询其对应的所有商品id列表
 *
 * @param orderId 订单id
 * @return 商品id列表
 */
@Select("select `product_id` from `order_product` where `order_id` = #{orderId}")
@DS("bridge")
List<Integer> selectProductIds(int orderId);

/**
 * 删除和某个订单关联的商品id记录
 *
 * @param orderId 订单id
 * @return 删除记录数
 */
@Delete("delete from `order_product` where `order_id` = #{orderId}")
@DS("bridge")
int deleteProductIds(int orderId);

}

由于继承了MyBatis-Plus的 BaseMapper,因此基本的增删改查这里不需要写了,所以这里只需要写 对搭桥表数据库中的操作,比如说获取这个订单中包含的商品 id列表等等,也可见 这里只获取 id或者是传入 id为参数对搭桥表进行增删查操作,并且这些方法标注了 @DS切换数据源查询。

再来看 Service层代码:

  package com.gitee.swsk33.dborder.service.impl;

import com.gitee.swsk33.dbentity.dataobject.Order;
import com.gitee.swsk33.dbentity.dataobject.Product;
import com.gitee.swsk33.dbentity.dataobject.User;
import com.gitee.swsk33.dbentity.model.Result;
import com.gitee.swsk33.dbfeign.feignclient.ProductClient;
import com.gitee.swsk33.dbfeign.feignclient.UserClient;
import com.gitee.swsk33.dborder.dao.OrderDAO;
import com.gitee.swsk33.dborder.service.OrderService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class OrderServiceImpl implements OrderService {

@Autowired
private OrderDAO orderDAO;

@Autowired
private UserClient userClient;

@Autowired
private ProductClient productClient;

@Override
public Result<Void> add(Order order) {
Result<Void> result = new Result<>();
// 先直接插入
if (orderDAO.insert(order) < 1) {
result.setResultFailed("插入失败!");
return result;
}
// 插入后,添加与之关联的商品多对多记录
for (Product each : order.getProducts()) {
orderDAO.insertRecord(order.getId(), each.getId());
}
result.setResultSuccess("插入完成!");
return result;
}

@Override
public Result<Void> delete(int id) {
Result<Void> result = new Result<>();
// 先直接删除
if (orderDAO.deleteById(id) < 1) {
result.setResultFailed("删除失败!");
return result;
}
// 然后删除关联部分
orderDAO.deleteProductIds(id);
result.setResultSuccess("删除成功!");
return result;
}

@Override
public Result<Order> getById(int id) {
Result<Order> result = new Result<>();
// 先查询订单
Order getOrder = orderDAO.selectById(id);
if (getOrder == null) {
result.setResultFailed("查询失败!");
return result;
}
// 远程调用用户模块,组装订单中的用户对象字段(一对多关联查询)
User getUser = userClient.getById(getOrder.getUserId()).getData();
if (getUser == null) {
result.setResultFailed("查询失败!");
return result;
}
getOrder.setUser(getUser);
// 远程调用商品模块,组装订单中关联的商品列表(多对多关联查询)
List<Integer> productIds = orderDAO.selectProductIds(id);
getOrder.setProducts(productClient.getByBatchId(productIds).getData());
result.setResultSuccess("查询成功!", getOrder);
return result;
}

@Override
public Result<List<Order>> getByBatchId(List<Integer> ids) {
Result<List<Order>> result = new Result<>();
// 先批量查询
List<Order> getOrders = orderDAO.selectBatchIds(ids);
// 组装其中的用户对象字段
for (Order each : getOrders) {
each.setUser(userClient.getById(each.getUserId()).getData());
}
// 由于批量查询目前专门提供给内部模块作为多对多关联查询时远程调用,因此这里不再对每个对象进行多对多查询,否则会陷入死循环
result.setResultSuccess("查询完成!", getOrders);
return result;
}

}

可以先看代码和注释,这里面已经写好了增删查记录的时候的流程和操作,包括查询多对多搭桥表中的 id以及远程调用等等,远程调用代码这里不再赘述。

然后,将这些服务暴露为接口即可,反过来商品服务模块也是基本一样的思路。

上述有以下需要注意的地方:

  • 将搭桥表的操作,即 增加、查询和删除这个订单包含的商品 id的操作,定义在了 OrderDAO,反过来在商品服务中, ProductDAO中也需要定义增加、查询和删除和这个商品所有关联的订单 id的操作,具体可以看项目源码
  • 在服务中编写了 getByBatchId这个方法专用于模块远程调用查询多对多的对象,但是可见在这个方法中批量查询时,没有继续组装每个对象中包含的多对多对象,防止死循环

对于远程调用,需要注意的是远程调用层的代码和这些服务不在一个模块中,因此在模块主类上标注 @EnableFeignClients注解启用远程调用功能时,还需要指定需要用到的远程调用的 FeignClient类,否则会注入失败:

image.png

所有模块写完后,启动并测试接口,来看一下效果:

image.png

image.png

4,总结

事实上,解决分布式微服务的跨库增删改查操作,有很多的方式,这里只是提供一个思路,大家可以适当采纳,不能说这里的方案就是最优雅、性能最好的,还需要根据实际情况考虑。

相关 [分布 微服务 系统] 推荐:

基于支付系统场景的微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.

分布式微服务系统的跨库查询/操作的解决思路(关系型数据库)

- - 掘金 后端
在后端开发过程中,我们绕不开的就是数据结构设计以及关联的问题. 然而在传统的单体架构的开发中,解决数据关联的问题并不难,通过关系型数据库中的关联查询功能,以及MyBatis的级联功能即可实现. 但是在分布式微服务中, 整个系统都被拆分成了一个个单独的模块,每个模块也都是使用的单独的数据库. 这种情况下,又如何解决不同模块之间数据关联问题呢.

微服务系统中的认证策略

- - 企业架构 - ITeye博客
软件安全本身就是个很复杂的问题,由于微服务系统中的每个服务都要处理安全问题,所以在微服务场景下会更复杂. David Borsos在最近的伦敦微服务大会上作了相关内容的演讲,并评估了四种面向微服务系统的身份验证方案. 在传统的单体架构中,单个服务保存所有的用户数据,可以校验用户,并在认证成功后创建HTTP会话.

微服务架构:如何用十步解耦你的系统?

- - 掘金后端
耦合性,是对模块间关联程度的度量. 耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少. 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系. 模块间联系越多,其耦合性越强,同时表明其独立性越差. 软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.

一个基于Spring Cloud的微服务电商平台系统

- - 程序猿DD
年之计在于春,新年就要有新的打算,TJ君身边不少小伙伴都有点想在新的一年里开个网店的冲动,但是如何入手、如何开店都是个学问,需要好好研究,不过这也说明了电商行业的前景还是不错滴. 所以当TJ君今天留意到这个开源项目的时候,第一反应就是,可用. 说到mall4cloud,不得不先说下Mall4j. Mall4j是一个商用的提供多元化电商服务,满足企业多场景业务需求,为垂直行业提供专业的电商解决方案网站,提供多种成熟的电商配套服务,而mall4cloud则正是它的 开源版本.

微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

微服务实现简单的分布式日志追踪

- - DockOne.io
最近想给项目添加一个简单的分布式请求跟踪功能,从前端发起请求到网关,再从网关调用 Spring Cloud 的微服务,这些过程中希望能从日志中看到一个分布式 ID 的链路,通过请求的 ID 可以追踪整一条链路,方便问题的排查. 现成的方案自然是使用 SkyWalking 、 Spring Cloud Sleuth 、Zipkin 之类的组件,但是想到主要的目的记录一个可以一直贯通各个服务的 ID,方便日志查询,也就不想引入太多复杂的组件,最终决定通过 MDC 在日志中输出追踪的 ID,然后在 Feign 和 RestTemplate 中将请求 ID 在微服务中传递.

消息系统在微服务间通讯的数据一致性

- - 互联网 - ITeye博客
微服务是当下的热门话题,今天来聊下微服务中的一个敏感话题:如何保证微服务的数据一致性. 谈到分布式事务,就避免不了CAP理论. CAP理论是指对于一个分布式计算系统来说,不可能同时满足以下三点: . 一致性(Consistence) (等同于所有节点访问同一份最新的数据副本). 可用性(Availability)(对数据更新具备高可用性).

解析微服务架构(一)单块架构系统以及其面临的挑战

- - 博客园_知识库
  多年来,我们一直在技术的浪潮中乘风破浪,扬帆奋进,寻找更优秀的方法来构建IT系统,也一直在积极的学习并观察先进的公司如何以不同的架构方式构建或者优化其IT系统,来积极应对市场的变化,迅速做出响应,从而为客户提供更多的价值.   微服务架构模式(Microservice Architect Pattern)是近两年在软件架构模式领域里出现的一个新名词.