Compliance Central Microservice设计选型咨询：两种方案利弊分析

背景概述 #

现有三个领域微服务：薪资处理（salary processing）、卡片服务（cards）、KYC文档服务（kyc docs），需执行两条核心合规规则：

• KYC文档过期时，冻结对应用户的卡片
• 用户月度薪资到账金额超限（如超过5000美元）时，删除对应卡片
  计划引入**合规中心微服务（Compliance Central Microservice）**统一处理合规事务，现有两个设计方案各存缺陷，以下是方案分析及优化建议：

设计1：领域微服务本地评估合规规则 #

方案流程 #

• 领域微服务每日从合规中心拉取合规规则并本地缓存（例如月度薪资上限、KYC有效期要求）
• 领域微服务依据缓存规则完成合规评估，触发违规时发布事件（如「薪资超限」「KYC文档过期」）
• 合规中心接收违规事件后，执行冻结/删除卡片操作，仅记录违规事件

核心顾虑 #

领域微服务是否应当承担合规评估职责？

问题与优化方向 #

领域微服务的核心职责是聚焦自身业务（薪资计算、卡片生命周期管理、KYC存储），嵌入合规评估逻辑会带来以下问题：

• 职责耦合：规则变更（如薪资上限调整）时，所有相关领域服务都需同步更新缓存逻辑或重启，运维成本极高
• 一致性风险：多服务缓存规则可能出现同步延迟，导致同一违规场景出现不同评估结果
• 审计困难：评估逻辑分散在各领域服务，合规审计需跨多服务排查，无法统一追溯判断依据

优化建议：保留领域服务触发业务事件的能力，但将合规评估逻辑完全剥离至合规中心，领域服务仅上报业务事实，不做规则判断。

设计2：合规中心统一订阅事件并评估 #

方案流程 #

• 领域微服务无需知晓合规规则，仅在业务操作完成后发布事实事件（如「薪资到账」「KYC文档更新」）
• 合规中心订阅所有领域事件，每日批量检查违规情况，触发卡片冻结/删除操作，同时记录所有事件

核心顾虑 #

合规中心需存储大量跨领域数据，存储成本与管理压力过大

问题与优化方向 #

该方案的职责边界清晰，但批量检查+全量存储的设计存在明显缺陷：

• 实时性不足：每日批量检查可能导致违规行为发生后无法及时处理（如KYC过期后卡片仍可正常使用一整天），不符合合规时效性要求
• 数据冗余：合规中心全量存储领域事件属于重复存储，增加存储成本与数据一致性维护复杂度

优化建议：

1. 按需获取数据，避免全量存储：合规中心评估时，通过API调用对应领域服务获取必要数据（如检查KYC有效期时调用KYC服务，检查薪资超限时调用薪资服务），无需持久化存储所有领域数据
2. 事件驱动实时评估：将每日批量检查改为事件触发的实时评估——合规中心收到领域事件后，立即针对对应场景执行合规检查，无需等待批量任务

整合优化后的最优方案 #

结合两个方案的优势，规避各自缺陷，推荐以下架构设计：

1. 领域服务：聚焦业务，上报事实事件 #

• 仅负责自身核心业务逻辑，不耦合任何合规规则
• 在关键业务节点发布事实型事件（如「薪资到账完成」「KYC文档更新完成」「卡片激活完成」），事件中携带用户ID、业务标识等必要信息

2. 合规中心：统一规则管理与实时评估 #

• 负责存储、维护所有合规规则，提供规则增删改查能力
• 订阅领域服务的事实事件，针对不同事件类型触发对应合规检查：
  • 收到「薪资到账完成」事件：调用薪资服务查询用户当月累计薪资，与规则上限对比，超限则发布「薪资超限需删除卡片」指令事件
  • 收到「KYC文档更新完成」事件：调用KYC服务查询文档有效期，过期则发布「KYC过期需冻结卡片」指令事件
• 仅存储合规检查的结果数据（违规事件记录、规则执行日志），无需存储原始领域事件或业务数据

3. 卡片服务：响应合规指令 #

• 订阅合规中心的指令事件，执行冻结/删除卡片操作，并发布操作完成事件供审计使用

方案优势 #

• 职责清晰：各微服务聚焦自身核心能力，符合微服务单一职责原则
• 实时合规：事件触发实时评估，违规行为可及时处理，满足合规时效性要求
• 扩展性强：新增合规规则仅需调整合规中心逻辑，新增领域服务仅需合规中心订阅其事件
• 审计便捷：合规评估与执行日志集中存储，便于后续审计与追溯

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