许多API/微服务提供对包括Kafka主题在内的关键资源的访问。API/微服务消息使用定义API/微服务合同的OpenAPI规范进行验证。一旦微服务验证了消息，它就会发布到Kafka主题中，此时消息将(再次(根据Kafka的模式注册表进行验证。
问题是，有两个消息定义可以验证消息(OpenAPI规范和Kafka的模式注册表(，确保这两个消息的定义同步是一个挑战。
考虑到这一点，我有几个问题：
- 有没有办法将OpenAPI规范转换为Kafka模式注册表格式(反之亦然(
- 有没有一种方法可以让Kafka根据OpenAPI规范而不是注册表进行验证(可能不是一个很好的解决方案，因为应该使用原生的Kafka功能(
- 是否有一种方法允许API/微服务根据Kafka模式而不是OpenAPI规范来验证其消息(同样，可能不是一种好方法，因为OpenAPI规范是定义API消息的标准方法(
最后，以上哪一项最有意义。还有其他更好的选择吗？
在多次尝试解决这个问题后，我得出结论，有一种架构方法可以让JSON Schema、OpenAPI规范和Schema Registry很好地协同工作(我有一个原型可以工作，但它太复杂了，无法在这里显示(。以下是一般方法。。。
首先是支持我的方法的几个事实：
- 事实：OpenAPI(v3.1+(是JSON模式的超集；请求和响应定义100%符合JSON架构
- 事实：Schema Registry支持JSON Schema；JSON模式似乎是第一类公民：它们可以存储在模式注册表中或由模式注册表查询；库(虽然不容易找到(允许JSON Schema与Kafka(消费者、生产者、Confluent的KSQLDB(及其连接器一起工作
这意味着JSON模式需要是定义流经的消息的主要方式，而不是AVRO(我认为Kafka社区可能不会很喜欢这一点(。但是通过使用JSONSchema可以让OpenAPI、SchemaRegistry和JSONSchema一起玩得很好！
换句话说，一个广义的解决方案应该是：
- OpenAPI成为定义API的主要方式，这些API通常是事件流解决方案中的前端
- JSON模式定义OpenAPI请求/响应格式
- OpenAPI规范，只要少量的工具(有几种可用(，OpenAPI规范就可以从JSON模式部分组装/捆绑，所以现在OpenAPI和JSONN模式终于协调一致了
- 由于API请求/响应形式"；事件"；在事件管理系统中，定义独立于OpenAPI规范，JSON模式现在定义事件
- 最后，由于JSON模式在Schema Registry中，所以所有事件都是以Kafka友好的方式定义的，并且可以以任何正常的Kafka方式访问