事件源和API管理平台能相互利用吗？

Question

我正在评估如何使用Kafka在已经使用API管理平台的微服务环境中实现事件源。

我想知道使用API管理作为获取Kafka主题的网关是否很常见和/或被认为是一种良好的实践。好处可以是分析、缓存、速率限制和改进网关层(可能还有其他)的访问控制。

然而，微型服务之间的交流一直是讨论的一个主要议题。我主要怀疑的是：

1. 在通信时，我的微服务应该直接调用内部API (通过API管理)还是应该直接从Kafka主题生成/使用事件？有一些微服务来公开API是一种反模式吗?但是如果没有使用这个API(即直接在Kafka中)，那么对底层数据的一些更改会发生吗？
2. 由于我使用的是事件源，而且所有的微服务都可以访问这个单一的真相来源，那么我是否需要在微服务之间进行如此多的通信呢？我可以复制我在本地资源中需要的数据，并且只担心在其他几个微服务需要采取行动的事务中进行通信(例如，一个支付管道)。这是个好做法吗？

Answer 1

一般来说，事件流和API之间的关系仍然是一个有争议的话题，我认为这样的问题没有一个正确的答案。但是，对于每个具体的用例，我们应该能够根据性能、成本、安全性...etc等多种因素找到合适的架构师。

在回答你们的问题之前，让我澄清以下几点：

1. Kafka为存储/流事件日志提供了高度可伸缩和可用的解决方案。因此，它不需要缓存或速率限制。事实上，限制速率不应该是流解决方案的要求，因为您需要使用订阅主题中的所有事件。您可以过滤您正在消费的东西，但这将从消费者方面进行。
2. API调用和事件流之间的主要区别是通信协议。API主要使用HTTP之类的同步通信，而流则使用异步通信。
3. 在微型服务领域，应尽可能避免同步通信(特别是对于内部服务通信)。
4. 对于外部订阅者，Kafka有一些解决方案，比如Confluent代理将Kafka主题公开为HTTP。

回到你的问题：

1. 可能有一些场景需要通过流和API公开相同的数据。Steams返回日志/历史记录，而API可以返回相同聚合的最终状态。但是，只要有可能，使用事件流就会更有效。它将消除服务之间的依赖，使用异步调用，并减少通信量。
2. 这是正确的。但是值得一提的是，您应该确保复制只适用于来自不同有界上下文的数据，并且它们最终是一致的。另外，值得一提的是，即使像支付这样的Saga模式也可以使用事件源异步处理。