微服务架构下如何处理created by字段的用户名映射问题？

以下为三类可落地的解决方案，可根据实际业务场景选型：

方案1：BFF层统一聚合（推荐优先考虑，无一致性问题） #

• 逻辑完全收敛在面向前端的BFF（Backend For Frontend）层，库存服务、用户服务无需改造，保持域边界完全解耦
• 前端请求库存列表时，BFF先调用库存服务拿到最多100条记录，提取所有非重复的createdBy用户ID，批量调用一次用户服务查询对应的用户名，拼装后返回给前端
• 可在BFF层加短时效（比如5~10分钟）的ID-用户名本地缓存，进一步降低调用用户服务的频率，缓存过期自动淘汰，不会产生长周期的一致性问题
• 优势：无数据一致性风险，服务完全解耦，100条量级的批量调用性能损耗可以忽略，开发成本极低

方案2：库存服务本地维护轻量映射表（适合接受最终一致的场景） #

• 库存服务新增仅含user_id、user_name两个字段的轻量映射表，不存储其他用户信息
• 监听用户服务抛出的用户名变更事件（通过MQ实现），消费到事件后更新本地映射表的对应记录，可配合定时增量校对任务处理消息丢失的极端情况，保证最终一致性
• 库存查询时直接关联本地映射表即可拿到用户名，完全不需要跨服务调用
• 优势：查询性能最优，服务耦合度极低，一致性延迟通常在毫秒到秒级，绝大多数业务场景都可接受

方案3：库存表冗余用户名字段（适合用户名修改频率极低的场景） #

• 库存业务表除createdBy存用户ID外，新增created_by_name冗余字段，写入库存记录时直接从请求上下文取当前用户名写入
• 监听用户服务的用户名变更事件，异步批量更新该用户关联的所有库存记录的冗余用户名字段
• 优势：库存查询为单表查询，性能最高，开发成本极低
• 注意：如果单用户关联的库存记录量级超过十万、或者用户修改用户名的频率很高，不推荐该方案，异步批量更新会产生不必要的数据库压力

选型建议 #

如果业务要求用户名必须完全实时一致，优先选方案1；如果可以接受秒级的最终一致，优先选方案2；如果平台用户名修改频率极低（比如月活用户中修改用户名的占比低于0.1%），选方案3性价比最高。

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