CloudEvent/KnativeEventing/RabbitmqBroker️实践总结

CloudEvent规范

CouldEvent（https://cloudevents.io/）是CNCF推出的一个以通用格式来描述事件数据的规范，通常用于分布式系统，以允许服务在开发过程中松耦合，独立部署，方便之后连接以创建新的应用程序。

type 属性应该是消费者识别他们收到的事件类型的主要方式。 这可以通过订阅特定的 CloudEvent 类型来实现，或者通过本地过滤所有收到的 CloudEvent实现。 但确定了 CloudEvent 类型的消费者通常会期望该类型的数据 仅以向后兼容的方式更改，除非另有明确说明。 “向后兼容”的确切含义将因数据内容类型而异。

id 属性是一个在同一事件源下所有事件中用来标识事件唯一的值 （其中每个事件源由其 CloudEvents source属性唯一标识）。 虽然id使用的确切值是生产者定义的， 但必须要确保来自单个事件源的 CloudEvents 消费者不会有两个事件共享相同的 id 值。 我们在这里隐含地声明没有两个事件将共享相同的 id 值，但不提供关于如何保证这一点的解释， 因为这超出了本规范的范围。 唯一的例外是如果支持事件的重播，在这些情况下，可以使用 id 来检测这一点。

CloudEvent提供SDK进行event的收发https://github.com/cloudevents

EventMesh

https://knative.dev/docs/eventing/event-mesh/

https://github.com/knative-extensions/eventing-rabbitmq

EventMesh是一种简化分布式事件发送和订阅的动态基础设施，相较于传统消息分发架构，例如kafka、Rabbitmq，EventMesh额外的简化了消息发布和订阅这对基础设施软件的耦合，消息发布者和订阅者的实现更加简化，事件发布者和订阅者无需实现消息路由和订阅管理。Knative Eventing是一种Event Mesh的实现，并遵循CloudEvent规范。

Eventing Rabbitmq Broker是Knative Eventing Broke-Trigger模型的具体实现，通过Rabbitmq作为其Broker后端。

完整部署一套Eventing Rabbitmq包含以下组件

Knatvie Eventing (v1.15.1) https://knative.dev/docs/install

Eventing Rabbitmq (v1.15.0) https://github.com/knative-extensions/eventing-rabbitmq

Rabbitmq Operator & Topology Operator

https://github.com/rabbitmq/cluster-operator

https://github.com/rabbitmq/messaging-topology-operator

Certmanager https://cert-manager.io/docs/installation/helm/

样例如下：

创建 Rabbitmq Cluster：

创建Knative Eventing Broker

DEMO

创建订阅

订阅应用为通过cloudevent SDK 接受 event并打印，代码 https://github.com/knative/eventing/tree/main/cmd/event_display

发送cloudevent

向broker ingress 发送event，集群内可直接使用service name