mirror of https://github.com/knative/docs.git
112 lines
3.5 KiB
Markdown
112 lines
3.5 KiB
Markdown
## Use Case
|
||
The broker and trigger model is useful for complex event delivery topologies like N:M:Z, i.e. there are a multitude of Sources sending events, Functions
|
||
consuming/transforming which are then processed by even more functions and so on. It can get a bit unwieldy to keep track of which Channel is having which events. Also, sometimes you might only want to
|
||
consume specific types of events. You would have to receive all the events, and throw out the ones you’re not interested in. To make these kinds of interactions easier and allow the
|
||
user to only focus on declaring which events they are interested in and where to send them is an easier way to reason about them. This is where Broker and Trigger are meant
|
||
to provide a straightforward user experience.
|
||
|
||
### Broker
|
||
Producers POST events to the Broker. Once an Event has entered the Broker, it can be forwarded to event Channels by using Triggers. This event delivery mechanism hides
|
||
details of event routing from the event producer and event consumer.
|
||
|
||
### Trigger
|
||
A Trigger describes a filter on event attributes which should be delivered to Consumers. This allows the consumer to only receive a subset of the events.
|
||
|
||
### Example
|
||
Suppose we want to implement the following workflow for events
|
||
|
||
|
||
We can implement this with Channel and Subscription, but in order for that we’d need 6 Channels and have two instances of Consumer1 (because we would need to have it output
|
||
to two different channels to separate Red and Yellow without Consumer2 and Consumer4 having to filter out the events they didn’t want). We would furthermore need to have 6
|
||
Subscription objects. By using the Broker / Trigger we only have to declare that Consumer1 is interested in Blue and Orange events, Consumer2 is interested in Red events and so forth. The new topology now becomes:
|
||
|
||
|
||
To see this in action let us first create a Broker:
|
||
|
||
```
|
||
kubectl create -f - <<EOF
|
||
apiVersion: eventing.knative.dev/v1
|
||
kind: Broker
|
||
metadata:
|
||
name: default
|
||
namespace: default
|
||
EOF
|
||
```{{execute}}
|
||
|
||
Now we will create consumers that will simply log the event. (We will only create two consumers, the rest will be very similar):
|
||
|
||
```
|
||
for i in 1 2; do
|
||
cat <<EOF | kubectl create -f -
|
||
apiVersion: serving.knative.dev/v1
|
||
kind: Service
|
||
metadata:
|
||
name: consumer${i}
|
||
spec:
|
||
template:
|
||
spec:
|
||
containers:
|
||
- image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
|
||
EOF
|
||
done
|
||
```{{execute}}
|
||
|
||
Let us now create Triggers that will send only the events that the consumer is interested in:
|
||
|
||
For `consumer2`, we create a filter for Red events only
|
||
|
||
```
|
||
kubectl apply -f - << EOF
|
||
apiVersion: eventing.knative.dev/v1
|
||
kind: Trigger
|
||
metadata:
|
||
name: consumer2-red
|
||
spec:
|
||
broker: default
|
||
filter:
|
||
attributes:
|
||
type: red
|
||
subscriber:
|
||
ref:
|
||
apiVersion: serving.knative.dev/v1
|
||
kind: Service
|
||
name: consumer2
|
||
EOF
|
||
```{{execute}}
|
||
|
||
For `consumer1` we will create 2 triggers, one for blue and one for orange events.
|
||
|
||
```
|
||
kubectl apply -f - << EOF
|
||
apiVersion: eventing.knative.dev/v1
|
||
kind: Trigger
|
||
metadata:
|
||
name: consumer1-blue
|
||
spec:
|
||
broker: default
|
||
filter:
|
||
attributes:
|
||
type: blue
|
||
subscriber:
|
||
ref:
|
||
apiVersion: serving.knative.dev/v1
|
||
kind: Service
|
||
name: consumer1
|
||
---
|
||
apiVersion: eventing.knative.dev/v1
|
||
kind: Trigger
|
||
metadata:
|
||
name: consumer1-orange
|
||
spec:
|
||
broker: default
|
||
filter:
|
||
attributes:
|
||
type: orange
|
||
subscriber:
|
||
ref:
|
||
apiVersion: serving.knative.dev/v1
|
||
kind: Service
|
||
name: consumer1
|
||
EOF
|
||
```{{execute}}
|