当涉及到它支持的不同事件传递方法时， Knative Eventing文档有点混乱。它讨论了事件代理和触发器， 还讨论了源、服务、渠道和订阅。什么时候用什么？目前还不清楚。让我们分解一下。交货方式Knative 中有 3 种不同的方法：
- 简单的交付
- 带有可选回复的复杂交付
- 经纪人和触发器交付
代理和触发器交付是您大部分时间应该关心的。然而，简单和复杂的交付已经在 Knative 中出现了一段时间，并且仍然很高兴知道幕后发生的事情。简单的交付
在简单交付中，事件源将消息直接发送到服务。这是 1:1，根本没有交货保证：
例如，这是一个 CronJobSource，它在给定的 cron 计划上触发事件，将消息直接发送到 Knative 服务：
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: source
spec:
schedule: "* * * * *"
data: '{"message": "Hello world from cron!"}'
sink:
apiVersion: serving.knative.dev/v1
kind: Service
name: service
|
您可以在我的 Knative 教程中看到一个完整的简单交付示例。
复杂的交付
复杂的交付允许通过频道和订阅的 1:n 扇出保证交付。
源向通道发送消息。它可以是内存中的通道，也可以是更持久的通道，例如 Kafka 通道：
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: source
spec:
schedule: "* * * * *"
data: '{"message": "Hello world from cron!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
name: channel
|
然后，服务通过订阅连接到通道：
apiVersion: messaging.knative.dev/v1alpha1
kind: Subscription
metadata:
name: subscription1
spec:
channel:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
name: channel
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: service1
|
复杂的交付还允许服务使用其他事件来回复事件：
在这种情况下，Service2 用另一个事件回复传入的事件，并通过另一个通道和订阅将其路由到 Service3。回复被定义为订阅的一部分：
apiVersion: messaging.knative.dev/v1alpha1
kind: Subscription
metadata:
name: subscription2
spec:
channel:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
name: channel1
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: service2
reply:
ref:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
name: channel2
|
您可以在我的 Knative 教程中看到完整的复杂交付示例和带回复的复杂交付示例。
Broker和触发器交付
复杂的交付模型有效，但很难维护多个频道、订阅和回复。它也没有过滤的概念，因此服务必须自己过滤所有消息。一个更简单的模型是代理和触发器。Broker 将频道、回复和过滤功能组合到一个资源中。触发器提供所有事件的声明式过滤。在这个方法中，前面的例子变成了这样：
代理被注入到服务和源的命名空间中。Source 向代理发送事件：
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: source
spec:
schedule: "* * * * *"
data: '{"message": "Hello world from cron!"}'
sink:
apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
name: default
|
Broker由通道支持。服务通过触发器注册对特定事件类型的兴趣：
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: trigger1
spec:
filter:
attributes:
type: dev.knative.cronjob.event
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: service1
|
在幕后，触发器创建订阅。任何服务都可以回复传入事件。通过代理返回的回复事件和对该类型事件感兴趣的服务获取该事件：
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: trigger3
spec:
filter:
attributes:
type: dev.knative.samples.hifromknative
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: service3
|
您可以在我的 Knative 教程中看到完整的代理和触发交付示例。
正如我之前提到的，您通常只关心 Knative Eventing 中的 Broker 和 Trigger，但我希望这篇文章能够阐明不同的交付方法以及在封面下会发生什么。