ALIBABA CLOUD → STACKIT · MESSAGING-ARCHITEKTUR
Alibaba Cloud Kafka, RabbitMQ und RocketMQ auf STACKIT
Drei Broker, drei verschiedene Antworten. Im Lauf hinter dieser Seite wird ApsaraMQ for RabbitMQ zu STACKIT RabbitMQ (REPLATFORM), ApsaraMQ for Kafka zu einem selbst betriebenen Kafka-kompatiblen Broker auf SKE (CONTAINERIZE) und ApsaraMQ for RocketMQ zu einem REDESIGN mit der Konfidenz LOW, weil geordnete und verzögerte Nachrichtensemantik neu gedacht werden muss. Für Ihre Architekten lautet die Frage, welches Brokermodell jede Workload tatsächlich braucht.
Drei Broker, bewertet
Eine für diese Seite geschriebene Streaming-Umgebung, am 4. November 2026 von StackToIT bewertet. Links: die Kafka- und RabbitMQ-Ressourcen der Eingabe. Rechts: ein Auszug aus assessment.json für alle drei Broker mit den Werten, die der Lauf geschrieben hat. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.
resource "alicloud_alikafka_instance" "events" {
name = "orders-events"
partition_num = 50
disk_type = 1
disk_size = 500
deploy_type = 5
io_max = 20
vswitch_id = alicloud_vswitch.data.id
}
resource "alicloud_amqp_instance" "jobs" {
instance_name = "billing-jobs"
instance_type = "professional"
max_tps = 1000
queue_capacity = 50
support_eip = false
}[
{
"id": "alicloud_amqp_instance.jobs",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT RabbitMQ"
},
"reason": "Alibaba Cloud Message Queue for RabbitMQ becomes STACKIT RabbitMQ. Exchanges, queues and credentials are recreated, and messages in flight are drained before cut-over."
}
},
{
"id": "alicloud_alikafka_instance.events",
"result": {
"class": "CONTAINERIZE",
"confidence": "MEDIUM",
"target": {
"service": "a self-managed Kafka-compatible broker on SKE"
},
"reason": "STACKIT has no managed Kafka service. The broker runs self-managed on SKE, or the messaging design changes to RabbitMQ."
}
},
{
"id": "alicloud_rocketmq_instance.txn",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"target": {
"service": "STACKIT RabbitMQ"
},
"reason": "STACKIT has no RocketMQ service. Ordered and delayed message semantics have to be redesigned for RabbitMQ, or the broker runs self-managed on SKE."
}
}
]RabbitMQ: Exchanges und Queues neu angelegt
Als Begründung hält der Lauf fest: Exchanges, Queues und Zugangsdaten werden neu angelegt, und Nachrichten in Bearbeitung werden vor dem Cutover abgearbeitet. StackToIT überträgt davon nichts.
Kafka: Dimensionierung steht in der Eingabe
Die Eingabe nennt 50 Partitionen, eine Disk mit 500 GB und ein io_max von 20. Das ist der Ausgangspunkt für das Broker-Design auf SKE, keine Empfehlung.
RocketMQ: die niedrigste Konfidenz
Die RocketMQ-Instanz ist die einzige Einheit des Laufs mit der Konfidenz LOW. Der Lauf nennt RabbitMQ als Ziel oder einen selbst betriebenen Broker auf SKE.
Die Optionen je Broker
Was der Lauf klassifiziert, welche Alternative er nennt und welchen Kompromiss Sie tragen. Wo die Kompromiss-Spalte über den Lauf hinausgeht, beschreibt sie allgemeine Praxis.
| Quellbroker und Option | Was es bedeutet | Kompromiss |
|---|---|---|
| RabbitMQ zu STACKIT RabbitMQ | REPLATFORM. Ein verwalteter Broker auf Basis von Open-Source-RabbitMQ der AMQP und weitere Protokolle spricht. | Geringster Aufwand. Prüfen Sie Funktionen, die nur der Alibaba-Cloud-Dienst ergänzt, etwa eingebaute verzögerte Nachrichten. |
| Kafka zu selbst betriebenem Broker auf SKE | CONTAINERIZE. Kafka-kompatible Broker laufen auf Ihrem SKE-Cluster. | Clients können beim Kafka-Protokoll bleiben. Sie betreiben Broker, Speicher, Updates und Monitoring. |
| Kafka zu RabbitMQ | Die vom Lauf genannte Alternative: Das Messaging-Design ändert sich. | Ein verwalteter Dienst, aber ein Queue-Modell ersetzt Partitionen und Consumer Groups. Die Anwendung muss sich ändern. |
| RocketMQ zu RabbitMQ | REDESIGN, Konfidenz LOW. Geordnete und verzögerte Nachrichtensemantik wird neu entworfen. | Verwalteter Dienst. Jedes Topic mit Semantik für Ordnung, Verzögerung oder Transaktionen braucht eine eigene Antwort. |
| RocketMQ zu selbst betriebenem Broker auf SKE | Der zweite Weg, den der Lauf nennt. | Die Broker-Semantik bleibt näher an der Quelle. Sie betreiben den Broker. |
Der Lauf führt keinen verwalteten Kafka- oder RocketMQ-Dienst auf STACKIT auf. Bietet STACKIT später einen solchen Dienst an, klassifiziert ein neuerer StackToIT-Build diese beiden Einheiten anders. Lassen Sie die Bewertung dann erneut laufen, statt sich auf diese Seite zu verlassen.
Was Quellbroker und Ziele unterscheidet
RabbitMQ-Funktionen des Dienstes
ApsaraMQ for RabbitMQ ist als AMQP-0-9-1-kompatibel dokumentiert und ergänzt verzögerte Nachrichten (bis zu einem Tag) sowie eine Wiederholungsregel: Fehlgeschlagene Nachrichten werden einmal pro Minute bis zu 16-mal wiederholt und gehen dann in eine Dead-Letter-Queue. Open-Source-RabbitMQ hat keine native Queue für verzögerte Nachrichten.
STACKIT RabbitMQ
Beschrieben als verwalteter Broker auf Basis des Open-Source-Projekts mit AMQP, STOMP, MQTT, HTTP und WebSockets, anlegbar im Portal oder im Cloud-Foundry-Marketplace. Die bepreisten Pläne auf der Produktseite sind Replica-Pläne mit drei Knoten.
Kafka-Clients
ApsaraMQ for Kafka unterstützt Apache Kafka 0.10.x bis 3.x mit Standard-Clients; Producer, Consumer und Kafka-Connect-Pipelines nutzen also das Kafka-Protokoll. Das macht einen selbst betriebenen Broker zum realistischen Ziel.
RocketMQ-Nachrichtentypen
Ein RocketMQ-5.x-Topic unterstützt genau einen Nachrichtentyp: Normal, FIFO, Delay, Transaction oder den neueren Typ Lite, und ein 5.x-Broker weist eine Nachricht ab, deren Typ nicht zum Topic passt. Ihre Topic-Liste verrät daher, auf welche Semantik jedes Topic angewiesen ist.
Consumer Groups und Offsets
Kafka-Consumer merken sich ihre Position je Partition, und mehrere Gruppen können ein Topic unabhängig lesen. Ein Queue-Modell hat kein Gegenstück zu einer unabhängigen Gruppe, die dasselbe Log liest. Die RabbitMQ-Alternative, die der Lauf für Kafka nennt, verändert deshalb das Messaging-Design und nicht nur den Endpunkt.
Zustand ist kein Datenumzug
Der Lauf führt für diese Einheiten keinen Datenumzug auf: Topics und Queues gelten nicht als zustandsbehaftet. Definitionen und Nachrichten in Bearbeitung müssen Sie trotzdem einplanen.
So entscheiden Sie, je Workload
1. Topics, Queues und Gruppen inventarisieren
Listen Sie jedes Topic oder jede Queue mit Producern, Consumern und der benötigten Semantik: Ordnung, Verzögerung, Replay, Transaktionen. Das Terraform zeigt die Instanz, nicht diese Angaben.
2. Event-Streams von Jobs trennen
Job- und Task-Verkehr passt in eine RabbitMQ-Queue. Event-Streams, die mehrere Consumer erneut lesen, sprechen für einen Kafka-kompatiblen Broker.
3. Betrieb des Brokers klären
Eigenbetrieb auf SKE ist ein Dienst, den Sie betreiben: Updates, Disk, Monitoring, Bereitschaft. Rechnen Sie diesen Aufwand ein, bevor Sie den Eigenbetrieb einem verwalteten Redesign vorziehen.
4. Cutover je Workload planen
In der Praxis: Queues leerlaufen lassen oder parallel in beide Broker publizieren, zuerst die Consumer umstellen, dann die Producer. Das ist allgemeine Praxis, kein Schritt, den der Lauf ausführt.
5. Verantwortliche festhalten
Der Lauf legt die drei Broker in ein Arbeitspaket für den Platform Architect und das Netzwerk in ein weiteres für den Network Architect.
Fragen von Plattformteams
Gibt es ein verwaltetes Kafka auf STACKIT?
Laut Lauf hat STACKIT keinen verwalteten Kafka-Dienst. Der Broker läuft daher selbst betrieben auf SKE, oder das Messaging-Design wechselt zu RabbitMQ.
Können RocketMQ-Topics unverändert zu RabbitMQ?
Nein. Laut Lauf hat STACKIT keinen RocketMQ-Dienst; geordnete und verzögerte Semantik muss für RabbitMQ neu entworfen werden, oder der Broker läuft selbst betrieben auf SKE.
Was passiert mit Nachrichten, die noch in Bearbeitung sind?
Bei RabbitMQ werden sie laut Lauf vor dem Cutover abgearbeitet. Für Kafka und RocketMQ nennt der Lauf kein Verfahren: Queue- und Topic-Dienste gelten nicht als zustandsbehaftet; wie Sie den Rückstand abarbeiten oder spiegeln, planen also Sie. Aufbewahrungsdauer und Rückstandsgröße stehen ebenfalls nicht im Terraform.
Schreibt der Lauf Terraform für die neuen Broker?
Nein. Für Alibaba-Cloud-Umgebungen schreibt dieser Build keine STACKIT-Ressourcenblöcke. Die drei Broker erscheinen als manuelle Schritte in einem Arbeitspaket.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.