如何向已运行系统添加新服务/限界上下文？历史数据同步方案咨询
现有两个限界上下文：Project和Budgets。Project添加新成员时发布
MemberAdded事件，Budgets监听该事件并创建本地Member实体副本（仅保留所需数据）。使用Kafka作为消息中间件，事件仅存储7天。后续新增Orders服务，需要基于历史MemberAdded事件生成本地Customer实体副本，但此时无法获取已过期的历史事件，该如何处理？
以下是几种可行的解决方案：
持久化事件存储全量重放
搭建一个长期留存所有事件的持久化存储（比如专门的事件溯源库，或者把Kafka对应主题的消息保留周期调整为永久/足够覆盖全量历史）。新增服务启动时，先从这个存储拉取所有历史MemberAdded事件，完成本地Customer实体的初始化，之后再切换到监听Kafka的实时事件。这是最能保证数据完整性的方案，也是你提到的思路的具体落地。主数据导出导入
直接从Project服务的核心数据库（或者如果Budgets的本地Member数据满足Orders的需求，也可以用Budgets的数据）导出所有已存在的Member数据，转换成Orders需要的Customer格式后批量导入到Orders的数据库。完成初始化后，再开始监听实时的MemberAdded事件，后续只处理新增数据。这种方式比全量事件重放更高效，适合历史数据量大的场景。增量补全+实时监听并行
先让Orders服务开始接收实时事件，同时做历史数据补全：- 让Orders服务按时间分片或ID分段，定期向Project服务请求未同步的Member数据
- Project服务返回对应数据后，Orders服务将其转成本地Customer实体
- 直到所有历史数据同步完成，之后只依赖实时事件。这种方式能避免一次性全量同步的性能压力，适合超大数据量的场景。
临时调整Kafka保留策略（应急方案）
如果新增服务时，部分历史事件还没超过7天的保留期，可以临时把Kafka对应主题的消息保留时间调长，等Orders服务把历史事件消费完，再改回原来的7天策略。但这只是应急手段，不适合频繁新增服务的场景，而且依赖事件还没被删除的前提。
内容的提问来源于stack exchange，提问作者Arczewski
