围绕 Kafka 的 REST Wrapper - 反模式？答案

【问题标题】：REST Wrapper around Kafka- Anti-Pattern?围绕 Kafka 的 REST Wrapper - 反模式？
【发布时间】：2020-09-09 08:19:45
【问题描述】：

不仅仅是一个问题，这是我面临的架构困境。在 Kafka Producer 周围使用 REST 包装器并与之集成，而不是在我的代码中直接与 Kafka Producer 集成，这是一个好主意吗？我可以为我的高级类使用通用接口，而不是直接使用 KafkaImpl 来保持松散耦合以备将来使用。

【问题讨论】：

【解决方案1】：

如前所述，kafka-rest-proxy 会起作用。

我知道很多人用 Spring Kafka、Mircaut、Akka、Quarkus、Lagom/Play 来包装 Kafka 生产者/消费者，仅举几例。具体来说，Spring 具有可以提供“通用接口”感觉的消息传递绑定器。

这些都是web框架，在任何代码上加一个API/RPC抽象层就是definitely necessary in 12factor applications

【讨论】：

对，但我拥有端到端的应用程序，并且认为不需要 Kafka 上的代理。如果是松耦合的代码，我还不如用一个接口和 Kafka 特定的实现来做。添加 REST 抽象会损失多少 Kafka 的吞吐量。
完全没有。我不明白这个问题。您可以使用通用 REST 代理并且根本不编写任何代码。或者，您可以添加自己的特定 RPC 层。（可能是 gRPC、Avro-RRC、Thrift、GraphQL 等）。它不一定是 HTTP，这可能是您实际上简单地说“REST”的意思。 REST 不是一种服务；它是协议的描述。
我的意思是，如果直接使用 Kafka Producer，那就是一劳永逸。每个请求大约需要 5 毫秒。一个 HTTP 包装器需要大约 200 毫秒的往返行程。我的问题是我是否将 REST 与消息传递模式混为一谈并失去了性能
如果你禁用了acks，它只会一劳永逸。 gRPC 也比 REST 往返更快，因为在 TPC 传输中没有这样的 HTTP 数据包开销

【解决方案2】：

如果您可以选择，我可能会选择纯 Kafka 方法，因为您可以获得更好的吞吐量（客户端在批处理和期货方面非常智能）。

我不确定您是否通过添加休息包装器来解耦代码；您只是添加了另一个抽象级别，增加了维护负担并涵盖了 Kafka 的一些好处。

如果你真的需要使用 REST，你可以使用Kafka-Rest - 无需重新发明轮子！

【讨论】：

我拥有端到端的应用程序。只是我的一些同行受到了现有实现的影响，在该实现中创建了 REST 代理，无论出于何种原因。我相信如果我在 Kafka 周围添加一个 HTTP 包装器，我会失去它并忘记它的好处。
如果没有更多关于您的项目的上下文，我无法告诉您您的选择是对还是错。然而，小心货物崇拜编程 - 了解 为什么 其他解决方案使用 REST 代理。总体来说是一个不错的选择吗？它解决了什么问题？费用是多少？（包括操作）。我要提出的一件事是，如果您不确定 REST 代理是否是正确的解决方案，您是否充分考虑过您的域？卡夫卡可以成为管理的野兽；你需要卡夫卡吗？ RabbitMQ 会工作吗？普通的 REST 会起作用吗？您的容量和持久性要求是什么？
我有一个调度程序，每天运行两次，最多发送 5k 封电子邮件。因此调度程序和电子邮件程序之间的卡夫卡。我并没有真正看到 REST 代理的意义，但是当我提出吞吐量参数并且 REST 正在同步等等时，我得到了“我们上次就是这样做的”。
如果您不需要保留消息，兔子（或其他）可能会为您节省一段时间的痛苦。假设您的公司目前没有 Kafka 集群。否则，原始 Kafka 似乎是合理的