|
|
@@ -1,6 +1,64 @@
|
|
|
-# Message Service #
|
|
|
+# Message Service
|
|
|
|
|
|
-## Einleitung
|
|
|
+# Einleitung
|
|
|
+
|
|
|
+Dieser Service ust en einfacher cloud native Message Service, wie es ja schon so viele gibt. Zunächst einmal ist er als reiner Test für eine Go Implementierung und verschiedene Studien gedacht. Längerfristig soll dieser Service den GAP zwischen den vielen kleinen selbstgestrickten Lösungen und den doch recht umfangreichen und komplexen Servicen wie Kafka, RocketMQ, RabbitMQ... schliessen.
|
|
|
+
|
|
|
+Ein kurzer Vergleich:
|
|
|
+
|
|
|
+Kafka: Mit Abstand der am weitesten vorgeschrittene Service. Die Eierlegende Woll-Milch-Sau. Kafka kann so ziemlich alles, was man braucht und eben noch viel mehr. Leider ist der Betrieb aber auch eher schwergewichtig. Neben dem Kafka CLuster selber, wernden och weitere zahreiche Komponeneten für den Betrieb benötigt, die auch nicht gerade einfach sind. Als ein Beispiel Zookeeper.
|
|
|
+
|
|
|
+(https://kafka.apache.org/)
|
|
|
+
|
|
|
+RocketMQ: Etwas weniger komplex, aber leider doch mit dem Nameserver und Broker Konzept recht komplex, gerade für kleine Installation für meine Begriffe etwas oversized.
|
|
|
+
|
|
|
+(http://rocketmq.apache.org/)
|
|
|
+
|
|
|
+RabbitMQ: Zwar werden mich die Entwickler nun schlagen, aber RabbitMQ ist nicht Cloud Native. Dazu gibt es da viel zu viele Sonderlocken. Das Discovery der Nodes ist eher fragwürdig, vor allem, wenn es um eine Docker/Kubernetes Integration geht.
|
|
|
+
|
|
|
+(https://www.rabbitmq.com/)
|
|
|
+
|
|
|
+Am nähesten für einen solchen Service käme für einen solchen "kleinen" Service wäre NSQ.
|
|
|
+
|
|
|
+Bei diesen sind jedoch der Lookup beim Start, und die nicht vorhandene Persistenz eines Nodes zu beanstanden. Vor allem, da die Messages nicht im Cluster verteilt werden, sondern nur auf dem Node, auf dem Sie gesendet wurden gespeichert. Geht der Node hops, sind die Messages weg. Auch schwierig, der Client macht zu allen Nodes eine Verbindung auf und sucht dann in den verschiedenen Shards nach der zu konsumierenden Message. Ein Splitbrain ist da schon vorprogrammiert. Aber NSQ ist ja noch relativ jung. (V 1.2)
|
|
|
+
|
|
|
+(https://nsq.io/)
|
|
|
+
|
|
|
+# Architekturansatz
|
|
|
+
|
|
|
+Da der Service eher für kleine bis mittlere Installation vorgesehen ist, werden folgende Annahmen/Voraussetzungen gemacht.
|
|
|
+
|
|
|
+- Der Service hat keinerlei Abhängigkeiten zu anderen Servicen. Er kann somit auch stand-alone betrieben werden.
|
|
|
+- Ein Cluster bildet sich, wenn die Knoten sich gegenseitig finden. Dazu kann eine DNS/IP Table übergeben werden. Einmal im Cluster, werden die IPs aller beteiligten geshared. Ebenso wie deren Status. Beim Start kann in der Konfiguration eine Mindest-Clustergröße mitgegeben werden. Sind weniger Nodes aktiv als in der Konfiguration angegeben, wird ein Splitbrain vermutet und der Service verweigert seinen Dienst. -> unhealthy
|
|
|
+- Topics werden in shards verwaltet. Je nach Konfiguration (QoS) kann die Annahme einer Meldung entsprechend des QuS Wertes zugesichert werden.
|
|
|
+ - QoS = 0: Die Nachricht ist auf dem 1. Knoten empfangen worden, keine Persistenz.
|
|
|
+ - QoS = 1: Die Nachricht ist in zumindest einem Shard aufgenommen worden.
|
|
|
+ - QoS = 2: Die Nachricht ist in zumindest zwei Shards (Topic Shard + Backup) aufgenommen worden.
|
|
|
+ - QoS = 3: Die Nachricht wurde zusätzlich auch noch persistiert.
|
|
|
+- ein Topic ist die eigentliche Struktur. Eine MEldung wird zunächst in einem Topic vom Producer empfangen. Dann wird die Nachricht an die angeschlossenen Consumer Groups parallel weiter geleitet. Innerhalb einer Consumer Group kann dann ein Consumer diese Nachricht erhalten (lock) und nach Verarbeitung entweder zurückweisen (Reject), dann geht Sie an einen anderen Consumer, oder aber als verarbeitet (acknowledge) markieren.
|
|
|
+- Nachrichten inenrhalb eines Topics sind grundsätzlich ordered. Einzig bei der parallelen Verarbeitung innerhalb einer Consumergroup, kann die Reihenfolge variieren. (Wenn eine Consumer eine Meldung Rejected hat)
|
|
|
+- Die ID einer Message ist innerhalb eines Topics fortlaufend.
|
|
|
+- Der Client kann jederzeit auch auf bereits konsumierte Nachrichten per ID zugreifen, wenn diese nicht explizite (oder implizit) gelöscht worden sind. Auch ein Peek ist jederzeit möglich.
|
|
|
+- Consumer erhalten nur die ausgewählte Meldung. Eine Persistenz im Client ist unerwünscht.
|
|
|
+- Auch der Consumer kann auf ein Topic mit einem QoS zugreifen.
|
|
|
+ - QoS = 0: Sobald der Client eine Message anfordert, wird diese automatisch als verarbeitet gekennzeichnet
|
|
|
+ - QoS = 1: Der Client muss explizite ein Nachricht als verarbeitet kennzeichnen
|
|
|
+- Pro Topic können bestimmte Verhaltensweisen beim Erstellen vom Producer und Consumer eingestellt werden.
|
|
|
+ - Producer:
|
|
|
+ - Generell:
|
|
|
+ - MAX_CAPACITY: wie viele Nachrichten kann das Topic maximal aufnehmen. Default: -1
|
|
|
+ - DEFAULT_QOS: Default QoS für alle Producer in diesem Topic
|
|
|
+ - Client-Session:
|
|
|
+ - DEFAULT_QOS: Default QoS für diesen Producer in diesem Topic
|
|
|
+ - Consumer:
|
|
|
+ - Generell
|
|
|
+ - DEFAULT_QOS: Default QoS für alle Consumer in diesem Topic
|
|
|
+ - Gruppe
|
|
|
+ - DEFAULT_QOS: Default QoS für alle Consumer einer Gruppe in diesem Topic
|
|
|
+ - DELETE_AFTER_ACKNOWLEDGE: Nach dem Acknowledge wird die Nachricht für diese Gruppe automatisch gelöscht.
|
|
|
+ - Client-Session
|
|
|
+ - DEFAULT_QOS: Default QoS für diesen Consumer in diesem Topic
|
|
|
+- Jeder Client hat eine eindeutige ID
|
|
|
|
|
|
## Konfiguration des Service
|
|
|
|
|
|
@@ -31,30 +89,6 @@ logging:
|
|
|
healthcheck:
|
|
|
# automatically check the health of this service every ## seconds
|
|
|
period: 30
|
|
|
-# background tasks configuration
|
|
|
-backgroundtasks:
|
|
|
- deleteOrphanedFiles: true # automatically delete orphaned files
|
|
|
- period: 86400 #once a day
|
|
|
-
|
|
|
-# configuration of the mongo storage
|
|
|
-mongodb:
|
|
|
- host: 127.0.0.1 #mongo host ip (comma seperated ip's with a cluster installation )
|
|
|
- port: 27017 # mongo host port
|
|
|
- username: #username for the database (should be at last dbadmin, and read/write access)
|
|
|
- password: #password for the user
|
|
|
- authdb: backend1 # database to authenticate against
|
|
|
- database: backend1 # database for the data
|
|
|
-
|
|
|
-```
|
|
|
-
|
|
|
-Die Secrets zu diesem Service, im speziellen username und Passwort zur MongoDB werden in einer speziellen Datei secrets.yaml abgelegt. Diese wird über den Configeintrag `secretfile` bestimmt.
|
|
|
-
|
|
|
-Inhalt:
|
|
|
-
|
|
|
-```yaml
|
|
|
-mongodb:
|
|
|
- username: backend1
|
|
|
- password: backend1
|
|
|
```
|
|
|
|
|
|
|
