README.md 5.11 KB
Newer Older
Nane Kratzke's avatar
Nane Kratzke committed
1
# Lab 10: Messaging-basierte Interaktion
Nane Kratzke's avatar
Nane Kratzke committed
2

Nane Kratzke's avatar
Nane Kratzke committed
3
4
5
Wir werden Messaging erstaunlicherweise am Beispiel der Datenbank [Redis](https://redis.io) demonstrieren. Wir nutzen Redis vor allem deswegen, weil es sehr einfach zu deployen ist und bereits an anderen Stellen in Labs verwendet wurde und wir so den Technologiestack übersichtlich und die Komplexität überschaubar halten können. Redis wurde zwar primär als In-Memory Key-Value Datenbank entwickelt, hat jedoch mittlerweile sowohl Publish-Subscribe als auch Queueing Features erhalten, die für einfache Anwendungsfälle durchaus ausreichend sind. Als Messaging-Komponenten werden in Cloud-nativen Systemen häufig "klassische" Lösungen wie bspw. [Kafka](https://kafka.apache.org), [Nats](https://nats.io), [RabbitMQ](https://www.rabbitmq.com), [ActiveMQ](https://activemq.apache.org) und weitere [AMQP](https://www.amqp.org)- oder [MQTT](https://mqtt.org)-konforme Lösungen verwendet.

Die in diesem Lab am Beispiel von Redis vermittelten Prinzipien sind aber durchaus auf diese Systeme übertragbar, da die zu Grunde liegenden Kommunikationsmuster Publish-Subscribe und Queueing letztlich von all diesen Messaging-Systemen ermöglicht werden.
Nane Kratzke's avatar
Nane Kratzke committed
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

## Inhalt

- [Lab 10: Messaging-basierte Interaktion](#lab-10-messaging-basierte-interaktion)
  - [Inhalt](#inhalt)
  - [Vorbereitung](#vorbereitung)
  - [Übung 01: Pub/Sub Messaging (Fan Out)](#übung-01-pubsub-messaging-fan-out)
  - [Übung 02: Queueing](#übung-02-queueing)
  - [Verständnis- und Transferfragen](#verständnis--und-transferfragen)
  - [Links](#links)
  - [Was sollten Sie mitnehmen](#was-sollten-sie-mitnehmen)

## Vorbereitung

## Übung 01: Pub/Sub Messaging (Fan Out)

```
              +--M3,M2,M1-> C
              |
P --M3,M2,M1--+--M3,M2,M1-> C
              |
              +--M3,M2,M1-> C
```

## Übung 02: Queueing

```
                 +--M4,M1-> C2
                 |
P --M4,M3,M2,M1--+-----M2-> C3
                 |
                 +-----M3-> C4
```

## Verständnis- und Transferfragen

Nane Kratzke's avatar
Nane Kratzke committed
42
43
44
45
46
47
48
49
50
51
52
- Für welche Anwendungsfälle würden Sie das PubSub-Kommunikationsmuster einsetzen?
- Für welche Anwendungsfälle würden Sie das Queueing-Kommunikationsmuster einsetzen?
- Vergleichen Sie die Latenzzeiten bei PubSub und Queue? Gibt es nennenswerte Unterschiede?
- Vergleichen Sie die Latenzzeiten dieses Labs mit dem gRPC-Lab? Welche Technologie ist grundsätzlich performanter? Woher kommt das?
- Wie stufen Sie den Grad der Kopplung bei Messaging/Streaming im Vergleich zu gRPC ein?
- Wie stufen Sie den Grad der Kopplung bei Messaging/Streaming im Vergleich zu REST ein?
- Blicken wir nun auf die Labs zu REST, gRPC und Streaming zurück?
  - Vor dem Hintergrund loser Kopplung und Performanz:
  - In welchen Fällen würden Sie REST einsetzen?
  - In welchen Fällen würden Sie gRPC einsetzen?
  - In welchen Fällen würden Sie Messaging einsetzen?
Nane Kratzke's avatar
Nane Kratzke committed
53
54
55
56
57
58
59
60
61
62

## Links

- [Redis](https://redis.io)
- [Introduction to Redis Streams](https://redis.io/topics/streams-intro)
- Weitere Messaging Lösungen wie [Kafka](https://kafka.apache.org), [Nats](https://nats.io), [RabbitMQ](https://www.rabbitmq.com), [ActiveMQ](https://activemq.apache.org)
- Messaging Standards wie [AMQP](https://www.amqp.org) und [MQTT](https://mqtt.org)

## Was sollten Sie mitnehmen

Nane Kratzke's avatar
Nane Kratzke committed
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
- Obwohl Redis eigentlich eine In-Memory Key-Value Datenbank ist, kann Sie (für viele überraschend) auch für (einfaches) Messaging eingesetzt werden. Gegenüber komplexeren Lösungen wie bspw. Kafka kann dies durchaus von Vorteil sein.
- Das Kommunikationsmuster Publish-Subscribe kann für vor allem für Fan-Out Anwendungsfälle eingesetzt werden, d.h. bei der Nachrichten an ALLE Consumer gehen.
- Das Kommunikationsmuster Queueing wird vor allem für Load Balancing eingesetzt werden, bei der Nachrichten über mehrere Consumer zur Verarbeitung verteilt und dort verarbeitet werden müssen. Sowohl Producer als auch Consumer können dabei unabhängig von einander skaliert werden.
- Messaging ist hinsichtlich Übertragungslatenzen meist performanter als gRPC, gRPC ist üblicherweise performanter als REST.
- Sowohl REST als auch Messaging ermöglichen eine lose Kopplung von Services.
- Die bislang betrachteten Technologien kann man aufsteigend anhand des Grads Ihrer Kopplung ordnen:
  1. **Messaging** (Consumer und Producer gehen eine Kopplung zu einem Use Case agnostischen Message Broker ein)
  2. **REST** (Consuming Services gehen eine Kopplung zu einem Providing Service ein)
  3. **gRPC** (Consuming und Providing Service gehen eine gegenseitige Kopplung ein)

Eine abschließende Platzierung der betrachteten Ansätze könnte daher wie folgt aussehen:

| Technologie | Kopplung | Performanz | Broker  | Summe der Platzierungen | Kommunikationsmuster
|-------------|:--------:|:----------:|:------: |:------:|--------------------------
| REST        | 2        | 3          | nein (1)| **6** | Request-Response
| gRPC        | 3        | 2          | nein (1)| **6** | Request-Response
| Messaging   | 1        | 1          | ja (3)  | **5** | Publish-Subscribe + Queueing

Einen klaren Gewinner gibt es also nicht (ansonsten hätte sich dieser vermutlich auch schon durchgesetzt). Es kommt also (wie so häufig) auf den Use Case an.