在我的新工作项目中，我发现不是直接从一个微服务向另一个微服务进行 post/put API 调用，而是一个微服务会向 kafka 生成一条消息，然后由单个微服务使用。
例如，Order 微服务会将记录发布到“待定订单”主题，然后由 Inventory 微服务（没有其他消费者）使用。反过来，在消费记录并完成一些处理之后，Inventory 微服务将生成一条记录到“已处理订单”，然后仅由 Order 微服务使用。
这是一个正确的用例吗？还是在这种情况下只在微服务之间进行 API 调用会更好？
【问题讨论】：
标签： rest apache-kafka microservices kafka-consumer-api spring-kafka
微服务作为消费者，对我来说似乎很可疑。您可能意味着该主题的侦听器会使用该消息，并且他们可能会调用您的第二个微服务，即库存微服务。
是的，该模型很好，特别是当您希望通过它处理异步行为和流量负载时。
想象一个场景，当您从 1 个端点调用多个微服务时。在这里，您需要一个聚合层来聚合您的服务并调用一次，或者您想向 Kafka 发布几条消息，然后由它来完成这项工作。
另外想想Read services，如果你需要调用一个微服务从其他地方读取一些数据，那么你就不能使用Kafka。
这完全取决于您的要求和设计。
【讨论】：
在基于微服务的应用程序中有两个强大的 Kafka 用例：
作为单个最终用户活动的一部分，您需要在多个微服务中进行状态更改。如果您通过顺序或并行调用所有适当的微服务 API 来执行此操作，则会出现两个问题： 首先，你失去了原子性，即你不能保证 "all or nothing" 。很可能调用微服务 A 成功但调用服务 B 失败，这将导致数据永久不一致。其次，在云环境中不可预测的延迟和网络超时并不少见，因此当您在一次呼叫中进行多次呼叫时，其中一个呼叫延迟或失败的可能性会更高地影响用户体验。因此，这里的一般建议是，您将用户操作原子地写入 Kafka 主题中作为一个事件，并拥有多个消费者组——每个感兴趣的微服务一个消费组消费该事件并在他们自己的数据库中进行状态更改。如果操作是由用户从 UI 触发的，您还需要提供“读取您自己的写入”保证，用户希望在写入后立即查看他的数据。因此，您需要先将事件写入第一个微服务的本地数据库，然后执行基于日志的event sourcing（使用适当的 Kafka 连接器）将事件数据传输到 Kafka。这将使您能够从本地数据库向用户显示数据。您可能还需要更新缓存、搜索索引、分布式文件系统等，所有这些都可以通过使用各个微服务发布的 Kafka 事件来完成。
需要从多个微服务中提取数据以执行某些活动或聚合数据并显示给用户的情况并不少见。由于上述延迟和超时问题，通常不建议这样做。通常建议我们根据其他微服务在更改自己的状态时发布的 Kafka 事件，在微服务本地数据库中预先计算这些聚合。这将使您能够更快地向用户提供聚合数据。这称为materialized view 模式。
这里要记住的唯一一点是写入 Kafka 日志或代理并异步读取它，并且可能会有一点时间延迟。
【讨论】：