在微服务架构中，我们通常有两种方式让两个微服务进行通信。假设服务a需要从服务b获取信息。第一个选项是远程调用，通常通过https同步，因此服务a查询是由服务b托管的api。
第二种选择是采用事件驱动体系结构，其中服务b的状态可以由服务a以异步方式发布和使用。使用此模型，服务a可以使用来自服务b的事件的信息更新自己的数据库，并且所有查询都在该数据库中本地进行。这种方法的优点是可以更好地将微服务从开发到操作分离开来。但它也有一些与数据复制相关的缺点。
第一个是磁盘空间的高消耗，因为相同的数据可以驻留在需要它的微服务的数据库中。但在我看来，第二个问题是最糟糕的：如果服务b不能以所需的速度处理其订阅，或者考虑到模型的最终一致性，数据不能在服务b上创建的同时对服务a可用，那么数据可能会过时。
假设我们使用kafka作为事件中心，其主题配置为使用7天的数据保留时间。服务a在服务b发布其状态时保持同步。两周后，部署了一个新的服务c，需要用服务b所拥有的所有信息丰富其数据库。我们只能从Kafka主题中获得部分信息，因为最古老的事件已经过去了。我这里的问题是，我们可以使用哪些模式来实现这个微服务的数据库丰富（除了要求服务b将其所有当前状态重新发布到事件中心之外）。
2条答案
按热度按时间mwngjboj1#
有两种选择：
可以为单个主题启用kafka的日志压缩。它将保留给定密钥的最新值，并丢弃旧的更新。在给定的保留期内，这样既节省了空间，又比普通模式保存了更多的数据
假设您每天都对服务b db进行备份，在引入新的服务c时，您需要首先从b的最新备份创建c的初始状态，然后从表示备份后数据的特定偏移量id重放kafka主题事件。
pvabu6sv2#
你的担心是对的，但同时微服务的方法是互通有无。以每个服务的单个数据库为代价获得松耦合。微服务体系结构没有正确的答案，这实际上取决于您试图实现的目标。
根据cap定理，您必须在一致性和可用性之间进行折衷，在大多数情况下，我们都会考虑最终的一致性。如果您的服务a与b不一致，那么它最终将是一致的，这是以可用性为代价的权衡。
关于microservice的另一件事是，您只保留来自其他服务的数据引用，来自其他服务的实际数据可能非常有限，但肯定不多。而且只有当复制数据使您的服务独立和自主时，如果即使在复制数据之后也无法实现任何一点，那么就没有意义了。e、 g.您的运输服务将有完整的订单转换历史，但您的预订服务只有最新的订单状态（如在途、已装船等）。用户进入预订，您将显示订单的当前状态。但如果用户单击“详细信息”，则可以从shipping microservice获得所有订单转换历史记录。现在，在某个时候，您的配送服务停止了，您的用户来检查状态您至少有当前的订单状态，即使您无法显示详细信息，因为订单状态在预订服务中是复制的。
对于后期加入系统的新服务，事件源是您用于此类场景的模式。它的模式很复杂，但它会将您新添加的服务带到您想要的状态。基本上，您将所有事件保存在事件存储中，并重放它们以获得系统的当前状态，并用这些事件预填充ServiceC数据库。