Channel+Subscription VS Broker+Trigger

[tydra-wang]

I am new to knative eventing, and a little confused about so many concepts. What's the difference between "Channel + Subscription" model and "Broker + Trigger" model ?

The two pictures are so similar. The channel and subscription actually is a special case of broker and trigger without a filter? Does that mean I can always use broker instead of channel?

broker + trigger:

channel + subscription:

[evankanderson]

The two box diagrams are very similar, and we should probably try to differentiate them further. There are some capability differences between Brokers and Channels, but also some differences of intent:

Brokers

The core model for a Knative Broker is a content-based router. This is a fairly powerful assumption that we believe works well for many low- and medium-volume event driven architectures where you want to route events to destinations based on the contents of the message.

The general assumption in the broker model is that teams will have one Broker for event-handling, and events will be routed to different components based on the event attributes.

In service of this goal, Triggers do not have a spec.reply property -- the reply (if present) to a Trigger delivery is always delivered to the Broker that the Trigger is attached to.

Channels

The core model for a Knative Channel is a topology-based message pipe. This is a simple and direct construct which is widely implemented by messaging systems for integration purposes, and assumes a uniform fan-out model for subscribers to a channel. That is, every message sent to a channel is sent to each subscriber; if you want to deliver messages to different subscribers, you need to create multiple channels.

The core assumption of the channel-based model is that users will create multiple channels (or topics) for different types of messages, and that consumers will subscribe to these channels based on the type of content they wish to receive.

Use of the channel-based model requires one extra level of awareness and indirection when subscribing to a particular type of event -- first you need to determine what channel the event is being sent on, then you need to create a subscriber to route those events to your application. If a channel contains multiple message types, the subscriber will receive all the message types, even if they only want to receive one type.