Architektur
STACKIT RabbitMQ basiert auf einer verwalteten RabbitMQ-Plattform und bietet eine robuste und skalierbare Message-Broker-Lösung für Ihre Anwendungen.
Kernkomponenten
Abschnitt betitelt „Kernkomponenten“RabbitMQ Message Broker
Abschnitt betitelt „RabbitMQ Message Broker“RabbitMQ dient als zentraler Message Broker und ermöglicht die asynchrone Kommunikation zwischen Anwendungen und Diensten. Er unterstützt mehrere Messaging-Protokolle und -Muster, einschließlich Publish/Subscribe, Request/Reply und Point-to-Point-Messaging. Der Broker übernimmt das Message-Routing, die Warteschlangenverwaltung (Queuing) und die Zustellung, wodurch eine zuverlässige Nachrichtenverarbeitung in verteilten Systemen gewährleistet wird.
Management-Schnittstelle
Abschnitt betitelt „Management-Schnittstelle“Die RabbitMQ-Management-Schnittstelle bietet eine webbasierte Benutzeroberfläche für das Monitoring und die Verwaltung Ihres Message Brokers. Sie ermöglicht es Ihnen, Queues, Exchanges, Bindings und Nachrichtenraten einzusehen sowie Benutzer und Berechtigungen zu verwalten.
Plugin-System
Abschnitt betitelt „Plugin-System“RabbitMQ unterstützt verschiedene Plugins, die seine Funktionalität erweitern, darunter Plugins für Federation, Shovel, MQTT, STOMP und Consistent-Hash-Exchange. Diese können basierend auf Ihren spezifischen Anforderungen an den Anwendungsfall aktiviert und konfiguriert werden.
Infrastruktur-Architektur
Abschnitt betitelt „Infrastruktur-Architektur“Isolation der Service-Instanzen
Abschnitt betitelt „Isolation der Service-Instanzen“Jede RabbitMQ-Service-Instanz läuft auf dedizierten virtuellen Maschinen in der STACKIT Compute Engine. Dies gewährleistet die Isolation von anderen Diensten und schützt vor Ressourcenkonflikten (Bad-Neighborhood-Schutz).
Trennung des Deployments
Abschnitt betitelt „Trennung des Deployments“RabbitMQ-Dienste, die über STACKIT Cloud Foundry erstellt wurden, und solche, die über das STACKIT Portal oder die STACKIT CLI erstellt wurden, sind vollständig voneinander getrennt. Dienste, die in einer Umgebung erstellt wurden, müssen in derselben Umgebung verwaltet und gelöscht werden – eine umgebungsübergreifende Verwaltung wird aus technischen Gründen nicht unterstützt.
Single Node vs. Cluster
Abschnitt betitelt „Single Node vs. Cluster“Single Node
- Läuft auf einem einzelnen Knoten
- Geeignet für Entwicklung und Tests
- Nicht für den Produktionseinsatz empfohlen
Cluster (Replica Set)
- Besteht aus 3 Knoten, die über mehrere Verfügbarkeitszonen verteilt sind
- Bietet Hochverfügbarkeit und Fehlertoleranz
- Empfohlen für Produktions-Workloads
- Gewährleistet die Dienstkontinuität, selbst wenn ein Knoten oder eine Verfügbarkeitszone ausfällt
- Automatische Wiederherstellung im Falle von Hardware- oder Rechenzentrumsausfällen
Netzwerkzugriff
Abschnitt betitelt „Netzwerkzugriff“RabbitMQ-Instanzen sind über Public IP-Adressen erreichbar, was die Integration ermöglicht mit:
- Cloud Foundry-Anwendungen
- Kubernetes-Workloads
- Virtuellen Maschinen
- Externen Systemen
Der Zugriff wird durch Zugriffssteuerungslisten (ACLs) und Authentifizierung auf Instanzebene gesichert. Alle Verbindungen unterstützen eine SSL/TLS-Verschlüsselung mit aktuellem TLS v1.3 für erhöhte Sicherheit.
Datenmanagement
Abschnitt betitelt „Datenmanagement“Backup-System
Abschnitt betitelt „Backup-System“Der integrierte Backup-Manager erstellt automatisch alle 4 Stunden vollständige Sicherungen und bewahrt diese für 14 Tage auf. Sie können auch manuelle Sicherungen auslösen und über das Service-Dashboard Wiederherstellungen aus vorhandenen Sicherungen durchführen.
Skalierbarkeit
Abschnitt betitelt „Skalierbarkeit“RabbitMQ nutzt ein T-Shirt-Größenmodell mit vordefinierten Service-Plans. Wenn Ihr Workload wächst, können Sie auf einen größeren Plan mit mehr Ressourcen (vCPU, RAM, Speicherplatz) herabstufen oder heraufstufen. Alle Instanzen nutzen Hochleistungs-SSD-Speicher für optimale Performance.