Commit a4c17e9f authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Update README

parent d6cea298
# Lab 10: Messaging-basierte Interaktion # Lab 10: Messaging-basierte Interaktion
Wir werden Messaging am Beispiel von Redis demonstrieren. Wir nutzen Redis, weil dies 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, doch hat 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. 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.
## Inhalt ## Inhalt
...@@ -37,9 +39,17 @@ P --M4,M3,M2,M1--+-----M2-> C3 ...@@ -37,9 +39,17 @@ P --M4,M3,M2,M1--+-----M2-> C3
## Verständnis- und Transferfragen ## Verständnis- und Transferfragen
- A - Für welche Anwendungsfälle würden Sie das PubSub-Kommunikationsmuster einsetzen?
- B - Für welche Anwendungsfälle würden Sie das Queueing-Kommunikationsmuster einsetzen?
- C - 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?
## Links ## Links
...@@ -50,6 +60,22 @@ P --M4,M3,M2,M1--+-----M2-> C3 ...@@ -50,6 +60,22 @@ P --M4,M3,M2,M1--+-----M2-> C3
## Was sollten Sie mitnehmen ## Was sollten Sie mitnehmen
- A - 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.
- B - 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.
- C - 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.
\ No newline at end of file - 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.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment