Spring Boot微服务：跨应用关联同一数据库用户表外键方案

我想把message表的user_id字段设为_user表uid字段的外键，方便消息的存储与检索。但当前采用Spring Boot微服务架构，运行两个独立的Spring Boot应用：一个负责用户认证，另一个负责消息存储。请问如何在这两个不同的Spring Boot应用中实现该外键关联？

数据库表信息 #

现有表列表 #

mysql> show tables;
+----------------------+
| Tables_in_spamspring |
+----------------------+
| _user                |
| message              |
+----------------------+
2 rows in set (0.00 sec)

_user表结构 #

mysql> desc _user;
+----------+--------------------------+------+-----+---------+----------------+
| Field    | Type                     | Null | Key | Default | Extra          |
+----------+--------------------------+------+-----+---------+----------------+
| uid      | bigint                   | NO   | PRI | NULL    | auto_increment |
| email    | varchar(50)              | NO   |     | NULL    |                |
| name     | varchar(50)              | NO   |     | NULL    |                |
| password | varchar(255)             | NO   |     | NULL    |                |
| role     | enum('ADMIN','CUSTOMER') | YES  |     | NULL    |                |
+----------+--------------------------+------+-----+---------+----------------+
5 rows in set (0.01 sec)

message表结构 #

mysql> desc message;
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | bigint       | NO   | PRI | NULL    | auto_increment |
| content   | varchar(255) | YES  |     | NULL    |                |
| timestamp | datetime(6)  | YES  |     | NULL    |                |
| user_id   | bigint       | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

现有实体类 #

Message实体类（消息服务）

package com.message.userMessage.Entity;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import lombok.Data;
import java.time.LocalDateTime;
@Data
@Entity
public class Message {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private Long userId; // 关联User表的外键
    private String content;
    private LocalDateTime timestamp;
}

User实体类（用户认证服务）

package com.spam.shield.model;

import java.util.Collection;
import java.util.List;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.security.core.userdetails.UserDetails;
import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.EnumType;
import jakarta.persistence.Enumerated;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
@Entity
@Table(name = "_user")
public class User implements UserDetails {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long uid;
    @Column(length = 50, nullable = false)
    private String name;
    @Column(length = 50, nullable = false)
    private String email;
    @Column(nullable = false)
    private String password;
    @Enumerated(EnumType.STRING)
    private Role role;

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return List.of(new SimpleGrantedAuthority(role.name()));
    }

    @Override
    public String getPassword() {
        return password;
    }

    @Override
    public String getUsername() {
        return email;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

在微服务架构中，跨服务的数据库外键关联需要平衡数据一致性和服务独立性，以下是两种可行方案：

方案一：数据库级外键约束（直接关联） #

操作步骤 #

1. 在数据库中给message表添加外键约束，关联_user表的uid：

ALTER TABLE message
ADD CONSTRAINT fk_message_user
FOREIGN KEY (user_id) REFERENCES _user(uid)
ON DELETE SET NULL; -- 可选：用户删除时消息设为无关联，或用ON DELETE CASCADE直接删除消息

2. 调整消息服务的Message实体类，仅映射字段无需关联用户实体：

@Data
@Entity
public class Message {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "user_id")
    private Long userId;
    
    private String content;
    private LocalDateTime timestamp;
}

优缺点 #

• 优点：数据库层面强制保证数据一致性，不会出现无效用户ID的消息数据。
• 缺点：服务间数据库耦合度提升，用户服务的数据库变更可能直接影响消息服务，违背微服务"独立自治"的设计原则。

方案二：应用级软关联（推荐） #

去掉数据库外键约束，通过应用层逻辑保证数据有效性，完全符合微服务架构的解耦要求。

操作步骤 #

1. 消息存储前验证用户存在性
   在消息服务中通过Feign调用用户认证服务的接口，确认userId的有效性：

• 添加Feign依赖（pom.xml）：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

• 创建Feign客户端接口：

@FeignClient(name = "user-auth-service") // 用户认证服务的注册名
public interface UserClient {
    @GetMapping("/users/{uid}")
    ResponseEntity<UserDto> getUserById(@PathVariable("uid") Long uid);
}

• 定义UserDto（仅包含必要字段，避免依赖用户服务实体）：

@Data
public class UserDto {
    private Long uid;
    private String email;
    private String name;
}

• 业务逻辑中添加验证：

@Service
public class MessageService {
    @Autowired
    private MessageRepository messageRepository;
    @Autowired
    private UserClient userClient;

    public Message saveMessage(Message message) {
        // 验证用户是否存在
        ResponseEntity<UserDto> response = userClient.getUserById(message.getUserId());
        if (!response.getStatusCode().is2xxSuccessful()) {
            throw new IllegalArgumentException("无效的用户ID");
        }
        message.setTimestamp(LocalDateTime.now());
        return messageRepository.save(message);
    }
}

2. 消息检索时关联用户信息
   查询消息后，批量调用用户服务接口获取用户信息并组装：

public List<MessageWithUserDto> getMessagesByUserId(Long userId) {
    List<Message> messages = messageRepository.findByUserId(userId);
    ResponseEntity<UserDto> userResponse = userClient.getUserById(userId);
    UserDto user = userResponse.getBody();
    
    return messages.stream().map(msg -> {
        MessageWithUserDto dto = new MessageWithUserDto();
        dto.setMessage(msg);
        dto.setUser(user);
        return dto;
    }).collect(Collectors.toList());
}

@Data
class MessageWithUserDto {
    private Message message;
    private UserDto user;
}

优缺点 #

• 优点：服务完全解耦，可独立部署、变更；避免数据库层面的耦合风险。
• 缺点：需额外开发跨服务调用逻辑，存在网络开销；需处理用户服务不可用的异常场景（可添加降级、缓存策略优化）。

注意事项 #

• 数据库级外键仅适用于两个服务共用同一数据库实例的场景，跨库无法创建外键约束。
• 应用级关联建议添加Redis缓存存储常用用户信息，减少对用户服务的调用次数，提升性能。
• 无论采用哪种方案，都需明确用户删除后的消息处理规则（如标记"用户已删除"或清理无效消息）。

内容的提问来源于stack exchange，提问作者Tholkappiar