knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove oudated overview page (#4443) 

* Remove oudated overview page

* fix links

* additional fluff cleanup
This commit is contained in:
Ashleigh Brennan 2021-11-05 10:14:12 -05:00 committed by GitHub
parent b5b45ef549
commit a659d5af00
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 32 additions and 127 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
docs/eventing/README.md
View File

@ -1,12 +1,16 @@
# Knative Eventing
Knative Eventing enables developers to use an [event-driven architecture](https://en.wikipedia.org/wiki/Event-driven_architecture) with serverless applications. An event-driven architecture is based on the concept of decoupled relationships between event producers that create events, and event consumers, or [_sinks_](../eventing/sinks/README.md), that receive events.
Knative Eventing provides tools for routing events from event producers to sinks, enabling developers to use an [event-driven architecture](https://en.wikipedia.org/wiki/Event-driven_architecture) with their applications.
In a Knative Eventing deployment, event [Sources](../eventing/sources/README.md) are the primary event producers, however you can also configure a sink or _subscriber_ to respond to HTTP requests by sending a response event. Examples of sinks in a Knative Eventing deployment include Knative Services, Channels and Brokers.
<!--TODO: Add response / reply event information, maybe diagrams-->
Knative Eventing resources are loosely coupled, and can be developed and deployed independently of each other. Any producer can generate events before there are active event consumers that are listening. Any event consumer can express interest in an event or class of events, before there are producers that are creating those events.
Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the [CloudEvents specifications](https://cloudevents.io/), which enables creating, parsing, sending, and receiving events in any programming language.
Other services can be connected to the Knative Eventing system. These services can perform the following functions:
- Create new applications without modifying the event producer or event consumer.
- Select and target specific subsets of the events from their producers.
## Common use cases
Knative Eventing supports the following use cases:
@ -22,16 +26,32 @@ Consume an event without creating a publisher
<!--TODO: What about channels?-->
## Design overview
## Eventing components
Knative Eventing is designed around the following goals:
An event-driven architecture is based on the concept of decoupled relationships between event producers that create events, and event consumers, or [_sinks_](../eventing/sinks/README.md), that receive events. It builds on delivery over HTTP by providing configuration and management of pluggable event-routing components.
1. Knative Eventing resources are loosely coupled, and can be developed and deployed independently of each other.
1. Event producers and event consumers are independent. Any producer can generate events before there are active event consumers that are listening. Any event consumer can express interest in an event or class of events, before there are producers that are creating those events.
1. Knative Eventing is consistent with the [CloudEvents](https://github.com/cloudevents/spec/blob/master/spec.md#design-goals) specification that is developed by the [CNCF Serverless WG](https://lists.cncf.io/g/cncf-wg-serverless), which ensures cross-service interoperability.
1. Other services can be connected to the Knative Eventing system. These services can perform the following functions:
- Create new applications without modifying the event producer or event consumer.
- Select and target specific subsets of the events from their producers.
A sink or _subscriber_ can also be configured to respond to HTTP requests by sending a response event. Examples of sinks in a Knative Eventing deployment include Knative Services, Channels and Brokers.
### Event sources
In a Knative Eventing deployment, event [Sources](../eventing/sources/README.md) are the primary event producers. Events are sent to a sink or _subscriber_.
### Broker and Trigger
[Brokers](../eventing/broker/README.md) and [Triggers](../eventing/broker/triggers/README.md) provide an "event mesh" model, which allows an event producer to deliver events to a Broker, which then distributes them uniformly to consumers by using Triggers.
This delivers the following benefits:
- Consumers can register for specific types of events without needing to
negotiate directly with event producers.
- Event routing can be optimized by the underlying platform using the specified
filter conditions.
### Channel and Subscription
[Channels](../eventing/channels/README.md) and [Subscriptions](../eventing/channels/subscriptions.md) provide a "event pipe" model which transforms and routes events between Channels using Subscriptions.
This model is appropriate for event pipelines where events from one system need to be transformed and then routed to another process.
### Event registry
@ -42,5 +62,4 @@ The registry consists of a collection of event types. The event types stored in
the registry contain (all) the required information for a consumer to create a
Trigger without resorting to some other out-of-band mechanism.
To learn how to use the registry, see the
[Event Registry documentation](event-registry.md).
To learn how to use the registry, see the [Event Registry documentation](event-registry.md).

1
docs/eventing/broker.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 27 KiB

1
docs/eventing/channel.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 44 KiB

112
docs/eventing/developer-overview.md
View File

@ -1,112 +0,0 @@
# Eventing
Knative Eventing provides tools for routing events from event sources to
targets. It builds on [CloudEvents](https://cloudevents.io) delivery over HTTP
by providing configuration and management of pluggable event-routing components.
Knative Eventing provides a few benefits over other messaging systems:
- Using CloudEvents, events can be produced either by microservices that publish
directly to the Broker or Channel or via configurable Sources.
- Using Kubernetes for the management of the underlying resources enables
applying existing management tools (Policy, GitOps, etc) to managing event
delivery between components.
## Object Models
Knative Eventing provides two different models for handling events. Both of
these models route CloudEvents and are configured using Kubernetes custom
resource objects.
- **Broker and Trigger** provides an event routing mesh with per-Trigger event
filtering capabilities.
- **Channel and Subscription** provides event routing between Channels using
explicit reply routing in the Subscription.
When in doubt, we generally recommend the "Broker and Trigger" model unless you
need the specific reply capabilities of "Channel and Subscription".
### Broker and Trigger
![Broker and Trigger model](broker.svg)
Brokers and Triggers provide an "event mesh" model which allows component
sources and software systems to deliver events to a well-known endpoint (the
Broker) and then distribute them uniformly to consumers (via Triggers).
Generally, only a single Broker is needed per namespace, and many Triggers may
key off the same Broker. This delivers the following benefits:
- Consumers can register for specific types of events without needing to
negotiate directly with event producers. (Decouples producing and consuming
teams.)
- Event routing can be optimized by the underlying platform using the specified
filter conditions.
### Channel and Subscription
![Channel and Subscription model](channel.svg)
Channels and Subscriptions provide a "event pipe" model which transforms and
routes events between Channels using Subscriptions. This model is appropriate
for event pipelines where events from one system need to be transformed and then
routed to another process. This pattern is appropriate when:
- Events should be explicitly routed from one component to another, rather than
connecting data from multiple sources.
- Generally, producers will have a better notion of their downstream consumers,
because they need to communicate the specific Channel that their consumer
needs to create a Subscription on.
## Event Delivery
All Knative components use the
[CloudEvents HTTP protocol binding](https://github.com/cloudevents/spec/blob/v1.0.1/http-protocol-binding.md)
to exchange events. This is a fairly simple metadata-and-payload format,
typically represented in binary format using `CE-` prefixed HTTP headers, like
this example from the CloudEvents spec:
```http
POST /someresource HTTP/1.1
Host: webhook.example.com
ce-specversion: 1.0
ce-type: com.example.someevent
ce-time: 2018-04-05T03:56:24Z
ce-id: 1234-1234-1234
ce-source: /mycontext/subcontext
.... further attributes ...
Content-Type: application/json; charset=utf-8
Content-Length: nnnn
{
... application data ...
}
```
Both Triggers and Subscriptions deliver events to the referenced Service
(`subscriber`) using HTTP POSTs. They also support routing events returned in
the reply to the POST:
- **Triggers** route replies back into the associated Broker for delivery to all
Triggers attached to the Broker (including this Trigger -- it's possible to
set up an infinite loop if you emit the same type of event you consume).
- **Subscriptions** have an explicit `reply` property that allows you to route
the reply to another Channel, which enables building
processor-channel-processor transformation pipelines.
A reply event is a CloudEvent delivered back to a Trigger or Subscription using
the HTTP Reply encoding, like this example from the CloudEvents spec:
```http
HTTP/1.1 200 OK
ce-specversion: 1.0
ce-type: com.example.someevent
ce-time: 2018-04-05T03:56:24Z
ce-id: 1234-1234-1234
ce-source: /mycontext/subcontext
.... further attributes ...
Content-Type: application/json; charset=utf-8
Content-Length: nnnn
{
... application data ...
}
```