在微服务架构中，我们通常有两种方式来通信2个微服务。假设服务A需要从服务B获取信息。第一个选项是远程调用，通常是通过HTTPS同步的，因此服务A查询服务B托管的API。
第二种选择是采用事件驱动的体系结构，其中服务B的状态可以由服务A以异步方式发布和使用。使用此模型，服务A可以使用服务B的事件信息更新其自己的数据库，并且所有查询都在该数据库本地进行。从开发到运营，这种方法的优点是更好地分离了微服务。但是它具有与数据复制相关的一些缺点。
第一个是磁盘空间的高消耗，因为相同的数据可以驻留在需要它的微服务的数据库中。但是第二个是我认为最糟糕的情况：如果服务B无法按需要快速处理其订阅，或者服务B在服务B创建的同时不能用于服务A，则数据可能会过时。最终实现模型的一致性。
假设我们将Kafka用作活动中心，其主题配置为保留7天的数据。服务B在其发布状态时保持同步。两周后，将部署一个新的服务C，并且需要使用服务B拥有的所有信息来丰富其数据库。由于最古老的事件已经过去，因此我们只能从Kafka主题中获取部分信息。我的问题是我们可以使用哪些模式来实现此微服务的数据库充实（除了要求服务B将其所有当前状态重新发布到事件中心之外）。