作者 | Steef-Jan Wiggers
译者 | 刘雅梦
策划 | 丁晓昀
今年早些时候，云原生计算基金会（CNCF）宣布 了 CloudEvents 的毕业。CloudEvents 是一个旨在以标准化的方式来公开事件元数据的规范，这有助于确保跨平台、服务和系统的互操作性。
CNCF CloudEvents 是 IT 行业中唯一一个绑定到所有主要消息传递协议和编码的事件元数据模型。它允许在不抽象任何相应协议功能的情况下传输事件，于此同时，它还允许在不丢失元数据信息的情况下通过混合协议路由来移动事件。
CNCF CloudEvents 概述（来源：LinkedIn帖子）InfoQ 采访了 Clemens Vasters，他是微软消息传递和流处理的首席架构师，也是 Cloud Events 的推动者之一。
InfoQ：你能分享一些 Cloud Events 从诞生到被 CNCF 认可这整个历程的见解吗？
Clemens Vasters：该项目于 2017 年底在西雅图的一个会议室里启动，当时一群人由于谷歌的一项倡议而聚在一起，目的是就互操作事件的外观找到共同点。由于涉及到许多大公司的努力，围绕治理模式和范围的确定，出现了一些麻烦，但这些讨论也有助于建立信任并进入节奏。我们最终就两个核心原则达成了共识：首先，定义一个最小但有用的规则集。其次，不要发明任何已经发明了的东西——特别是，不要发明新的协议或编码；而是整合现有的东西。
一些工作组成员仍然对 SOAP 和 WS-* 标准化工作的兴衰以及随之而来的 SOAP 与 REST 之争记忆犹新。我们意识到，这在为事件数据定义信封（Envelope）模型的目标中有一些相似之处，并非常有意地避免了当时犯下的一些错误。SOAP/WS-* 押注于单一的数据编码（XML），并尝试将应用程序协议抽象为纯粹的传输通道，并在顶部添加新的语义，包括致命级别的端到端安全性。
在 CloudEvents 中，我们在所有这些情况下都做出了相反的决定。我们认为，用户应该能够用自己选择的编码来表达事件和事件数据，因此，我们有了一个最小的抽象类型系统。你可以将“在线”CloudEvent 表示为一个自包含的数据报，并按照你喜欢的方式进行编码，我们有 JSON、XML、Apache Avro、Google Protobuf 和 AMQP 编码的正式“格式”规范。我们将这些自包含的数据报称为“结构化事件”。或者，这是将 CloudEvents 支持添加到现有应用程序最平滑的方法，你可以将 CloudEvent 直接映射到现有应用协议的消息模型上，从而使 CloudEvents 元数据属性成为该协议的扩展头。我们有 HTTP、MQTT、AMQP、NATS 和 Kafka 绑定，还有更多特定于供应商的绑定。这意味着你可以利用你正在使用的协议 / 平台的所有优势和功能，同时仍然可以传输标准化的事件。
InfoQ：CloudEvents 规范的开发和设计遵循了哪些考虑因素和原则，特别是在确保诸如 MQTT、HTTP、Kafka 和 AMQP 等不同事件路由协议之间的互操作性方面？
Vasters：由于事件越来越多地通过多跳进行路由，从通过 MQTT 或 HTTP 发送事件的设备开始，然后复制到 Kafka，再移动到 AMQP 队列中，因此我们特别注意的是，事件始终可以从本地协议消息和结构化格式之间进行映射，而不会丢失信息或出现歧义。一些决定，如 CloudEvents 属性名称不允许使用分隔符，只允许使用小写拉丁字符，只是对所有这些选项的可互操作字符集进行充分分析的结果。
最终，我们获得了 CloudEvent 的元数据，并回答了以下问题：
它是什么样的？“类型”（type）
它来自哪里？“来源”（source）
它是关于什么的？“主题”（subject）
是哪个事件？“id”（id）
什么时候提出的?“时间”（time）
事件数据是如何编码的？“数据内容类型”（datacontenttype）
该内容类型的事件数据符合什么模式？“数据模式”（dataschema）
它是哪个版本的 CloudEvents？“规范版本”（specversion）
该规范的当前版本是“1.0”，在完成该版本后，我们现在将重点放在了该核心规范的扩展以及进一步的格式和绑定上。我们明确避免制作“2.0”，但要保护核心规范，使其成为每个人的可靠基础。
耐心和稳定性在所有制定标准的工作中都是必不可少的，CNCF 的认可证明了这种耐心是有回报的。
InfoQ：自从实现这一里程碑以来，业界对 CloudEvents 的接受程度如何？
Vasters：https://cloudevents.io/ 主页上的采用者库显示了一些采用 CloudEvents 的最知名的平台用户。在微软工作期间，我看到越来越多的企业客户甚至在联系我们讨论其解决方案的某些方面之前就已经将 CloudEvents 纳入到了他们的设计中，这是一个很好的迹象。对于微软来说，我可以说 CloudEvents 是我们通常会为所有平台上尚未发生的事件进行聚合的事件模型。
InfoQ：你如何看待 CloudEvents 在这些生态系统中的持续增长和演进？
Vasters：我认为 CloudEvents 是事件驱动应用程序的可互操作生态系统的基础。
这一过程的下一步是一个元数据模型，用于声明 CloudEvents 及其有效负载，并将这些 CloudEvent 声明与应用程序的端点关联起来。我们的目标是让事件生产者能够提前准确地声明它可能引发的事件，以便在其上构建应用程序。我们希望事件流变成“类型安全的”，并使消费者能够了解它们可以从流或主题中所预期的事件类型。我们的目标是为事件流创建一个类型安全级别，在该级别中为流行编程语言中的集合添加泛型和模板。
我们在这项名为“xRegistry”的工作上已经花了几年的时间，最终定义了一个非常通用的、版本感知的、可扩展的元数据注册表模型，作为分类的副产品，它具有一个显著的特征，即它在文档格式和面向资源的 API 之间提供了完全的对称性。在这里，与 CloudEvents 一样，我们定义了一个抽象模型。该 API 目前被规划到了 OpenAPI 中，文档格式用 JSON 和 Avro 模式表示。我们期望文档格式具有 XML 表示形式，并且以 RPC 绑定或其他方式来表达 API 是绝对可行的。
xRegistry 中定义的具体注册表是一个版本感知的模式注册表，可用于序列化和验证模式（JSON 模式、Avro 模式、Protos 等）；是一个消息元数据注册表，可以声明 CloudEvents 和 / 或 MQTT、AMQP、Kafka、NATS 和 HTTP 等消息的模板，并将其有效负载绑定到模式注册表中；也是一个端点注册表，可以对绑定到消息定义注册表的抽象和具体应用程序网络端点进行编录。我们有另一个注册表的草图，其中包含诸如 OpenAPI 和 AsyncAPI 之类的契约定义文档。
与我们在这个工作组中所做的所有事情一样，原则是只发明需要发明的东西，但要非常彻底地完成我们所选择做的工作。我们也非常慎重地考虑了我们的范围。我们认为，在我们能够准确描述单个事件通道之前，现在还不是标准化事件通道之间关系的时候。这就是为什么我们暂时不考虑更高级别的契约模型，它将说明如果你将事件发送到通道 A，通道 B 可能会产生什么。
我认为最终拥有一个正式的契约模型来反映跨多个支柱事件流的活动图会很酷。国际电信联盟在这方面有一些古老的现有技术，但我们还没有做到这一步。
LF AsyncAPI 工作从直接连接方的角度为事件流提供了一个简单的契约模型。我们用于验证规范工作的原型代码生成器可以从 xRegistry 中的端点或消息组定义生成模板化的 AsyncAPI 文档和 OpenAPI 文档。我们认为这些努力是相辅相成的，xRegistry 提供了一个基础。
作者介绍
Steef-Jan Wiggers 是 InfoQ 的高级云编辑之一，目前在荷兰 i8c 担任集成架构师。他目前的技术专长主要集中在集成平台实现、Azure DevOps 和 Azure 平台解决方案架构方面。Steef-Jan 经常在会议和用户组中发表演讲，也是 InfoQ 的撰稿人。此外，在过去的 14 年里，微软一直将他评为 Microsoft Azure MVP。
