使用REST/HTTP的请求-响应通信很简单，很好理解，并且被大多数技术、产品和SaaS云服务所支持。相反，使用Apache Kafka的数据流是连续处理数据的一个根本性变化。HTTP和Kafka以各种方式相互补充。这篇文章探讨了架构和用例，以利用请求-响应与数据流一起在控制面进行管理或在数据面产生和消费事件。
(原载于Kai Waehner的博客。"REST/HTTP的请求-响应与Apache Kafka的数据流对比"......通过以下方式了解新博文的信息 订阅我的通讯)
请求-回应（HTTP）与数据流（Apache Kafka）的对比
在讨论HTTP/REST和Apache Kafka之间的关系之前，让我们先探讨一下两者背后的概念。传统上，请求-响应和数据流是两种不同的范式。
用REST/HTTP进行请求-响应
以下特点使HTTP在软件工程中如此盛行，用于请求-回应（又称请求-回应）通信。
- 万维网的数据通信基础
- 互联网协议套件中的标准应用层协议，通常被称为TCP/IP
- 简单且易于理解
- 得到大多数开源框架、专有产品和SaaS云服务的支持
- 带有GET、POST、PUT和DELETE命令的预定义API
- 通常是同步通信，但也可以进行分块传输编码（即流媒体）。
- 两个应用程序（如客户端和服务器或两个独立的微服务）之间的点对点消息交换
使用Apache Kafka的数据流
HTTP是关于两个应用程序之间的通信。相反，数据流远不止是客户端和服务器之间的数据通信。因此，像Apache Kafka这样的数据流平台具有非常不同的特点。
- 没有像HTTP那样的官方网络标准
- 存在大量的开源和专有实现方式
- 由于流媒体平台的存储，一个具有异步通信的事件驱动系统，使用真正的解耦生产者和消费者。
- 通用事件而不是预先定义的API--在大型项目中，使用模式的合同管理对API的执行和数据治理至关重要
- 在任何规模下的连续实时数据处理--对于习惯于用网络服务和数据库来构建应用程序的开发者来说，这是一个根本性的变化。
- 背压处理、慢速消费者和历史事件的可重放性是开箱即用的核心概念。
- 数据集成和数据处理能力内置于数据流平台，也就是说，它不仅仅是一个消息队列
请注意，这篇文章特别讨论了 Apache Kafka，因为它是数据流的既定事实标准.它为大多数数据流分布提供动力，如Confluent、Red Hat、IBM、Cloudera、TIBCO等，加上Confluent Cloud和Amazon MSK等云服务。尽管如此，其他框架和云服务，如Apache Pulsar、Redpanda、Apache Flink、AWS Kinesis，以及其他许多数据流技术都遵循同样的原则。只是要注意的是 数据流产品之间的技术差异和权衡.
请求-回应和数据流是互补的
大多数架构在点对点通信（如服务器和移动应用之间）和连续事件处理的数据流方面需要请求-响应。
对于大多数数据流应用场景来说，使用CQRS的事件源是更好的设计。然而，开发人员可以实现 与Apache Kafka原生的请求-响应消息交换模式.
尽管如此，对于适当的用例来说，与Kafka的直接HTTP通信是更容易的，而且往往是更好的方法。考虑到这一点，让我们来看看HTTP与Kafka一起使用的用例，以及它们如何相互补充。
为什么HTTP / REST如此受欢迎？
大多数开发人员和管理员都熟悉REST APIs。它们是许多最佳实践和安全准则的自然选择。下面是一些很好的理由，为什么这在未来不会改变。
- 避免技术锁定。有时，你想嵌入通信或用一个更不可知的API代理它。
- 对已知技术的熟悉。开发人员熟悉REST端点，如果他们有压力或需要一个快速的结果，这比学习如何使用一个新的API更快。
- 几乎所有的产品都支持。大多数开源框架、商业产品和SaaS云都提供HTTP APIs。
- 安全性：与Java、Go、C++或Python等编程语言的客户端API使用的Kafka原生协议的TCP端口相比，HTTP端口更容易被安全团队打开。例如，在DMZ直通要求中，InfoSec拥有DMZ中的F5代理。Kafka REST代理使整合更容易。
- 领域驱动的设计（DDD）。通常情况下。 HTTP/REST和Kafka的结合来利用两者的优点：Kafka用于解耦，HTTP用于客户端和服务器的同步通信。A 使用Kafka与REST API的服务网状结构是一种常见的架构。
对于请求-响应通信，还有其他伟大的实现方式。比如说。
- gRPC：通过一个跨平台的开源高性能远程过程调用框架进行高效的请求-响应通信
- GraphQL 用于API的数据查询和操作语言，以及用现有数据完成查询的运行时间。
然而，在大多数项目中，HTTP是第一选择。如果HTTP不够好，则选择gRPC、GraphQL或其他实现方式来解决具体问题。
使用Apache Kafka的HTTP / REST APIs的用例
Apache Kafka集群的RESTful接口使得生产和消费消息、查看集群的元数据，以及使用标准的HTTP(S)而不是基于TCP的Kafka协议或客户端执行管理操作变得容易。
每个场景的目的都有很大不同。有些用例是出于方便而实施的，而有些则是由于技术规范的要求。
将HTTP与Kafka结合起来的用例主要有两类。就云原生架构而言，可以分为管理平面（即管理和配置）和数据平面（即生产和消费数据）。
使用HTTP和Kafka的管理平面
Kafka集群的管理和行政工作涉及各种任务，如：。
- 集群管理。创建一个集群，扩大或缩小集群，等等。
- 集群配置。管理Kafka主题、消费者组、密钥管理、基于角色的访问控制（RBAC）等。
- CI/CD和DevOps整合。HTTP API是建立交付管道和自动管理的最流行方式，而不是使用Python或其他替代脚本选项。
- 数据治理。用于数据脉络、数据目录和政策执行的工具需要使用API进行配置。
- 第三方监控集成。将指标API、警报和其他通知接入Datadog、Slack等系统。
使用HTTP和Kafka的数据平面
许多场景需要或倾向于使用REST API来生产和消费Kafka的消息，例如
- 自然的请求-响应应用程序，如移动应用程序：这些应用程序和框架几乎总是需要通过HTTP和请求-响应进行集成。WebSockets、Server-Sent Events（SSE）和类似的概念更适合用Kafka进行数据流。它们都在客户端框架中，尽管通常不支持。
- 遗留应用和第三方工具集成。遗留的应用程序、标准软件和传统的中间件往往是专有的。唯一的集成能力是HTTP/REST。 提取、转换、加载（ETL），企业服务总线（ESB）。，和其他第三方工具是对Kafka的数据流的补充。 使用REST API从COBOL到Kafka的主机集成是另一个例子。
- API网关。目前，大多数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是唯一可行的解决方案。
例子 使用Confluent REST代理的HTTP + Kafka
许可证 Confluent REST Proxy已经存在了很长时间，并且可以在 Confluent社区许可证.许多公司在生产中使用它作为管理平面和数据平面，与开源的Apache Kafka、Confluent Platform或Confluent Cloud一起作为自我管理的组件。
虽然我不是律师，但简而言之，你可以免费使用Confluent REST Proxy--甚至用于你任何规模的生产工作负载--只要你不用它建立一个有竞争力的云服务（例如，"AWS Kafka HTTP Proxy"），并对无服务器产品按小时或体积收费。
Confluent REST代理和REST API被分成了数据平面和管理平面。
虽然有些应用需要两者，但在许多情况下，只使用其中之一。
管理平面通常用于非常低的全程和少数API调用。另一方面，数据平面是不同的。许多应用程序连续产生和消耗数据。REST代理数据平面的最大限制是它是一个同步的请求-响应协议。
Kafka的REST代理支持什么规模和数量？
不要低估REST代理作为数据平面的力量，因为Kafka提供了批处理能力，可以扩展到许多并行的REST代理实例。在一些部署中，四个REST Proxy实例可以每秒处理~20,000个事件，这对许多用例来说是足够的。
许多HTTP用例并不要求每秒有数百万个事件。因此，Confluent REST Proxy通常已经足够好了。我在野外看到的许多物联网用例也是如此，这些设备或机器通过HTTP连接到Kafka。
HTTP的流式数据传输是如何融入架构的？
请注意 分块传输编码是一种流式数据传输机制在HTTP的1.1版本中可用。在分块传输编码中，数据流被划分为一系列不重叠的 "块"。这些 "块 "的发送和接收是相互独立的。
一些Kafka REST Produce API支持流模式，允许在一个流上发送多个记录。除非明确终止，否则该流将保持开放。流模式可以通过在初始请求中设置一个额外的头 "Transfer-Encoding: chunked "来实现。检查你喜欢的Kafka代理或云API是否支持HTTP流模式。
Kafka+Rest Proxy的架构选择
Confluent REST代理存在不同的部署选项。
自我管理的REST代理实例或实例集群（作为一个 "专用节点"）仍然与开放的开源Kafka代理或商业Confluent服务器解耦。这是数据平面生产和消费消息的理想选择。
管理平面也被作为一个统一的REST API嵌入到Confluent服务器（作为一个 "代理插件"）和Confluent云中，用于管理操作。这简化了架构，因为使用管理API不需要额外的节点。
在某些部署中，这两种方法可以结合使用。管理平面通过Confluent服务器或Confluent云中的嵌入式REST APIs使用。同时，数据平面的用例被解耦到他们自己的REST代理实例中，以方便处理扩展性，并独立于服务器端。
开发者不需要关心Confluent云中REST API的基础设施或架构。HTTP接口完全由供应商管理。
自我管理的REST代理和Confluent云的REST API是兼容的。混合架构和云迁移是可能的，无需实施任何破坏性的改变。
用模式注册表对数据流和HTTP服务进行数据治理
数据治理是大多数数据流项目的一个重要部分。Kafka的部署通常包括各种解耦的生产者和消费者，通常遵循的是 微服务架构的DDD原则。因此。 Confluent Schema Registry在大多数项目中用于模式执行和版本管理。
任何由Confluent构建的Kafka客户端都可以使用Avro、Protobuf或JSON Schema来利用模式注册。这包括Java、Python、Go或Python等编程API，也包括Kafka Connect源和汇、Kafka Streams、ksqlDB和Confluent REST Proxy。与REST代理一样，Schema Registry也是在Confluent社区许可下提供的。
Schema Registry与你的Kafka经纪商分开生存。Confluent REST Proxy仍然与Kafka对话，向主题发布和读取数据（消息）。同时，REST代理也可以与Schema Registry对话，发送和检索描述消息的数据模型的模式。
模式注册中心为你的元数据提供服务层，并为所有事件实现数据治理和模式执行。它提供了一个RESTful接口来存储和检索你的Avro、JSON Schema和Protobuf模式。模式注册中心根据指定的主题名称策略存储所有模式的版本历史，提供多种兼容性设置，并允许根据配置的兼容性设置和对这些模式类型的扩展支持来演变模式。它提供了插入Kafka客户端的序列化器，处理以任何支持的格式发送的Kafka消息的模式存储和检索。
模式执行发生在客户端。此外，Confluent Platform和Confluent Cloud还提供服务器端模式验证。如果不正确的或恶意的客户端应用程序在没有使用客户端模式注册表集成的情况下向Kafka发送消息，后者是有帮助的。
API管理和数据共享
API管理是一个来自开放API世界的术语，它在HTTP/REST API的基础上加了一层，用于API的管理、监控和货币化。解决方案包括Apigee、MuleSoft Anypoint、Kong、IBM API Connect、TIBCO Mashery，以及更多。
API网关和API管理产品的特点
API网关和API管理工具提供了许多出色的功能。
- 用于创建和发布API的API门户网站
- 强制执行使用政策和控制访问
- 数据转换的技术特点
- 培养订户社区
- 收集和分析使用统计数据
- 业绩报告
- 货币化和计费
这些功能在任何数据流平台中都是不可用的，如Kafka、Pulsar、Kinesis等。另一方面，像MuleSoft或Kong这样的API工具并不是为处理大规模低延迟的实时数据而建立的。
API管理和数据流是互补的
因此，API管理和数据流是互补的，而不是竞争的!这篇博文"Apache Kafka和API管理/API网关--朋友、敌人还是敌人？"对此进行了探讨。
API == 大多数API管理产品和相关API网关的REST/HTTP。供应商开始整合Kafka API或AsyncAPI等事件标准，进入基于事件的架构。这是个好消息!
共享流数据需要一个流数据交换，而不是HTTP APIs
数据共享对于建立在微服务和数据网状结构等概念上的现代灵活的企业架构来说变得至关重要。实时数据胜过慢速数据。这不仅适用于应用程序，也适用于跨业务部门、组织、B2B、云、混合环境和其他场景的数据复制。因此，下一代的数据共享是建立在数据流之上的。
在许多数据流场景中，HTTP API的意义不大，尤其是当你预期有大量数据或需要低延迟时。因此，通过连接Kafka集群或使用流数据交换来实时共享数据是更好的方法。
这里我就不多说了。专门的博文"用Kafka进行实时数据共享的流式数据交换"探讨了这个想法，它的权衡，以及一些真实世界的例子。
不是非此即彼，而是在你的项目中结合Kafka和HTTP/REST!
各种用例都采用HTTP/REST和Apache Kafka作为管理平面或数据平面。这种组合在未来是不会消失的。
Confluent REST Proxy可用于与你最喜欢的客户端界面进行HTTP(S)通信。不管你是运行开源的Apache Kafka、Confluent平台还是Confluent云。请看 GitHub上的源代码或开始使用 直观的教程.
如何将数据流与请求-响应原则相结合？你如何结合HTTP和Kafka？你在使用什么代理？让我们 在LinkedIn上联系并讨论一下吧!
