微服务审计日志：跨服务获取可读文本的优化方案咨询

异步补全审计消息 #

• 主业务流程只生成带原始ID的审计消息，直接写入Cosmos DB，完全不阻塞数据保存操作
• 单独部署一个异步审计处理服务，要么监听Cosmos DB的新增事件，要么通过消息队列接收初始审计消息
• 该服务专门负责跨服务调用（比如调用服务B）获取关联ID的可读名称，补全后更新Cosmos DB中的审计记录
• 调用失败时加入重试机制，用死信队列存放无法处理的消息，确保数据不丢失

事件驱动的轻量元数据同步 #

• 约定元数据变更事件，当服务B中关联记录的名称发生变化时，主动发布事件到全局事件总线
• 每个服务维护一个仅存储ID和对应可读名称的轻量化本地存储（比如小型Redis实例或本地数据库表），订阅对应事件并实时更新
• 服务A生成审计消息时，直接从本地轻量化存储读取名称，无需跨服务调用；若未找到则标记为待补全，后续由异步服务处理
• 仅同步必要元数据，数据量远小于全量业务数据，避免本地存储的容量压力

延迟渲染与按需解析可读文本 #

• 审计消息中仅存储原始ID和关联服务标识，不提前生成可读文本
• 用户查询审计日志时，由审计查询服务实时调用对应服务获取可读名称并渲染展示
• 针对频繁查询的记录，查询服务可设置短期缓存（比如5分钟），减少重复调用；非频繁查询则直接实时获取
• 前端展示时先显示ID，异步加载可读名称，避免影响用户体验

批量异步调用关联服务轻量接口 #

• 与服务B约定轻量元数据接口，仅返回ID对应的可读名称，避免返回全量业务数据
• 服务A生成审计消息时，将需要补全的ID打包，通过异步批量请求调用服务B，把审计消息的生成和保存放在异步线程中，主流程直接返回不阻塞
• 若调用失败，先保存原始审计消息，后续通过重试机制补全；同时设置超时时间，避免长时间等待

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