Knative Eventing是Knative平台的通用事件驱动组件，它实现了云原生应用开发对事件驱动的通用需求，同时还提供了一组可组合的原语，实现了事件源和消费者之间的延迟绑定。
Knative Eventing支持多种使用模式。现有的事件驱动组件支持以下3种使用场景。
1）想要发布事件，不关心谁来消费事件。
使用HTTP POST方式将事件发送给Broker，SinkBinding将目标配置与应用程序解耦。
2）想要消费特定类型事件，不关心事件是如何发布的。
使用Trigger基于CloudEvent属性消费来自Broker的事件。应用程序通过HTTP POST来接收事件。
3）想要通过一系列步骤来转换事件。
使用通道（Channel）和订阅（Subscription）来定义复杂的消息传递拓扑。对于简单的管道，Sequence自动在每个阶段构建通道和订阅。由于系统是模块化设计，它可以以各种方式组合搭配使用这些组件。此外，Knative还支持一些附加模式，诸如事件的并行（Parallel）扇出、从通道和代理路由事件响应。
Eventing的架构设计
Eventing组件遵循Knative的标准化、可替代、松散组合、不绑定的总体设计原则，采用了CloudEvent事件格式标准，还对事件源、消费者、通道进行了抽象。
总体设计目标
Knative Eventing围绕着以下目标而设计。
1）Knative Eventing服务是松散耦合的，可以独立开发和部署，并且可以跨多种平台（例如Kubernetes、VMS、SaaS或FaaS）。
2）事件生产者和事件消费者是独立存在的。任何生产者（或事件源）可以生成事件而不依赖消费者。任何事件消费者可以在事件创建前订阅某个或某类事件。
3）其他服务可以连接到事件系统，这些服务可以完成两个功能：在不修改事件生产者或事件消费者的情况下创建新应用；从生产者那里选择并定位特定事件子集。
4）保障跨服务的互操作性。Knative Eventing遵循CloudEvent标准。
Eventing的基础概念
1.事件消费者
为了能够将事件交付到多种类型的服务，Knative Eventing定义了两个被多个Kubernetes资源实现的通用接口：Addressable与Callable。
1）Addressable接口能够接收和确认通过HTTP传递到指定地址的事件，这个地址在status.address.url中定义。
2）Callable接口能够接收通过HTTP传递的事件，并且转换事件，在HTTP响应中返回0或1个新事件。这些返回的事件可以以处理外部事件源同样的方式被进一步处理。
2.代理与触发器
为了更容易地过滤事件，Knative Eventing定义了代理（Broker）和触发器（Trigger）对象。
代理提供了一个可以通过属性选择的事件桶。它接收并转发事件到由一个或多个匹配的Trigger所定义的订阅者中。
触发器描述了一个基于事件属性的过滤器，该事件将被传递给可寻址对象。你可以按需创建多个触发器。
3.事件注册表
Knative Eventing定义了一个事件类型（EventType）对象，用以简化消费者发现可通过代理消费的事件类型。
事件注册表（Registry）是事件类型的集合。存储在注册表中的事件类型包含所有必要的信息，供消费者创建触发器而不需要依靠其他外部的机制。
4.事件通道与订阅
Knative Eventing还定义了一个事件转发和持久化层，叫作通道（Channel）。每个通道是一个独立的Kubernetes自定义资源。我们可以使用订阅（Subscription）将事件传递给服务或转发给其他通道。集群中消息的传递方式可以基于需求的变化而改变。事件可以通过in-memory实现的通道来处理，也可以使用Apache Kafka或NATS Streaming来持久化。
5.事件流控制
在某些情况下，你可能希望使用一组需要协作的服务。对于这种场景，Knative Eventing提供了两个附加资源：Sequence提供了定义一个有序服务列表的方法；Parallel提供了一个定义事件分支列表的方法。
6.事件源
事件源（Source）是由开发人员或集群管理员创建的Kubernetes定制资源（Custom Resource，CR），用于连接事件生产者和事件接收器。事件接收器可以是Kubernetes服务、Knative服务、通道或一个事件的代理。
每个事件源是一个独立的Kubernetes定制资源，它允许每种事件源类型定义必要的参数来实例化。所有的事件源应该是事件源类型的一部分，你可以使用kubectl get sources命令列出现存的事件源。
事件传递方式
当前，Eventing架构支持3种事件传递方式。
1）简单事件传递：直接从事件源到单个服务。在这个场景中，如果目标服务不可用，事件源负责重试或对事件排队，如下所示。
事件源到单个服务传递方式
2）通过通道与订阅方式传递事件：一个事件源或服务的响应使用通道和订阅扇出模式传递到多个端点。在这个场景中，通道要确保消息被传递到目标，并且目标服务不可用时应缓存事件，如下所示。
通过通道与订阅方式传递事件
3）通过Broker/Trigger方式传递事件：该方式与订阅方式类似，不同之处是它支持事件过滤。事件过滤是一种事件的筛选方法，该方法允许订阅者对流入Broker中的特定消息表示感兴趣。
对于每个代理，Knative Eventing会隐式地创建一个通道。Trigger会订阅Broker，并将过滤器作用到消息上。过滤器通过CloudEvent消息的属性过滤相应的消息，然后将消息传递给感兴趣的订阅者，如下所示。
通过Broker/Trigger方式传递事件
CloudEvent
在详细介绍Knative Eventing组件之前，需要先了解一下当前最重要的通用事件数据规范CloudEvent。作为Knative Eventing采用的标准事件格式，CloudEvent极大地推动了Serverless事件驱动基础设施的标准化。
CloudEvent简介
事件无处不在，然而事件生产者描述事件的方式各不相同。由于缺少通用方式来描述事件，开发人员不得不为每个事件源编写新的事件处理逻辑。没有通用的事件格式意味着没有通用的库、工具和基础设施来跨环境传递事件数据。事件数据的可移植性和生产效率受到了阻碍。
CloudEvent是一个采用通用格式描述事件数据的规范，提供了事件在跨服务、平台和系统之间的互操作性。事件格式指定如何使用某些编码格式序列化CloudEvent。支持这些编码并兼容CloudEvent的实现必须遵守相应事件格式中指定的编码规则。所有实现都必须支持JSON格式。
当前，CloudEvent还处于活跃的发展过程中，已经广泛引起行业兴趣，包括主流的云厂商和热门的SaaS厂商。
术语
下图是对CloudEvent中部分术语关系的描述。
CloudEvent术语
1）发生（Occurrence）：在软件系统运行期间捕获的事实的陈述。这可能是由于系统发出一个信号或观察到一个信号后发生的状态变化、计时器时间变化或任何其他值得注意的活动。例如，由于电池电量不足或虚拟机将要执行重启计划，设备可能会进入警报状态。
2）事件（Event）：发生（Occurrence）及其上下文的数据记录。事件从事件生产者路由到感兴趣的事件消费者。事件路由可以基于事件中包含的信息，但是不会标识特定的路由目的地。事件包含两种类型的信息：事件数据和内容元数据。一次发生可能会产生多个事件。
3）生产者（Producer）：创建描述CloudEvent数据结构的特定实例、进程或设备。
4）源（Source）：事件出现时的上下文信息。在分布式系统中，事件源可能由多个生产者组成。如果事件源不知道CloudEvent，外部生产者将会代表事件源来创建CloudEvent。
5）消费者（Consumer）：接收事件并对其采取行动。消费者使用上下文和数据执行某些逻辑，这也可能导致新的事件发生。
6）中介（Intermediary）：接收包含事件的消息，目的是将事件转发给下一个接收者。该接收者可能是另一个中介或消费者。中介的典型任务是根据上下文中的信息将事件路由到接收者。
7）上下文（Context）：元数据封装在“Context Attribute”（上下文属性）中。工具和应用程序代码可以使用此信息来识别事件与系统或事件与其他事件的关系。
8）数据（Data）：有关事件特定域的信息（即有效负载）。这可能包括发生事件的信息、已更改数据的详细信息。
9）事件格式（Event Format）：给出了将CloudEvent序列化为字节序列的方法。独立事件格式（诸如JSON格式）指定了独立于任何协议或存储介质的序列化方法。协议绑定可以定义协议依赖的格式。
10）消息（Message）：事件是以消息为载体从事件源传递到目的地的。
11）协议（Protocol）：通过各种行业标准协议（例如HTTP、AMQP、MQTT、SMTP）、开源协议（例如Kafka、NATS）或特定于平台/供应商的协议（例如AWS Kinesis、Azure Event Grid）传递消息。
12）协议绑定（Protocol Binding）：描述了如何通过给定协议发送和接收事件。协议绑定可以选择使用一个事件格式将事件直接映射到传输封包体，也可以为封包体提供附加格式和结构。例如，使用围绕一个结构化模式的消息打包，或者将几个消息一起批量打包进一个传输封包体。
上下文属性
符合此规范的CloudEvent必须包含Required的上下文属性（Context Attribute），并且可以包括一个或多个Optional上下文属性。
这些属性描述了事件，可以独立于事件数据进行序列化。这样，我们就可以在目的地对它们进行检查，而不必对事件数据进行反序列化。
1.属性命名规范
CloudEvent规范定义了到各种协议和编码的映射，随附的CloudEvent SDK提供了对各种运行时和语言的支持。其中，一些语言和运行时处理元数据元素区分大小写，并且单个CloudEvent可能会通过涉及协议、编码和运行时混合的多个跃点进行路由。因此，CloudEvent规范限制了所有属性的可用字符集，避免区分大小写问题或通用语言中的标识符与允许字符集冲突问题。
CloudEvent属性名称必须由ASCII字符集的小写字母（a至z）或数字（0至9）组成，并且必须以小写字母开头。属性名称应简洁、方便对应，长度不得超过20个字符。
2.类型系统
以下抽象数据类型可用于属性。每一个类型都可以通过不同的事件格式和协议元数据字段来表示。CloudEvent规范为所有实现必须支持的类型定义了字符串编码规范。
1）Boolean：布尔值为true或false。
2）Integer：范围在-2 147 483 648到+2 147 483 647之间的整数。
3）String：允许的Unicode字符序列。
4）Binary：字节序列。
5）URI：绝对统一资源标识符。
6）URI-reference：统一资源标识符引用。
7）Timestamp：公历的日期和时间表达式。
3.Required属性
以下属性必须出现在所有CloudEvent中。
1）id：String类型。该属性用来表示事件的标识。生产者要确保source和id对每个特定事件是唯一的。如果事件被重复发送（例如由于网络错误），它可能具有相同的id。消费者可以假定具有相同source和id的事件是重复的。
2）source：URI-reference类型。该属性用来标识一个发生事件的上下文。通常，这包括诸如事件源的类型、发布事件的组织或事件的进程等信息。事件生产者定义了URI中编码数据背后的确切语法和语义。应用程序可以为每个不同的生产者分配唯一的source，没有生产者有相同的source，唯一id的生成会更加容易。应用程序可以使用UUID、URN、DNS Authority或特定于应用程序的方案来创建唯一的source标识符。
3）specversion：String类型。该属性用来表示事件使用的CloudEvent规范的版本。
4）type：String类型。该属性描述了初始发生相关事件的类型。通常，此属性用于描述路由、可观察性、策略执行等。此属性格式由生产者定义，可以包含类型的版本等信息。
4.Optional属性
以下属性是可选的，可以出现在CloudEvent规范中。
1）datacontenttype：String类型。该属性用来表示data值的内容类型。该属性使data可以承载任何类型的内容，格式和编码可与所选事件的格式和编码不同。例如，使用JSON封包格式渲染的事件可以在data中携带XML的有效负载，并且通过将此属性设置为application/xml来通知使用者。
2）dataschema：URI类型。该属性用来表示data遵循的模式。
3）subject：String类型。该属性用来表示事件生产者的上下文中描述的事件主题。在发布-订阅场景中，订阅者订阅源发出的事件，如果源的上下文中具有内部子结构，仅通过事件源标识符不足以作为任何特定事件的限定符，就需要引入事件主题。在上下文的元数据中，指定事件的主题在中间件无法解释数据内容的订阅在过滤场景中特别有用。
4）time：Timestamp类型。该属性用来表示发生时的时间戳。如果无法确定发生时间，生产者可以将此属性设置为其他时间（诸如当前时间）。事件源相同的生产者在时间规则上必须要保持一致，它们要么使用实际发生时间，要么使用相同的算法来确定这个值。
5.扩展上下文属性
CloudEvent可以包含任意数量具有不同名称的附加上下文属性，这些属性称为扩展属性。扩展属性必须遵循相同的命名约定，并使用与标准属性相同的类型系统。扩展属性在CloudEvent规范中没有预先定义，允许外部系统将元数据附加到事件，就像HTTP自定义头信息一样。
扩展属性始终根据绑定规则进行序列化，就像标准属性一样。为了与非CloudEvent系统进行交互，此规范不会阻止将事件属性值复制到消息的其他部分。如果这些复制的值与Cloud Event序列化值不同，扩展规范应该明确接收方将如何解释该消息。
扩展定义应该全面定义属性的所有方面，包括名称、类型、语义含义以及可能的值。新的扩展定义应该使用描述准确的名称，避免与其他扩展发生命名冲突。特别注意，扩展的作者应该检查已知扩展集的文档，这不仅是为了避免潜在的命名冲突，还为了发现潜在感兴趣的扩展。
许多协议支持发送者包含附加元数据的能力，例如使用HTTP头信息的方式。虽然未强制要求CloudEvents接收方处理并传递它们，但强烈建议接收方通过某种机制实现这样的处理，这可以使其明确它们不是CloudEvent元数据。
这是一个演示附加属性需求的示例。在许多物联网和企业使用场景中，事件可以在Serverless应用程序中使用。该应用程序跨多种事件类型执行操作。为了支持这类使用场景，事件生产者需要向上下文属性添加其他标识属性，以便事件消费者使用这些属性将这个事件与其他事件相关联。如果此类身份属性恰好是事件数据的一部分，事件生产者还需要将身份属性添加到上下文属性中，这样事件消费者无须解码和检查事件数据就可以轻松访问此信息。此类身份属性还可用于帮助中间网关确定如何路由事件。
标签：CloudEvent,Eventing,事件驱动,Knative,上下文,事件,属性 From： https://www.cnblogs.com/muzinan110/p/17067006.html