Kafka微服务正确用例

Question

在我的新作项目中，我发现，一个微服务不会直接对另一个微服务进行post/put API调用，而是会向kafka生成一条消息，然后由单个微服务使用。

例如，Order微服务将向“Pending-Order”主题发布一条记录，然后该记录将被Inventory微服务（没有其他消费者）消费。反过来，在消费记录并进行一些处理之后，Inventory微服务将生成一个“Processed-Order”的记录，然后该记录将仅由Order微服务消费。

这是一个正确的用例吗？还是在这种情况下只做微服务之间的API调用更好？

Answer 1

在基于微服务的应用程序中，Kafka有两个强大的用例：

>

您需要在多个微服务中进行状态更改，作为单个最终用户活动的一部分。如果您通过顺序或并行地调用所有适当的微服务API来实现这一点，将会出现两个问题：首先，您失去了原子性，即您不能保证“全部或全部”。很有可能对微服务A的调用成功，但对服务B的调用失败，这将导致永久的数据不一致。其次，在云环境中，不可预测的延迟和网络超时并不少见，因此，当您在一个呼叫中进行多个呼叫时，其中一个呼叫延迟或失败的概率会更高，从而影响用户体验。因此，这里的一般建议是，您在Kafka主题中将用户操作原子化地编写为一个事件，并拥有多个消费者组--每个感兴趣的微服务都有一个消费者组消费该事件，并在他们自己的数据库中更改状态。如果操作是由用户从UI触发的，那么您还需要提供一个“读您自己写”的保证，用户希望在写入后立即看到他的数据。因此，您需要首先在第一个微服务的本地数据库中写入事件，然后执行基于日志的事件源（使用aporopriate Kafka连接器）以将事件数据传送到Kafka。这将使您能够从本地DB向用户显示数据。您可能还需要更新缓存、搜索索引、分布式文件系统等，所有这些都可以通过使用单个微服务发布的Kafka事件来完成。

需要从多个微服务中提取数据来执行某些活动或聚合数据并显示给用户的情况并不少见。由于上面提到的延迟和超时问题，通常不建议这样做。通常建议我们在微服务本地数据库中根据其他微服务在更改自身状态时发布的Kafka事件预先计算这些聚合。这将允许您更快地向用户提供聚合数据。这称为物化视图模式。

这里要记住的唯一一点是写入Kafka日志或broker，并从它异步读取，可能会有一点时间延迟。