确保与 Kafka Schema 和 OpenAPI 规范的一致性答案

【问题标题】：Ensuring consistency with Kafka Schema and OpenAPI specification确保与 Kafka Schema 和 OpenAPI 规范的一致性
【发布时间】：2021-03-27 05:34:45
【问题描述】：

许多 API/微服务提供对关键资源的访问，包括 Kafka 主题。 API/微服务消息使用定义 API/微服务合同的 OpenAPI 规范进行验证。微服务验证消息后，将其发布到 Kafka 主题，此时（再次）根据 Kafka 的模式注册表验证消息。

问题在于验证消息的依据有两个消息定义（OpenAPI 规范和 Kafka 的模式注册表），确保两个消息定义同步是一个挑战。

考虑到这一点，我有几个问题：

有没有办法将 OpenAPI 规范转换为 Kafka 架构注册表格式（反之亦然）？
有没有办法让 Kafka 验证 OpenAPI 规范而不是注册表（可能不是一个很好的解决方案，因为应该使用原生 Kafka 功能）？
有没有办法让 API/微服务根据 Kafka 架构而不是 OpenAPI 规范验证其消息（同样，这可能不是一个好方法，因为 OpenAPI 规范是为 API 定义消息的标准方法）？

最后，以上哪个最有意义。还有其他更好的选择吗？

【问题讨论】：

不清楚您所说的“Kafka 模式注册表格式”是什么意思... 新版本的注册表接受 JSON 模式（这是 openapi 使用的，对吗？）。此外，“原生 Kafka”的架构概念为零，因此您可以对消息做任何事情，但要权衡延迟
我应该更具体一点：Confluent 的 Kafka 发行版有一个模式注册表。可以定义模式并将其存储在注册表中。然后使用这些模式来验证消息。有两个属性允许此功能：“confluent.value.schema.validation”和“confluent.key.schema.validation”。当设置为“true”时，它们允许消息验证，如果消息（或一批消息中的任何一条消息）无效，则丢弃该消息/批次。关于第二点，我同意存在延迟考虑，但消息验证（在我的环境中）具有更高的优先级。
我知道它的作用。更具体地说-您期望模式的“格式”是什么？特别是，Schema Registry 有一个用于定义您自己的格式的可插入接口，您可以检查源代码以了解现有 Avro/Protobuf/JSON 序列化程序如何操作/验证消息，但这是基于每个客户端，而不是每个主题或集群范围内的整体
我希望采用行业标准的 OpenAPI 规范作为格式。基本原理：API/微服务和 Kafka 经常结合使用。因此，API/微服务和 Kafka 之间的统一消息定义和安全模型是理想的。 API/微服务使用 OpenAPI 规范来定义/验证消息和安全定义（范围），它允许基于每个主题的细粒度访问控制：通过使用 OpenAPI 规范（每个主题一个），我不仅可以一致地验证消息之间API/微服务和 Kafka，但我也得到了一个统一的安全模型。
OpenAPI / HTTP 更多地围绕同步请求/响应主体。例如，您可以使用swaggergen 创建模型，然后围绕Kafka 主题传递这些模型。但是，您可能还想查看AsyncAPI

标签： apache-kafka microservices openapi confluent-schema-registry

【解决方案1】：

在多次尝试解决这个问题后，我得出结论，有一种架构方法可以让 JSON Schema、OpenAPI 规范和 Schema Registry 很好地协同工作（我有一个可以工作的原型，但这里展示太复杂了） .这是一般方法...

首先支持我的方法的一些事实：

事实：OpenAPI (v3.1+) 是 JSON Schema 的超集；请求和响应定义 100% 符合 JSON Schema
事实：Schema Registry 支持 JSON Schema； JSON Schema 似乎是一等公民：它们可以在 Schema Registry 中存储和查询；并且有一些库（虽然不容易找到）允许 JSON Schema 与 Kafka（消费者、生产者、KSQLDB for Confluent）及其连接器一起使用

这意味着 JSON Schema 需要成为定义流经消息的主要方式，而不是 AVRO（我认为 Kafka 社区可能不会非常喜欢这点）。但是通过使用 JSON Schema 可以让 OpenAPI、Schema Registry 和 JSON Schema 一起玩得很好！

换句话说，通用解决方案将具有：

OpenAPI 成为定义 API 的主要方式，这些 API 通常是事件流解决方案的前端
JSON 模式定义 OpenAPI 请求/响应格式
OpenAPI 规范，使用少量工具（有几个可用），OpenAPI 规范可以从 JSON Schema 部分组装/捆绑，所以现在 OpenAPI 和 JSONN Schema 终于协调一致了
由于 API 请求/响应在事件管理系统中形成“事件”，并且定义独立于 OpenAPI 规范，因此 JSON 模式现在定义事件
最后，由于 JSON Schema 位于 Schema Registry 中，所有事件都以对 Kafka 友好的方式定义，并可通过任何普通 Kafka 方式访问

【讨论】：