事件
事件
事件是一个不可变的小段数据，记录了系统在特定时间内的特定行为，或状态的转变；
通过读取系统的事件流（序列），可以重建系统的运行历史；事件格式
1. 事件的格式完全可由开发者自行决定；
2. CNCF的CloudEvents规范至力于事件格式的标准化；
3. 目前，众多云服务商都开始支持该规范；事件驱动
不存在一个规范、严格的定义，任何使用事件通知范式（pub/sub）的系统都是事件驱动的系统；事件驱动分类
1. 响应式（reactive）：本质上是非同步性质的函数调用（或HTTP RESTful/RPC调用），即所谓的发布/订阅模型；
2. 流处理（stream processing）：密集式、面向数据式使用事件，订阅者通常是流处理器，它从事件流中提取状态，并将状态传递给相关方；事件源 (Event Sourcing)
事件数据的持久化模式；
通常基于事件日志保存不可变的事件信息；事件驱动架构（EDA）
EDA架构简介
事件驱动的通用架构中，主要由三个组件组成：
1. 生产者：事件消息的生成方，或消息格式转换者
2. 消费者：负责接收、解析和处理事件
3. 事件总线：负责存储事件，从而将生产者和消费者解耦单体架构
基于库调用模式开发的大型软件系统中，随着代码模块及代码库的膨胀，程序的执行路径将不可避免地“迷宫化”，直至难以维护；微服务架构
建立在HTTP RESTful/RPC之上的微服务架构，借助于迫使开发人员针对远程服务的接口进行编程，克服了程序内部调用路径不可维护这一潜在问题；代价是，不得不在服务间维护复杂的依赖关系，因而执行路径依然存在；微服务架构确实大大降低了单个团队需要管理的代码量，只不过，这是通过将一些责任转移给了其他服务实现的；程序与程序之间需要高度规范的接口契约；事件驱动架构
应用程序在任务完成时生成事件（一个带有上下文数据的消息块），而非协调另一个程序代码的执行:
1. 事件发布者基本不关心下一步会发生什么，而是由消息系统及消息传递机制来决定，通常是消息队列或者流系统一类的解决方案;
2. 消息传递机制将事件同时从发布者传递给数量不定的订阅者，再由其完成事件处理;系统的各部分之间没有依赖关系，也不需要规范的编程接口，尽管发布者和订阅者仍然需要在一定程度上遵循事件的预设模式，但这种契约非常灵活；
1. 发布者无须关心订阅者是否使用，以及如何使用自己发布的事件；
2. 这消除了执行路径，应用程序和服务的可扩展性大大增强，系统随时能够以订阅者的方式添加或删除代码块；消息队列系统可以承载短时间内的海量信息，这为IoT时代的应用架构提供了坚实的支撑；Knative Eventing 概述
Knative Eventing 是 API 的集合，能够在应用程序中使用事件驱动的架构。可以使用这些 API 创建将事件从事件生成者（称为源）路由到接收事件的事件使用者（称为接收器）的组件。接收器还可以配置为通过发送响应事件来响应 HTTP 请求。Knative Eventing 是一个独立平台，为各种类型的工作负载提供支持，包括标准 Kubernetes 服务和 Knative Serving Services。Knative Eventing 使用标准 HTTP POST 请求在事件生成器和接收器之间发送和接收事件。这些事件符合 CloudEvents 规范，可以使用任何编程语言创建、解析、发送和接收事件。Knative Eventing 组件是松散耦合的，可以相互独立开发和部署。任何生产者都可以在有活动的事件消费者正在侦听这些事件之前生成事件。任何事件消费者都可以在创建事件的生产者之前表达对一类事件的订阅。支持的 Knative Eventing 用例示例：
发布事件而不创建消费者。您可以将事件作为 HTTP POST 发送到代理，并使用绑定将目标配置与生成事件的应用程序解耦。
使用事件而不创建发布者。您可以使用触发器根据事件属性使用来自代理的事件。应用程序以 HTTP POST 形式接收事件。Knative Eventing 术语
Event Source
事件源是由开发人员或集群管理员创建的 Kubernetes 自定义资源 (CR)，充当事件生产者和事件接收器之间的链接。接收器可以是 k8s 服务，包括 Knative Services、Channel 或从事件源接收事件的 Broker。Channels
事件管道模型，负责在Channel及其各Subscription之间格式化和路由事件Subscriptions
创建通道和接收器后，您可以创建订阅以启用事件传递。Subscription 由 Subscription 对象组成，该对象指定要向其传递事件的 Channel 和 Sink（也称为订阅者）。Event registry
Knative Eventing 定义了一个 EventType 对象，使消费者更容易发现他们可以从 Brokers 或 Channels 消费的事件类型。Event Registry即为存储着EventType的集合，这些EventType含有Consumer创建Trigger的所有必要信息。Broker和Trigger
1. 事件网格（mesh）模型，Producer把事件发往Broker，再由Broker统一经Trigger发往各Consumer；
2. 各Consumer利用Trigger向Broker订阅其感兴趣的事件；sinks
创建事件源时，您可以指定事件从源发送到的接收器。接收器是可寻址或可调用资源，可以从其他资源接收传入事件。Knative Services、Channels 和 Brokers 都是接收器的示例。可寻址对象接收并确认通过 HTTP 传递到其 status.address.url 字段中定义的地址的事件。可调用对象能够接收通过 HTTP 传递的事件并转换该事件，在 HTTP 响应中返回 0 或 1 个新事件。这些返回的事件可以以与处理来自外部事件源的事件相同的方式被进一步处理。Knative Eventing 组件
Knative Eventing具有四个最基本的组件：Sources、Brokers、Triggers 和 Sinks1. 事件会从Source发送至Sink；
2. Sink是能够接收传入的事件可寻址（Addressable）或可调用（Callable）资源。Knative Service、Channel和Broker都可用作SinkKnative Eventing 网格
Event Mesh是动态基础设施，旨在简化从发送者到接收者的事件分发。与 Apache Kafka 或 RabbitMQ 等传统消息通道架构类似，Event Mesh提供异步（存储转发）消息传递，从而可以及时解耦发送者和接收者。与传统的基于消息通道的集成模式不同，Event Mesh还通过将发送者和接收者与底层事件传输基础设施（可能是 Kafka、RabbitMQ 或云提供商基础设施等联合解决方案集）解耦来简化发送者和接收者的路由问题。网格通过互连的事件代理网络将事件从生产者传输到消费者跨任何环境，甚至在云之间以无缝且松散耦合的方式。在Event Mesh中，生产应用程序和消费应用程序都不需要实现事件路由或订阅管理。事件生产者可以将所有事件发布到网格，网格可以将事件路由到感兴趣的订阅者，而不需要应用程序将事件细分到通道。事件使用者可以使用网格配置来使用细粒度过滤器表达式接收感兴趣的事件，而不需要实现多个订阅和应用程序级事件过滤来选择感兴趣的事件。事件序列化和反序列化可以由语言本机库处理，无需实现更重量级的路由和过滤。
Broker API 为事件入口提供了一个可发现的端点，而 Trigger API 则通过其事件过滤和交付功能完善了该产品。通过这些 API，Knative Eventing 提供了Event Mesh。Event Mesh是使用 Broker 和 Trigger API 定义的，用于事件的入口和出口。Knative Eventing 使多个资源能够通过称为“duck typing”的部分架构模式参与Event Mesh。duck typing允许多种资源类型宣传通用功能，例如“可以在 URL 接收事件”或“可以将事件传递到目的地”。Knative Eventing 使用这些功能来提供可互操作的源池，用于将事件发送到代理并作为触发器路由事件的目的地。值得注意的是，事件源和接收器是事件生态系统的支持组件，但不是事件网格的直接一部分。虽然不是事件网格的一部分，但这些生态系统组件补充了网格并受益于duck typing API ( Callable/ Addressable)，以便与“事件网格”顺利集成或连接。Knative Eventing API 类型
Events Ingress
支持连接事件发送者：Source duck 类型和 SinkBinding 支持轻松配置应用程序以将事件传递给 Broker。即使没有安装任何源，应用程序也可以提交事件并使用事件。Event routing
Broker 和 Trigger 对象支持定义网格和事件路由。请注意，Broker 与可寻址事件目标的定义相匹配，因此可以将事件从一个集群中的 Broker 中继到另一个集群中的 Broker。类似地，Trigger 使用与许多源相同的 Deliverable duck 类型，因此很容易替换事件网格来直接传递事件。Event egress
Deliverable 合约支持指定裸 URL 或引用实现 Addressable 接口（具有 status.address.url）的 Kubernetes 对象作为目的地。所有事件目的地（“接收器”）必须实现 CloudEvents 交付规范，但不一定需要实现任何 Kubernetes 行为——URL 引用的裸虚拟机是可接受的事件出口。Knative Event 处理流程
1. Event Source：事件源，即生产者抽象，负责从真正的事件源导入事件至Eventing拓扑中
2. Event Type：事件类型，它们定义于Event Registry中
3. Flow：事件处理流，可简单地手工定义流，也可使用专用的API进行定义
4. Event Sinks：能接收Event的可寻址（Addressable）或可调用（Callable）资源，例如KService等Knative Event 事件传递模式
Knative Eventing中的Sink（接收事件）的用例主要有Knative Service、Channels和Brokers三种。Sources to Sink
1. 单一Sink模式，事件接收过程中不存在排队和过滤等操作；
2. Event Source的职责仅是传递消息，且无需等待Sink响应；
3. fire and forget；Channels and Subscriptions
1. Event Source将事件发往Channel；
2. Channel可以有一到多个Subscription（即Sink）；
3. Channel中的每个事件都被格式化Cloud Event并发送至各Subscription；
4. 不支持消息过滤机制；Brokers and Triggers (推荐模式)
1. 功能类似于Channel和Subscription模式，但支持消息过滤机制；
2. 事件过滤机制允许Subscription使用基于事件属性的条件表达式（Trigger）筛选感兴趣的事件；
3. Trigger负责订阅Broker，并对Broker上的消息进行过滤；
4. Trigger将消息传递给感兴趣的Subscription之前，还需要负责完成消息的格式化；Knative Event API 群组
sources.knative.dev/v1
声明式配置Event Source的API，提供了四个开箱即用的Source。1. ApiServerSource：监听Kubernetes API事件
2. ContainerSource：在特定的容器中发出针对Sink的事件
3. PingSource：以周期性任务（cron）的方式生具有固定负载的事件
4. SinkBinding：链接任何可寻址的Kubernetes资源，以接收来自可能产生事件的任何其他Kubernetes资源的事件eventing.knative.dev/v1
声明式配置“事件网格模型”的API。1. Broker
2. Triggereventing.knative.dev/v1beta2
1. EventTypemessaging.knative.dev/v1
声明式配置“事件管道模型”的API。1. Channel
2. Subscriptionflows.knative.dev/v1
事件流模型，即事件是以并行还是串行的被多个函数处理。1. Parallel
2. Sequence参考文档
https://knative.dev/docs/eventing/