使用 REST/HTTP 的请求-响应通信简单易懂，并且受到大多数技术、产品和 SaaS 云服务的支持。相比之下，Apache Kafka 的数据流是对数据连续处理的根本改变。HTTP 和 Kafka 以各种方式相互补充。这篇文章探讨了架构和用例，以利用控制平面中的请求-响应和数据流进行管理，或利用数据平面中的数据流来生成和使用事件。

请求-响应 (HTTP) 和数据流 (ApacheKafka)

在讨论 HTTP/REST 和 Apache Kafka 之间的关系之前，让我们先探讨一下两者背后的概念。传统上，请求-响应和数据流是两种不同的范例。

使用 REST/HTTP 的请求-响应

以下特征使 HTTP 在请求-响应（又名请求-回复）通信的软件工程中如此普遍：

万维网数据通信基础

Internet协议族中的标准应用层协议，俗称TCP/IP

容易理解

受大多数开源框架、专有产品和 SaaS 云服务的支持

带有 GET、POST、PUT 和 DELETE 命令的预定义 API

通常是同步通信，但分块传输编码（即流式传输）也是可能的

两个应用程序（如客户端和服务器或两个独立的微服务）之间的点对点消息交换

使用 Apache Kafka 进行数据流式传输

HTTP 是关于两个应用程序之间的通信。相反，数据流不仅仅是客户端和服务器之间的数据通信。因此，像 Apache Kafka 这样的数据流平台具有非常不同的特点：

没有像 HTTP 这样的官方网络标准

存在许多开源和专有实现

由于流媒体平台存储，使用真正解耦的生产者和消费者的异步通信的事件驱动系统

通用事件而不是预定义的 API - 使用模式的合同管理在 API 实施和数据治理的大型项目中至关重要

任何规模的实时连续数据处理——对于习惯于使用 Web 服务和数据库构建应用程序的开发人员来说，这是一个根本性的变化

背压处理、慢消费者和历史事件的可重放性是开箱即用的内置核心概念

数据集成和数据处理能力内置于数据流平台中，即它不仅仅是一个消息队列

请注意，本文专门讨论 Apache Kafka，因为它是数据流的既定事实标准。它为大多数流媒体发行版提供支持，如 Confluent、RedHat、IBM、Cloudera、TIBCO，以及 ConfluentCloud 和 AmazonMSK 等云服务。尽管如此，其他框架和云服务（如 Apache Pulsar、Redpanda、Apache Flink、AWS Kinesis 和许多其他数据流技术）都遵循相同的原则。请注意数据流产品之间的技术差异和权衡。

请求-响应和流式传输是免费的

大多数体系结构都需要请求-响应和数据流来进行点对点通信（例如，服务器和移动应用程序之间）的连续事件处理。

使用 CQRS 的事件溯源是大多数数据流场景的更好设计。但是，开发人员可以使用 Apache Kafka 在本地实现请求-响应消息交换模式。

然而，与 Kafka 的直接 HTTP 通信对于适当的用例来说是更简单且通常更好的方法。考虑到这一点，让我们看看 HTTP 与 Kafka 一起工作的用例以及它们如何相互补充。

为什么 HTTP/REST 如此受欢迎？

大多数开发人员和管理员都熟悉 REST API。它们是许多最佳实践和安全指南的自然选择。以下是未来不会改变的一些充分理由：

避免技术锁定：有时，您希望嵌入通信或使用更不可知的 API 代理它。

熟悉已知技术：开发人员熟悉 REST 端点，如果他们面临压力或需要快速获得结果，这比学习如何使用新 API 更快。

几乎所有产品都支持：大多数开源框架、商业产品和 SaaS 云都提供 HTTP API。

安全性：对于来自 Java、Go、C++ 或 Python 等编程语言的客户端 API 使用的 Kafka 本机协议，安全团队更容易打开 HTTP 端口而不是 TCP 端口。例如，在 DMZ 直通要求中，InfoSec 在 DMZ 中有 F5 代理。KafkaREST 代理使集成更容易。

领域驱动设计 (DDD)：通常，HTTP/REST 和 Kafka 结合起来利用两全其美：用于解耦的 Kafka 和用于同步客户端-服务器通信的 HTTP。使用带有 REST API 的 Kafka 的服务网格是一种常见的架构。

存在用于请求-响应通信的其他优秀实现。例如：

gRPC：通过跨平台开源高性能远程进程称为框架的高效请求-响应通信

GraphQLAPI 的数据查询和操作语言和运行时使用现有数据完成查询

但是，HTTP 是大多数项目的首选。如果 HTTP 不够好，请选择 gRPC、GraphQL 或其他实现来解决您的特定问题。

使用 Apache Kafka 的 HTTP/REST API 的用例

Apache Kafka 集群的 RESTful 接口使得生成和使用消息、查看集群的元数据以及使用标准 HTTP(S) 而不是基于 TCP 的本机 Kafka 协议或客户端执行管理操作变得容易。

每个场景的目的都非常不同。有些用例是出于方便而实施的，而其他用例是由于技术规范而需要的。

将 HTTP 与 Kafka 结合使用有两大类用例。就云原生架构而言，这可以分为管理平面（即管理和配置）和数据平面（即数据的生产和消费）。

使用 HTTP 和 Kafka 的管理平面

Kafka 集群的管理和管理涉及各种任务，例如：

集群管理：集群创建、集群扩缩容等。

集群配置：Kafka主题管理、消费者组、密钥管理、基于角色的访问控制（RBAC）等。

CI/CD 和 DevOps 集成：HTTP API 是构建交付管道和自动化管理的最流行方式，而不是使用 Python 或其他替代脚本选项。

数据治理：需要使用 API 配置用于数据沿袭、数据目录和策略实施的工具。

第 3 方监控集成：将指标 API、警报和其他通知连接到 Datadog、Slack 等。

使用 HTTP 和 Kafka 的数据平面

许多场景需要或更喜欢使用 REST API 来生产和消费来自 Kafka 的消息，例如

自然的请求-响应应用程序，例如移动应用程序：这些应用程序和框架几乎总是需要通过 HTTP 和请求-响应进行集成。WebSockets、服务器发送事件 (SSE) 和类似概念更适合使用 Kafka 进行数据流传输。它们位于客户端框架中，但通常不受支持。

遗留应用程序和第三方工具集成：遗留应用程序、标准软件和遗留中间件通常是专有的。唯一的集成功能是 HTTP/REST。提取、转换、加载 (ETL)、企业服务总线 (ESB) 和其他第三方工具补充了 Kafka Dataflow。使用 REST API 从 COBOL 到 Kafka 的大型机集成是另一个例子。

API Gateway：目前大多数API管理工具不提供对数据流和Kafka的原生支持，只能工作在REST接口之上。Kafka（通过 REST 接口）和 API 管理对于某些用例仍然非常互补，例如服务货币化或与合作伙伴系统的集成。

其他编程语言：Kafka 提供 Java 和 Scala 客户端。Confluent 提供并支持其他客户端，包括 Python、.NET、C、C++ 和 Go。社区中存在更多 Kafka 客户端，包括 Erlang、Kotlin、Node.js、PHP、Ruby 和 Rust。许多这些社区客户都没有经过实战测试或支持。因此，从您最喜欢的编程语言调用 REST API 有时是更好、更容易的选择。其他的，比如大型机上的 COBOL，甚至根本不提供 Kafka 客户端。因此，REST API是唯一可能的解决方案示例：HTTP+KafkaWithConfluentRESTProxy。

标签：集群配置,RESTful接口,C++,Python,TCP端口 来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。