Geeigneten Messaging Service identifizieren

Erfahren Sie, wie Sie einen Messaging-Service auswählen, und prüfen Sie dann anhand der Entscheidungsmatrixtabelle die verschiedenen Optionen und Einschränkungen der OCI-Services basierend auf Ihren Geschäftsanforderungen.

Überlegungen zum Auswählen eines Messaging-Service

Berücksichtigen Sie die folgenden Bewertungsfaktoren, um Ihre Entscheidung zu treffen.

Choreografie oder Orchestrierung

Choreographie und Orchestrierung sind zwei architektonische Ansätze, wie verschiedene entkoppelte Komponenten für die Zusammenarbeit organisiert werden. Die Choreographie nimmt das Prinzip an, dass jede Komponente unabhängig ausgeführt wird, hört aber auf und beobachtet nach Hinweisen, wann sie ihre nächste Aktion ausführen soll. Ein Message Broker überträgt die Hervorhebungen an die nächste Komponente. Komponenten können sehr autonom und einfach skalierbar sein. Der Nachteil besteht darin, dass jede Komponente ein besseres Verständnis ihrer Rolle in der Gesamtlösung erfordert und die Komplexität erhöht. Ein Message Broker ist ein wichtiges Element, und die Einfachheit reduziert die Workload und ermöglicht einen höheren Durchsatz.

Orchestrierung bezieht sich auf die Idee von Komponenten, die wie ein Orchester zusammengestellt wurden. Jede Komponente muss nur ihre Aufgabe kennen und dann warten, bis der Leiter oder Orchestrator sie zur Ausführung der Aktion auffordert. Der Leiter muss also verstehen und die Intelligenz haben, um alle Komponenten zu leiten. Die Leiterrolle ist wichtig und ihre Resilienz und Skalierbarkeit beeinflussen direkt die Skalierbarkeit und Resilienz der Gesamtlösung.

Einige Orchestrierungsprodukte umfassen die Möglichkeit, Choreografien (z. B. die Einbeziehung eines Brokers) oder Services zu erstellen, die Komponenten verwenden, um die Wirkung der vermittelten Kommunikation zu erzielen.

Zahlung pro Nachricht oder Ereignisse vs. Massenkauf

Berücksichtigen Sie die verschiedenen Zahlungsmodelle basierend auf den Kostenauswirkungen auf Ihre Lösung. Sie können pro Nachricht bezahlen, wenn Sie potenziell ungenutztes Nachrichtenvolumen bei einem Massenkauf haben. Beachten Sie, dass die Bezahlung pro Nachricht oder Ereignis zu einem höheren Volumen führen kann, da die Mindesthaltungskosten für einen Service auf weniger Verwendungen verteilt werden müssen.

Einzelne oder mehrere Nachrichten-Consumer

Der Unterschied zwischen einer Queue und einem Topic besteht darin, dass eine Nachricht nur einmal mit einer Queue konsumiert werden kann. Ein Thema kann viele verschiedene Verbraucher haben. Queues und Topics können viele Instanzen eines Consumer-Typs aufweisen. Mehrere Instanzen desselben Verbrauchertyps, die mit einem einzelnen Thema oder einer einzelnen Queue verbunden sind, werden häufig als Race-Bedingung beschrieben, wobei der nächste verfügbare Konsument die nächste verfügbare Nachricht erhält.

Nachrichtenaufbewahrung nach dem Lesen

Einige Nachrichten-Broker löschen eine Nachricht, sobald sie gelesen wurden (oder nachdem alle Verbraucher die Nachricht gelesen haben), um Ressourcen zu verwalten. Apache Kafka verfolgt, wie weit ein Consumer die Nachrichten durchlaufen hat, löscht sie jedoch nicht nach dem Lesen. Dadurch können Nachrichten wiedergegeben werden, wenn ein Problem auftritt. Daher fungiert Kafka als Datenspeicher sowie als Nachrichtenbroker und unterstützt das Erstellen von Datenanalysen für den Nachrichtendatenspeicher.

Garantierter Auftrag

Dadurch, dass Nachrichten in der Reihenfolge zugestellt werden, in der sie empfangen werden, wird die Performance beeinträchtigt, und nicht die Reihenfolge, in der sie gespeichert werden. Latenzprobleme können beim Durcharbeiten eines Brokers auftreten, da er warten kann, bevor Verbraucher eine Nachricht erhalten können, um sicherzustellen, dass es keine verzögerten Nachrichten gibt, die in die richtige Reihenfolge eingefügt werden müssen, bevor sie konsumiert werden.

Beispiel: Die Nachrichtenreihenfolge ist für Ereignisse von wesentlicher Bedeutung, die einen stornierten Auftrag darstellen. Die Nachricht für die Auftragserstellung hat das Potenzial, Anwendungsprobleme zu verursachen, wenn die Nachrichten nicht der Reihenfolge folgen.

Es gibt Muster und Strategien auf Anwendungsebene, die dazu beitragen können, Bestellprobleme zu mindern und Broker-Constraints auszugleichen.

Asynchroner Vorgang

Der Vorteil der Verwendung eines Broker-Mechanismus besteht darin, dass der Nachrichtenanbieter nichts über den Verbraucher wissen muss und den Anbieter nicht verlangsamt. Der Broker weiß, wer der Verbraucher ist, ob er verfügbar ist oder nicht, und verwaltet die Übertragung, wenn es Probleme mit dem Verbraucher (wie Leistung) gibt. Die Verwendung des Brokers ermöglicht die asynchrone Kommunikation, und Provider und Consumer müssen nicht synchron sein.

Maximale Nachrichtenrate, Aufbewahrungszeitraum für Nachrichten und maximales Aufbewahrungsvolumen

Diese Faktoren sind alle Influencer für die Kosten der Bereitstellung einer serverlosen Lösung und erfordern oft die Festlegung von harten Grenzen. Software bietet nicht immer eine einheitliche Leistung, da sie die Erwartungen skaliert. Sie können Limits festlegen, um Erwartungen zu kontrollieren und vorhersagbare Verhaltensweisen bereitzustellen. Sie müssen diese Limits verstehen, um zu bestimmen, ob sie sich auf die von Ihnen erstellte Lösung auswirken können.

Beispiel: Ein Aktienhandelssystem erhält Nachrichten, wenn sich die Aktienkurse ändern. Jede Nachricht ist klein, das Nachrichtenvolumen ist jedoch aufgrund der hohen Aktualisierungshäufigkeit hoch. Ein Broker mit einem niedrigen Durchsatz, aber einer großen Nachrichtengröße kann diese Anforderung nicht unterstützen.

Unterstützung für Eingabe nach Industriestandard und Ausgabe nach Industriestandard

Durch die Verwendung von branchenüblichen Formaten und Protokollen zum Senden und Empfangen von Nachrichten kann der Messaging-Mechanismus neu konfiguriert und mit verschiedenen Deployments und Implementierungsprovidern verwendet werden. Sie können allgemeine Bibliotheken nutzen, um die Low-Level-Kommunikationsmechanik zu verbessern und auch die Anbieterbindung zu reduzieren.

Unterstützung für Drittanbieteradapter

Um die Entwicklung von Nachrichtenanbietern und Verbrauchern zu unterstützen, kann die Unterstützung durch Drittanbieteradapter vorteilhaft sein, wenn die Entwicklungsoptionen erweitert werden.

Einzelne Deployments pro Compartment

Sie können einzelne Messagingkanäle oder -flüsse in bestimmten Compartments bereitstellen und den Services in einer Lösung über eine gemeinsame Steuerungsoberfläche feingranulierte, kollektive Sicherheitskontrollen ermöglichen. Bei diesem Ansatz wird davon ausgegangen, dass alle Elemente auf Compartment-Ebene gesteuert werden können. Die Lösungen, die keine Steuerelemente auf Compartment-Ebene pro Kanal berücksichtigen können, können Alternativen bieten. Alternative Ansätze können zusätzliche Konfigurationsaspekte erfordern.

OCI-IAM-Authentifizierung verwenden

Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) bietet eine robuste Sicherheitsebene der Unternehmensklasse, wenn Sicherheit mit anderen Providern föderiert werden kann. Durch die Arbeit mit einem einzelnen IAM-Provider (mit oder ohne Föderation) kann der Datenflusszugriff einfacher verwaltet werden.

Daten sind im Flug und im Ruhezustand verschlüsselt

Wenn die Daten, die den Dienst durchlaufen, empfindlich sind, müssen sie sowohl während der Übertragung als auch während der Aufbewahrung durch den Broker bis zur Lieferung geschützt werden. Sensible Nachrichten müssen vom Verschlüsselungsmechanismus des Brokers verschlüsselt werden, um keinen Nachrichtenverlust zu gewährleisten.

Transformation der Nachricht

Je nach den verwendeten Architekturprinzipien muss der Broker möglicherweise die Möglichkeit haben, die Nachrichtenformatierung zu übersetzen. Der Nachrichtenprovider oder die Consumer müssen weder allgemeine Datensemantik verstehen noch wissen, wie der Provider oder die Consumer die Daten formatieren möchten. Diese Überlegung kann sich auch auf Änderungen in den verwendeten Protokollen erstrecken. Beispiel: Übersetzung von REST in STOMP.

Protokoll

Um Probleme mit verteilten Anwendungen zu beheben, können Sie mit einem Audittrail verfolgen, von wo eine Nachricht gesendet und empfangen wurde. Ein Audittrail kann nützlich sein, wenn Sie die gesetzlichen Anforderungen erfüllen müssen. Daher ist es möglicherweise erforderlich, zu erfahren, wie der Service diese Anforderung unterstützen kann.

Entscheidungsmatrix prüfen

Verwenden Sie die folgende Entscheidungsmatrix, um mehr über die verfügbaren Optionen von OCI-Services und die Überlegungen oder Bewertungsfaktoren für die Auswahl eines bestimmten Service zu erfahren.

Service/Faktor	Queue	Streaming	Benachrichtigungen	Oracle Integration (Gen2, Gen3)	Autonomous Database (TEQ und AQ)
Choreografie und Orchestrierung	Choreografie	Choreografie	Choreografie	Choreografie und Orchestrierung (abhängig von der Integrationskonfiguration)	Choreografie und Orchestrierung (abhängig von der Integrationskonfiguration)
Zahlung pro Nachricht oder Ereignis im Vergleich zum Massenkauf	`Per API call + multiplier for messages > 64 KB`	`Per GB data transfer + Storage`	Abhängig vom Kommunikationskanal. Preise nach gesendeter Menge.	Preis in Blöcken mit 5000 Integrationsaufrufen pro Stunde	Nein, Database - Preise
Einzelner oder mehrere Consumer für eine Nachricht	Einzelner Nutzer. (Race-Bedingungen zulässig, aber nur ein Consumer pro Nachricht).	Einzel und mehrere	Einzel und mehrere	Einzeln und Mehrere (abhängig von der Integrationsdefinition)	Einzel und mehrere
Nachrichtenaufbewahrung nach dem Lesen	Nein	Ja	Nein	Ja (abhängig von der Integrationsdefinition)	Ja
Garantierte Bestellung	Beste Leistung	Ja, innerhalb einer Partition	Nein	Ja (abhängig von der Integrationsdefinition)	Teilweise (Regeln über Prioritäten können festgelegt werden, die eine Verbrauchsreihenfolge vorschreiben können)
Asynchroner Vorgang	Ja	Ja	Ja	Ja (abhängig von der Integrationsdefinition)	Ja
Für Input unterstützte Branchenstandards	REST-API, STOMP	Kafka Connect	Cloud-Ereignisse aus OCI-Ereignissen, Alarmen	Mehrere verschiedene Adapter	JMS und SQL Bieten Sie durch die Bereitstellung von REST-APIs ein zusätzliches Risiko für benutzerdefinierte ORDS-Implementierungen
Unterstützung für Drittanbieteradapter	Open Source STOMP-Implementierungen	Jedes Kafka-konforme Tool, jede Library oder ein SDK	Nein	Große Auswahl an Branchenadaptern. Sie können aus der REST-Schnittstelle oder einem Standard-JMS-Client generieren	Verwendung der Standard-JMS-Standard-Library SQL wird häufig unterstützt
Für Ausgaben unterstützte Branchenstandards	STOMP, REST-API	Kafka Connect	E-Mail, Slack, PagerDuty, HTTP/S	Mehrere verschiedene Adapter	JMS und SQL
Maximale Nachrichtenrate	10 MBIT/S	1 MB pro Sekunde pro Partition Bis zu 250 `GET`-Anforderungen pro Sekunde	60 pro Minute für HTTP/S 10 pro Minute für E-Mail 60 pro Minute für Benachrichtigungsthemen	Nichts angegeben	Abhängig von der Datenbankgröße
Nachrichtenaufbewahrungszeitraum	7 Tage (oder kürzer, wenn konfiguriert)	7 Tage	Bis zu erschöpften Zustellungsversuchen	Nichts definiert	Konfigurierbar
Maximale Aufbewahrungsdauer	2 GB pro Queue (20 GB pro Mandant)	Die Aufbewahrung unterliegt der maximalen Schreibrate von 1 MB pro Sekunde pro Partition für 7 Tage.	Die Funktion der Nachrichtenrate und der Wiederholungsdauer für die Zustellung.	Nicht verfügbar	Abhängig von Datenbankkonfiguration
Wird vom OCI-SDK oder der CLI zum Senden von Nachrichten unterstützt	Ja	Ja	Ja	Nein	Nein
Einzelne Deployments pro Compartment	Ja	Ja	Ja	Nein Auf Compartment-Ebene getrennte Oracle Integration-Instanzen, nicht einzelne Integrationen	Nein Datenbankinstanzen werden an Compartments ausgerichtet, nicht an einzelne Queues
Verwendet IAM-Authentifizierung (RBAC usw.)	Ja	Ja	Ja	Ja	Ja
Daten werden im Flug und im Ruhezustand verschlüsselt	Ja	Ja	Ja	Ja	Abhängig von Datenbankkonfiguration
Nachrichtentransformation	Nein	Nein	Begrenzt. Benutzerfreundliche Formatierung für E-Mails usw. Wenn der Endpunkt Oracle Functions verwendet, kann Functions die Nachricht transformieren.	Ja	Ja (gespeicherte SQL-Prozeduren)
Protokoll	Ja (mit Logging)	Ja (mit Logging)	Ja (mit Logging)	Ja (umfasst Oracle Integration mit Logging)	Ja

Sie können die Matrix anhand der folgenden Informationen interpretieren:

Zahlungsmodell: Bezieht sich auf eine Nachricht oder einen Massenkauf von Kapazität.
Gespeicherte Bedingung: Wenn eine Queue mehrere Consumer enthält, werden die Consumer als "Verfolgungsbedingung" bezeichnet, weil die nächsten Nachrichten vom Consumer verarbeitet werden, der zuerst für eine andere Nachricht bereit ist.
REST-basierte Endpunkte: Einige der Services bieten REST-basierte Endpunkte. Wenn die REST-Payload mit einer Open API-Spezifikation modelliert wird, wird möglicherweise kein Payload-spezifisches SDK bereitgestellt. In solchen Fällen können Sie API-Gateway-Services verwenden, um SDKs zu generieren. Weitere Informationen finden Sie in der OCI-Dokumentation zum Generieren von SDKs für eine API-Ressource.

Neben den OCI-Services bezieht sich die Matrix auf folgende Technologien:

STOMP: Einfaches (oder Streaming) textorientiertes Messaging-Protokoll. Es bietet ein interoperables Drahtformat, mit dem STOMP-Clients mit jedem STOMP-Nachrichtenbroker kommunizieren können, um eine einfache und weit verbreitete Messaginginteroperabilität zwischen vielen Sprachen, Plattformen und Brokern bereitzustellen.
STOMP-Implementierungen: Bezieht sich auf die bekannten STOMP-konformen Nachrichtenserver.
Kafka Connect: Mit diesem Tool können Sie Daten zwischen Apache Kafka und anderen Systemen zuverlässig streamen und skalieren. Ermöglicht die schnelle Definition von Connectors, die große Datenmengen in und aus Kafka verschieben.

Weitere Informationen zu den Technologien finden Sie im Abschnitt Erfahren.