Streaming & Messaging - Hikube

Kafka, RabbitMQ, NATS.
kubectl apply - das ist alles.

Drei vollständig gemanagte Messaging-Dienste auf Hikube. Verteiltes Event-Streaming, PQAM-Task-Queues, ultraleichte Werbung/Sub. Automatische Replikation, koordinierter ZooKeeper, JetStream inklusive.

KONTAKTIEREN SIE UNSERE EXPERTEN DOKUMENTATION

3 Dienste

Kafka - RabbitMQ - NATS

Native HA

Automatische Replikation + Quorum

>1 ms

NATS-Latenz (dasselbe Rechenzentrum)

0 Konfig.

ZooKeeper, Sentinel, Raft - verwaltet
Vergleich

Der richtige Dienst für jedes Pattern

Kafka, RabbitMQ und NATS erfüllen unterschiedliche Anforderungen. Die Wahl hängt von der Menge, dem Liefermodell und der benötigten Haltbarkeit ab.

SERVICE
PROTOKOLL
MODELL
PERSISTANZ
GEBRAUCHSFALL
Kafka
Kafka
Binäres TCP
Pub/Sub mit verteiltem Log
Ja - konfigurierbare Retention
Event-Streaming, Datenpipelines, Echtzeit-Analytik
RabbitMQ
RabbitMQ
AMQP
Warteschlange mit Routing
Ja - Quorum Queues (Raft)
Task Queues, RPC, komplexes Routing, asynchrone Workflows
Frame 11502-2
NATS
TCP Text
Pub/Sub + Request/Reply
Optional - JetStream
Microservices, IoT, Edge, leichte Echtzeitkommunikation
DIENSTLEISTUNGEN

Jede Dienstleistung im Detail

Kafka

Strimzi Operator ZooKeeper Verteiltes Log

Kafka organisiert Nachrichten in Topics, die in Partitionen unterteilt und auf mehrere Broker verteilt sind. Jede Partition wird gemäß dem replicationFactor repliziert. Fällt ein Broker aus, werden die Partitionen auf die verfügbaren Replikate umgeleitet. ZooKeeper koordiniert die Wahl der Leader und speichert die Metadaten des Clusters.

Im Gegensatz zu RabbitMQ bewahrt Kafka die Nachrichten nach ihrem Verbrauch auf. Die Dauer der Speicherung kann pro Topic konfiguriert werden (retention.ms). Mehrere Consumer Groups können das gleiche Topic unabhängig voneinander lesen, wobei jede Gruppe ihren eigenen Offset beibehält.

  • Topics deklariert im Manifest
    Partitionen, Replikationsfaktor, Retention und Cleanup Policy direkt in YAML konfiguriert. Keine externen Tools zum Erstellen von Topics erforderlich.
  • Verwalteter ZooKeeper
    3 ZooKeeper-Instanzen koordinieren den Cluster automatisch. Das ungerade Quorum ist garantiert ein Ausfall eines ZK-Knotens unterbricht den Dienst nicht.
  • Retention und Compact
    cleanup.policy: delete löscht Nachrichten nach retention.ms. cleanup.policy: compact speichert nur die letzte Nachricht pro Schlüssel, ideal für Referenztabellen.
  • Optionale externe Exposition
    external: true Erstellt einen LoadBalancer pro Broker für Clients außerhalb des Clusters. Vermeiden Sie dies ohne konfigurierte Authentifizierung.
yaml
apiVersion: apps.cozystack.io/v1alpha1
kind: Kafka 
  metadata:
name: example
spec:
  external: false
  kafka:
    replicas: 3
    resourcesPreset: small
    size: 10Gi
    storageClass: replicated
  zookeeper:
    replicas: 3 # Toujours impair
    resourcesPreset: small
    size: 5Gi
    storageClass: replicated
topics:
  - name: my-topic
    partitions: 3
    replicas: 3
    config:
      retention.ms: "604800000" # 7 jours
      cleanup policy: "delete" 


 
Warum gemanagt

Was Sie nicht mehr tun müssen

Kafka, RabbitMQ und NATS sind drei verschiedene verteilte Systeme, aber sie teilen im selbstgehosteten Betrieb das gleiche Problem: Jedes erfordert dediziertes Fachwissen, um in der Produktion ordnungsgemäß betrieben werden zu können. Die Dimensionierung von Knoten, die Konfiguration des Quorums, das Testen von Failover, die Verwaltung von Versionsupgrades ohne Unterbrechung des Nachrichtenflusses stellt Engineering-Zeit dar, die keinen geschäftlichen Wert erzeugt.

Auf Hikube absorbiert der Kubernetes-Betreiber diesen Aufwand für alle drei Dienste. Sie deklarieren, was Sie wollen, Anzahl der Knoten, Topics oder Vhosts, Ressourcen, und der Betreiber stellt bereit, repliziert und schaltet im Falle eines Ausfalls um. Die Konfiguration zu ändern ist so, als würde man einen Wert in einer YAML-Datei ändern und anwenden.

markup-cropped-1

Automatisches Quorum und Konsens

ZooKeeper für Kafka, Raft für RabbitMQ und JetStream NATS. Die Leader-Election-Mechanismen werden ohne manuellen Eingriff konfiguriert und überwacht.

markup-cropped-1

Topics, vhosts und streams mit dem Cluster

Partitionen, Retention, Virtual Hosts, JetStreams, die in YAML am selben Ort deklariert werden. Kein separates Initialisierungsskript, das gepflegt werden muss.

markup-cropped-1

Scaling ohne Unterbrechung

Ändern Sie die Anzahl der Knoten im Manifest und wenden Sie sie an. Der Operator fügt die Instanzen im Rolling Update ohne manuelles Rebalancing und ohne Downtime hinzu.

markup-cropped-1

Selbst erstellte Credentials

Die Passwörter werden beim Provisioning in einem Kubernetes Secret erstellt. Verweisen Sie in Ihren Pods auf das Secret, keine Schlüssel im Klartext in Ihren Manifesten oder Git-Repositories.

Anwendungsfälle

Welcher Dienst für welchen Bedarf?

Die drei Dienste konkurrieren nicht miteinander, sondern ergänzen sich. Hier sind die konkreten Muster, in denen sich jeder durchsetzt.

Pipeline von Anwendungslogs

Verwaltung von Millionen von Log-Ereignissen aus 50 Mikrodiensten. 7 Tage Speicherung, mehrere unabhängige Consumer (Elasticsearch, ClickHouse, Alerting). Jeder Consumer liest aus seinem eigenen Offset nach.

3 Broker - 3 Partitionen - retention.ms: 604800000

Event Sourcing und Audit Trail

Jede Benutzeraktion wird in einem Thema mit cleanup.policy: compact veröffentlicht. Der aktuelle Status ist die Summe der Ereignisse. Das Topic compact stellt sicher, dass der letzte Status pro Schlüssel beibehalten wird.

cleanup.policy: compact - replicas: 3 - min.insync: 2

Warteschlange für die Bearbeitung von E-Mails

Befehle lösen eine Nachricht in einer Warteschlange emails.pending aus. Workers lesen die Warteschlange, senden die E-Mail und ACK die Nachricht. Wenn ein Worker abstürzt, wird die Nachricht automatisch neu gequeued.

replicas: 3 - quorum queues - ACK/NACK

Routing von Veranstaltungen mit mehreren Zielen

Ein Exchange vom Typ topic routet die Ereignisse orders.* in die Rechnungswarteschlange, orders.shipped in die Logistikwarteschlange und # in eine Audit-Warteschlange. Ein Publish, mehrere Ziele.

exchange: topic - bindings - 3 Schwänze

Kommunikation zwischen Mikrodiensten

Dienst A ruft Dienst B über NATS request/reply statt HTTP an. Keine Service Discovery, kein Load Balancer. NATS routet direkt zu einem verfügbaren Subscriber in der Queue Group.

Request/Reply - Warteschlangengruppen - <1ms latency

IoT-Telemetrie mit JetStream

10.000 Sensoren veröffentlichen Metriken auf sensors.>. JetStream speichert 24 Stunden lang Daten. Analysedienste verbinden sich und spielen beim Start die Historie ab. Nützlich nach einer Wartung.

JetStream - 24h retention - replay on connect
Managed Streaming & Messaging

Event-Driven als Grundlage für moderne Architekturen

Ereignisorientierte Architekturen sind zum Standard moderner verteilter Systeme geworden. Wo synchrone APIs schwache Kopplungen schaffen, ermöglichen Message Broker die Kommunikation zwischen Diensten ohne direkte Abhängigkeit. Jeder Dienst produziert oder konsumiert Ereignisse in seinem eigenen Tempo.

Kafka strukturiert Pipelines mit großen Datenmengen, Logs, Metriken, Geschäftsereignissen, mit langer Speicherung und Ereigniswiederholung, die Prüfung und Disaster Recovery vereinfacht. RabbitMQ sorgt für die zuverlässige Weiterleitung kritischer Aufgaben: Jede Nachricht wird genau einmal verarbeitet, mit Zustellungsgarantie. NATS reduziert die Reibung zwischen Microservices durch leichte Kommunikation, Mikrosekunden-Latenz und ohne schwere Infrastruktur.

In der gemanagten Version übernehmen Ihre Teams diese Patterns, ohne bei der Infrastruktur von Grund auf neu anfangen zu müssen. Die gleiche Technologie, die gleichen SDKs und die gleichen Tools werden von Hikube bereitgestellt und betrieben.

markup-cropped-1

Entkopplung und Ausfallsicherheit von Anwendungen

Ein ausgefallener Dienst zieht nicht die anderen nach sich. Die Nachrichten sammeln sich im Broker an und werden bei der Wiederaufnahme verarbeitet, ohne Verluste oder manuelle Eingriffe.

markup-cropped-1

IoT und Edge Computing

NATS inkorporiert Millionen von Sensorereignissen mit einem minimalen Speicherplatzbedarf. JetStream stellt sicher, dass die Daten nicht verloren gehen, wenn ein Verarbeitungsdienst neu gestartet wird.

markup-cropped-1

Data-Streaming und Echtzeit-Analytik

Füttern Sie ClickHouse, Elasticsearch oder Ihre Grafana-Dashboards kontinuierlich aus Kafka. Dasselbe Topic kann gleichzeitig mehrere unabhängige Consumer füttern.

markup-cropped-1

Kompatibel mit Ihrem Stack

Kafka Connect, Confluent SDKs, pika, nats.go, nats.py. Alle bestehenden Clients funktionieren ohne Änderungen. Verweisen Sie auf den Kubernetes-Dienst, der Rest ist identisch.

FAQ

Frage zu Managed Streaming & Messaging

Kafka oder RabbitMQ, wie soll man sich entscheiden?

Kafka ist für hochvolumiges Streaming und lange Retention gemacht - Nachrichten bleiben nach dem Konsum verfügbar, mehrere Consumer können das gleiche Topic unabhängig voneinander lesen. Es ist die natürliche Wahl für Datenpipelines, Event Sourcing und Echtzeitanalytik.

RabbitMQ ist für Task Queues und komplexes Routing gemacht - Nachrichten werden verbraucht und gelöscht, mit garantiertem acknowledgement. Es ist die natürliche Wahl für Hintergrundverarbeitung, asynchrone Workflows und Systeme, in denen jede Nachricht genau einmal verarbeitet werden muss.

Wann sollte man NATS anstelle von Kafka oder RabbitMQ verwenden?

NATS ist die richtige Wahl, wenn Sie eine leichte und schnelle Kommunikation zwischen Mikrodiensten benötigen - ohne die Komplexität eines schwerfälligen Brokers. Seine Sub-Millisekunden-Latenz und sein minimaler Speicherplatzbedarf (<10 MB pro Instanz) machen ihn zur besten Wahl für Edge-Architekturen, IoT und die Request/Reply-Kommunikation zwischen Diensten.

Wenn Sie Langzeitpersistenz und großflächige Ereigniswiederholungen benötigen, ist Kafka nach wie vor besser geeignet. Wenn Sie komplexes Routing mit garantiertem ACK benötigen, ist RabbitMQ besser geeignet.

Warum benötigt ZooKeeper eine ungerade Anzahl von Replikas?

ZooKeeper verwendet einen Quorum-Konsensus-Algorithmus - eine Entscheidung (Leader-Wahl, Schreiben) wird bestätigt, wenn eine Mehrheit der Knoten ihr zustimmt. Bei 3 Knoten ist das Quorum 2 - der Verlust eines Knotens unterbricht den Dienst nicht. Bei 4 Knoten ist das Quorum ebenfalls 2 - Sie tolerieren immer den Verlust eines einzelnen Knotens. Eine Erhöhung von 3 auf 4 verbessert die Fehlertoleranz nicht, sondern erhöht nur die Kosten. Deshalb empfehlen wir 3 oder 5, niemals 4.

Ist NATS JetStream standardmäßig aktiviert?

Ja, JetStream ist auf Hikube-NATS-Clustern standardmäßig aktiviert. Deaktivieren Sie es nur, wenn Sie einen rein flüchtigen Pub/Sub ohne Persistenz benötigen - so reduzieren Sie den Speicherplatzbedarf und beseitigen die Notwendigkeit eines persistenten Volumens. Lassen Sie in der Produktion JetStream aktiviert, um von Persistenz, Replay und dauerhaften Consumer Groups zu profitieren.

Achtung: Auch bei aktiviertem JetStream werden Nachrichten nur dann persistiert, wenn ein Stream so konfiguriert ist, dass er die betreffenden Subjects erfasst.

Was ist der Unterschied zwischen Partitionen und replicationFactor in Kafka?

Partitionen definieren Parallelität - mehr Partitionen ermöglichen es mehr Consumern, parallel zu lesen. Jede Partition ist eine geordnete Folge von Nachrichten an einen Broker.

Der replicationFactor definiert die Nachhaltigkeit - jede Partition wird auf diese Anzahl von Brokern kopiert. Wenn ein Broker fällt, werden seine Partitionen von den Replikaten bedient. Der replicationFactor kann die Anzahl der Broker nicht überschreiten.

Kann ich meinen Cluster außerhalb des Kubernetes-Clusters ausstellen?

Ja, für Kafka und RabbitMQ über external: true, und für NATS über external: true. Kafka erstellt einen LoadBalancer pro Broker, RabbitMQ legt die Ports AMQP (5672) und Management (15672) offen, NATS legt den Client-Port (4222) offen.

Durch die externe Exposition ist der Dienst über das Internet erreichbar - stellen Sie sicher, dass Sie starke Passwörter verwenden. Kafka hat keine Standardauthentifizierung auf Hikube, daher wird dringend davon abgeraten, den Dienst ohne zusätzliche Sicherheitskonfiguration auszusetzen.