Identity Server与Web API的用户数据同步方案咨询

场景概述 #

系统架构包含三个核心组件：

• 存储用户认证数据的Identity Server数据库
• 拥有独立数据库的Web API，负责存储/返回游戏业务数据（存档进度、技能树进度等）
• 安卓端UE5客户端

核心需求：Identity Server负责用户注册（含未来Google授权登录），需同步用户数据至Web API数据库，同时避免不合理的耦合方案。

推荐标准方案：事件驱动的用户数据同步 #

这是独立服务架构下解决跨系统用户数据同步的典型方案，核心思路是通过事件通知实现松耦合的同步：

具体实现步骤 #

1. Identity Server侧触发用户事件

   • 当用户完成本地注册、或首次通过第三方（如Google）授权登录时，触发UserRegistered事件；当用户基础信息（用户名、邮箱等）更新时，触发UserUpdated事件
   • 可通过.NET内置的事件发布机制，或轻量消息队列（如RabbitMQ、Redis Pub/Sub）发布事件，事件内容只需包含**用户唯一标识（IS侧的SubjectId）**及业务必要的基础信息（如用户名、邮箱），无需同步敏感数据（如密码哈希）

2. Web API侧监听并同步数据

   • 在Web API中订阅上述事件，收到事件后执行以下逻辑：
     • 检查本地数据库是否已存在对应SubjectId的用户
     • 不存在则创建新用户实体，仅保留业务关联所需字段（以SubjectId作为唯一约束）
     • 已存在则更新本地用户的基础信息
   • 实现时需保证幂等性，避免重复创建用户（比如通过数据库唯一索引限制SubjectId）

3. 第三方授权（如Google）的处理

   • 用户首次通过Google登录时，Identity Server会自动创建新用户并触发UserRegistered事件，Web API按正常逻辑同步即可
   • 若用户后续切换登录方式（如从本地账号切换到Google），Identity Server会关联已有用户并触发UserUpdated事件，Web API同步更新用户关联信息

对两种不理想方案的分析 #

• 共用同一数据库及Users表：会导致DBContext状态冲突、数据库迁移混乱，同时违反单一职责原则——Identity Server专注认证，Web API专注业务，耦合后会大幅提升维护成本和故障风险
• 合并为一个项目：同样违背单一职责，后续认证协议升级、业务功能扩展会互相影响，部署和扩容也缺乏灵活性

额外注意事项 #

• 数据最小化：Web API仅同步业务必需的用户信息，不要冗余存储Identity Server侧的认证相关数据
• 同步可靠性：若使用消息队列，需配置死信队列处理失败事件，避免数据丢失；也可添加定时补偿任务，定期对比两边用户数据差异
• 标识一致性：全程以Identity Server的SubjectId作为用户唯一标识，确保跨系统用户关联的准确性

内容的提问来源于stack exchange，提问作者Роман Пермяков