Freigeben über

Architekturansätze für das Messaging in mehrinstanzenfähigen Lösungen

  • Artikel

Asynchrones Messaging und ereignisgesteuerte Kommunikation sind wichtige Ressourcen beim Erstellen einer verteilten Anwendung, die mehrere interne und externe Diensten umfasst. Wenn Sie eine mehrinstanzenfähige Lösung entwerfen, ist es wichtig, eine Vorabanalyse durchzuführen, um zu definieren, wie Nachrichten für verschiedene Mandanten gemeinsam verwendet oder partitioniert werden.

Die gemeinsame Nutzung desselben Messagingsystems oder Ereignisstreamingdiensts kann die Betriebskosten und die Komplexität der Verwaltung erheblich reduzieren. Die Verwendung eines dedizierten Messagingsystems für jeden Mandanten bietet hingegen eine bessere Datenisolation, verringert das Risiko von Datenlecks, beseitigt das Noisy Neighbor-Problem und ermöglicht es, Ihre Azure-Kosten problemlos für Ihre Mandanten in Rechnung zu stellen.

In diesem Artikel finden Sie die Unterschiede zwischen Nachrichten und Ereignissen sowie Richtlinien, mit denen Lösungsarchitekt*innen entscheiden können, welcher Ansatz für die Messaging- oder Ereignisinfrastruktur in einer mehrinstanzenfähigen Lösung verwendet werden soll.

Nachrichten, Datenpunkte und diskrete Ereignisse

Alle Messagingsysteme verfügen über ähnliche Funktionen, Transportprotokolle und Anwendungsszenarien. Beispielsweise unterstützen die meisten modernen Messagingsysteme die asynchrone Kommunikation, flüchtige oder dauerhafte Warteschlangen, AMQP- und HTTPS-Transportprotokolle, die mindestens einmalige Übermittlung (At-Least-Once) usw. Ein genauerer Blick auf den Typ der veröffentlichten Informationen und die Art und Weise, wie Daten von Clientanwendungen verwendet und verarbeitet werden, ermöglicht jedoch eine genauere Unterscheidung der verschiedenen Typen von Nachrichten und Ereignissen. Es gibt einen wesentlichen Unterschied zwischen Diensten, die ein Ereignis übermitteln, und Systemen, die Nachrichten senden. Weitere Informationen finden Sie in den folgenden Ressourcen:

Ereignisse

Ein Ereignis ist eine einfache Benachrichtigung über eine Bedingung oder eine Zustandsänderung. Ereignisse können eigenständige Einheiten oder Teil einer Reihe sein. Ereignisse sind Nachrichten, die im Allgemeinen vom Herausgebers ausschließlich zu Informationszwecken ausgegeben werden. Mit einem Ereignis wird ein Fakt erfasst und an andere Dienste oder Komponenten weitergegeben. Ein Consumer des Ereignisses kann das Ereignis nach Bedarf verarbeiten, ohne damit spezielle Erwartungen des Herausgebers erfüllen zu müssen. Ereignisse können in zwei Hauptkategorien klassifiziert werden:

  • Diskrete Ereignisse enthalten Informationen zu bestimmten Aktionen, die von der veröffentlichenden Anwendung ausgeführt wurden. Bei Verwendung der asynchronen, ereignisgesteuerten Kommunikation veröffentlicht eine Anwendung ein Benachrichtigungsereignis, wenn etwas innerhalb ihres Bereichs passiert. Eine oder mehrere Consumeranwendungen sollen über diese Zustandsänderung informiert werden (z. B. bei einer Preisänderung in einer Produktkataloganwendung). Consumer abonnieren die Ereignisse, um sie asynchron zu empfangen. Wenn ein bestimmtes Ereignis eintritt, können die Consumeranwendungen die Entitäten in ihrem Bereich aktualisieren. Dies zu weiteren Veröffentlichungen von Integrationsereignissen führen.
  • Reihenereignisse enthalten Informationsdatenpunkte, z. B. Temperaturwerte von Geräten für die Analyse oder Benutzeraktionen in einer Klickanalyselösung, als Elemente in einem fortlaufenden Datenstrom. Ein Ereignisdatenstrom steht in einem bestimmten Kontext, z. B. die Temperatur oder Luftfeuchtigkeit, die von einem Feldgerät gemeldet werden. Alle Ereignisse im Zusammenhang mit demselben Kontext haben eine strenge zeitliche Reihenfolge. Dies ist wichtig, wenn die Ereignisse mit einer Verarbeitungs-Engine für Ereignisdatenströme verarbeitet werden. Zum Analysieren von Ereignisdatenströmen mit Datenpunkten müssen diese Ereignisse in einem Puffer gesammelt werden, der ein gewünschtes Zeitfenster abdeckt. Die Ereignisse können auch in einer festgelegten Anzahl von Elementen erfasst und dann mithilfe einer Lösung in Quasi-Echtzeit oder eines ML-Algorithmus verarbeitet werden. Die Analyse einer Ereignisreihe kann zu Signalen führen, z. B. dem Durchschnitt eines Werts, der über ein Zeitfenster gemessen wird und einen Schwellenwert überschreitet. Diese Signale können dann als diskrete, handlungsrelevante Ereignisse ausgelöst werden.

Diskrete Ereignisse geben Statusänderungen an und erfordern Aktionen. Die Ereignisnutzdaten enthalten im Allgemeinen nur Informationen darüber, was passiert ist, aber nicht die vollständigen Daten, die das Ereignis ausgelöst haben. Beispielsweise kann ein Ereignis Consumer benachrichtigen, dass eine Berichterstellungsanwendung eine neue Datei in einem Speicherkonto erstellt hat. Die Ereignisnutzdaten können allgemeine Informationen zu der Datei enthalten, aber nicht die eigentliche Datei. Eigenständige Ereignisse eignen sich ideal für serverlose Lösungen, die skaliert werden müssen.

Reihenereignisse geben eine Bedingung an und können analysiert werden. Diskrete Ereignisse sind nach Zeit sortiert und voneinander abhängig. In einigen Kontexten muss der Consumer die vollständige Abfolge von Ereignissen empfangen, um analysieren zu können, was passiert ist, und die erforderlichen Maßnahmen zu ergreifen.

Meldungen

Bei einer Nachricht handelt es sich um Rohdaten, die von einem Dienst erzeugt wurden und an anderer Stelle genutzt und gespeichert werden sollen. Nachrichten enthalten häufig Informationen, die für den empfangenden Dienst zum Ausführen von Schritten in einem Workflow oder einer Verarbeitungskette erforderlich sind. Ein Beispiel für diese Art der Kommunikation ist das Befehlsmuster. Der Herausgeber erwartet möglicherweise auch, dass die Empfänger einer Nachricht eine Reihe von Aktionen ausführen und das Ergebnis ihrer Verarbeitung in einer asynchronen Nachricht melden. Zwischen dem Nachrichtenherausgeber und den Nachrichtenempfängern besteht ein Vertrag. Beispiel: Der Herausgeber sendet eine Nachricht mit Rohdaten und erwartet, dass der Consumer eine Datei aus den Daten erstellt und eine Antwort sendet, wenn dies abgeschlossen ist. In anderen Situationen kann ein Absenderprozess eine asynchrone, unidirektionale Nachricht senden, um einen anderen Dienst um die Durchführung eines bestimmten Vorgangs zu bitten, ohne jedoch davon auszugehen, dass er eine Bestätigungs- oder Antwortnachricht zurück erhält.

Diese Form der vertraglichen Nachrichtenverarbeitung unterscheidet sich deutlich von einem Herausgeber, der diskrete Ereignisse für eine Zielgruppe von Consumer-Agents veröffentlicht, ohne dass eine bestimmte Erwartung an die Verarbeitung dieser Benachrichtigungen besteht.

Beispielszenarien

Im Folgenden finden Sie eine Liste einiger Beispiele für Mehrmandantenszenarien für Nachrichten, Datenpunkte und diskrete Ereignisse:

  • Diskrete Ereignisse:
    • Eine Sharingplattform für Musik verfolgt nach, ob bestimmte Benutzer*innen eines bestimmten Mandanten einen speziellen Musiktitel angehört haben.
    • In der Webanwendung eines Onlineshops sendet die Kataloganwendung ein Ereignis mithilfe des Herausgeber-Abonnent-Muster an andere Anwendungen, um diese zu benachrichtigen, dass sich ein Artikelpreis geändert hat.
    • Ein Fertigungsunternehmen pusht Echtzeitinformationen zu Gerätewartung, Systemzustand und Vertragsupdates an die eigene Kundschaft und an Dritte.
  • Datenpunkte:
    • Ein Gebäudesteuerungssystem empfängt Telemetrieereignisse wie Temperatur- oder Luftfeuchtigkeitswerte von Sensoren, die zu mehreren Kund*innen gehören.
    • Ein ereignisgesteuertes Überwachungssystem empfängt und verarbeitet Diagnoseprotokolle in Quasi-Echtzeit von mehreren Diensten (z. B. Webservern).
    • Ein clientseitiges Skript auf einer Webseite sammelt Benutzeraktionen und sendet sie an eine Klickanalyselösung.
  • Nachrichten:
    • Eine B2B-Finanzanwendung empfängt eine Nachricht, um mit der Verarbeitung der Bankdatensätze eines Mandanten zu beginnen.
    • Ein Workflow mit langer Ausführungszeit empfängt eine Nachricht, mit der die Ausführung des nächsten Schritts ausgelöst wird.
    • Die Warenkorbanwendung einer Onlineshopanwendung sendet einen CreateOrder-Befehl mithilfe einer asynchronen, persistenten Nachricht an die Bestellanwendung.

Wesentliche Aspekte und Anforderungen

Das Bereitstellungs- und Mandantenmodell, das Sie für Ihre Lösung auswählen, hat einen erheblichen Einfluss auf Sicherheit, Leistung, Datenisolation und Verwaltung und bietet die Möglichkeit, Ressourcenkosten für Mandanten einzeln zu berechnen. Diese Analyse umfasst auch das Modell, das Sie für Ihre Messaging- und Ereignisinfrastruktur auswählen. In diesem Abschnitt werden einige der wichtigsten Entscheidungen beschrieben, die Sie treffen müssen, wenn Sie ein Messagingsystem in Ihrer mehrinstanzenfähige Lösung planen.

Skalieren

Die Anzahl der Mandanten, die Komplexität von Nachrichtenflows und Ereignisdatenströmen, die Nachrichtenmenge, das erwartete Datenverkehrsprofil und die Isolationsstufe sollten für Entscheidungen bei der Planung einer Messaging- oder Ereignisinfrastruktur herangezogen werden.

Der erste Schritt besteht darin, eine umfassende Kapazitätsplanung durchzuführen und die erforderliche maximale Kapazität für ein Messagingsystem im Hinblick auf den Durchsatz zu ermitteln, damit die zu erwartende Nachrichtenmenge bei regulärem Betrieb oder zu Spitzenzeiten ordnungsgemäß verarbeitet werden kann.

Einige Dienstangebote, z. B. die Dienstebene Azure Service Bus Premium, bieten Ressourcenisolation auf CPU- und Arbeitsspeicherebene, sodass jede Kundenworkload isoliert ausgeführt wird. Dieser Ressourcencontainer wird als Messaging-Einheit bezeichnet. Jedem Premium-Namespace wird mindestens eine Messaging-Einheit zugeordnet. Sie können 1, 2, 4, 8 oder 16 Messagingeinheiten für jeden Service Bus Premium-Namespace erwerben. Eine einzelne Workload oder Entität kann mehrere Messagingeinheiten umfassen, und Sie können die Anzahl der Messagingeinheiten an Ihren Bedarf anpassen. Das Ergebnis ist eine vorhersagbare und wiederholbare Leistung Ihrer Service Bus-basierten Lösung. Weitere Informationen finden Sie unter Service Bus Premium- und Standard-Preisstufe für Messaging. Ebenso ermöglichen die Azure Event Hubs-Tarife das Anpassen der Namespacegröße basierend auf dem erwarteten Volumen ein- und ausgehender Ereignisse. Das Premium-Angebot wird z. B. nach Verarbeitungseinheiten (Processing Units, PUs) abgerechnet, die einem Anteil isolierter Ressourcen (CPU, Arbeitsspeicher und Speicher) der zugrunde liegenden Infrastruktur entsprechen. Der effektive Erfassungs- und Datenstromdurchsatz pro PU hängt von den folgenden Faktoren ab:

  • Anzahl von Producern und Consumern
  • Größe der Nutzdaten
  • Partitionsanzahl
  • Anforderungsrate für ausgehenden Datenverkehr
  • Nutzung von Event Hubs Capture, Schemaregistrierung und anderen erweiterten Features

Weitere Informationen finden Sie unter Übersicht über Event Hubs Premium.

Wenn Ihre Lösung eine sehr hohe Anzahl von Mandanten verarbeitet und Sie sich für die Einführung eines separaten Messagingsystems für jeden Mandanten entscheiden, benötigen Sie eine konsistente Strategie, um Bereitstellung, Überwachung, Warnung und Skalierung der einzelnen Infrastrukturen getrennt voneinander zu automatisieren.

Beispielsweise kann ein Messagingsystem für einen bestimmten Mandanten während des Bereitstellungsprozesses mithilfe eines IaC-Tools (Infrastructure-as-Code) wie Terraform-, Bicep- oder ARM-JSON-Vorlagen (Azure Resource Manager) und einem DevOps-System wie Azure DevOps oder GitHub Actions bereitgestellt werden. Weitere Informationen finden Sie unter Architekturansätze für die Bereitstellung und Konfiguration mehrinstanzenfähiger Lösungen.

Das Messagingsystem kann mit einem maximalen Durchsatz in Nachrichten pro Zeiteinheit dimensioniert werden. Wenn das System die dynamische automatische Skalierung unterstützt, kann seine Kapazität basierend auf den Bedingungen und Metriken des Datenverkehrs automatisch erhöht oder verringert werden, um die erwartete Vereinbarung zum Servicelevel (SLA) zu erfüllen.

Vorhersagbarkeit und Zuverlässigkeit der Leistung

Beim Entwerfen und Erstellen eines Messagingsystems für eine begrenzte Anzahl von Mandanten kann die Verwendung eines einzelnen Messagingsystems eine hervorragende Lösung sein, um die funktionalen Anforderungen an den Durchsatz zu erfüllen und die Gesamtkosten senken. Eine mehrinstanzenfähige Anwendung kann die gleichen Messagingentitäten wie Warteschlangen und Themen für mehrere Kund*innen gemeinsam verwenden. Ebenso könnten dedizierte Komponenten für jede Entität verwendet werden, um die Mandantenisolation zu erhöhen. Auf der anderen Seite kann die gemeinsame Nutzung derselben Messaginginfrastruktur für mehrere Mandanten zum Noisy Neighbor-Problem für die gesamte Lösung führen. Die Aktivität eines Mandanten kann die Leistung und Funktionsfähigkeit für andere Mandanten beeinträchtigen.

In diesem Fall sollte das Messagingsystem ordnungsgemäß dimensioniert werden, um die zu erwartende Datenverkehrslast auch zu Spitzenzeiten zu unterstützen. Im Idealfall sollte die automatische Skalierung unterstützt werden. Das Messagingsystem sollte dynamisch aufskaliert werden, wenn der Datenverkehr zunimmt, und bei geringerem Datenverkehr abskaliert werden. Ein dediziertes Messagingsystem für jeden Mandanten kann auch das Noisy Neighbor-Risiko verringern, aber die Verwaltung einer großen Anzahl von Messagingsystemen erhöht die Komplexität der Lösung.

Für eine mehrinstanzenfähige Anwendung kann auch ein Hybridansatz genutzt werden, bei dem Kerndienste für die interne, asynchrone Kommunikation dieselben Warteschlangen und Themen in einem einzelnen, gemeinsamen Messagingsystem verwenden. Im Gegensatz dazu könnten andere Dienste dedizierte Messagingentitäten oder sogar ein dediziertes Messagingsystem für jeden Mandanten nutzen, um das Noisy Neighbor-Problem zu beheben und die Datenisolation zu gewährleisten.

Wenn Sie ein Messagingsystem auf VMs bereitstellen, sollten Sie diese mit den Computeressourcen am selben Ort bereitstellen, um die Netzwerklatenz zu reduzieren. Diese VMs sollten nicht mit anderen Diensten oder Anwendungen gemeinsam genutzt werden, um zu vermeiden, dass die Messaginginfrastruktur mit anderen Systemen um Systemressourcen wie CPU, Arbeitsspeicher und Netzwerkbandbreite konkurrieren muss. VMs können auch auf Verfügbarkeitszonen verteilt werden, um die Resilienz und Zuverlässigkeit von unternehmenskritischen Workloads (zu denen auch die Messagingsysteme gehören) innerhalb der Region zu erhöhen. Angenommen, Sie möchten ein Messagingsystem wie RabbitMQ oder Apache ActiveMQ auf VMs hosten. In diesem Fall empfiehlt es sich, sie in einer VM-Skalierungsgruppe bereitzustellen und für die automatische Skalierung basierend auf Metriken wie CPU oder Arbeitsspeicher zu konfigurieren. Auf diese Weise wird die Anzahl der Agent-Knoten, die das Messagingsystem hosten, ordnungsgemäß basierend auf den Datenverkehrsbedingungen auf- und abskaliert. Weitere Informationen finden Sie unter Übersicht über die automatische Skalierung mit Azure-VM-Skalierungsgruppen.

Ebenso sollten Sie beim Hosten von Messagingsystemen in einem Kubernetes-Cluster die Verwendung von Knotenselektoren und Taints in Betracht ziehen, um die Ausführung ihrer Pods in einem dedizierten Knotenpool zu planen, der nicht für andere Workloads genutzt wird, und damit das Noisy Neighbor-Problem zu vermeiden. Wenn Sie ein Messagingsystem in einem zonenredundanten AKS-Cluster bereitstellen, verwenden Sie Verteilungseinschränkungen für die Podtopologie, um zu steuern, wie Pods in Ihrem AKS-Cluster auf Fehlerdomänen wie Regionen, Verfügbarkeitszonen und Knoten verteilt werden. Verwenden Sie beim Hosten von Messagingsystemen von Drittanbietern in AKS die automatische Kubernetes-Skalierung, um die Anzahl der Workerknoten dynamisch aufzuskalieren, wenn der Datenverkehr zunimmt. Mit der horizontalen automatischen Podskalierung und einer automatischen AKS-Clusterskalierung werden Knoten- und Podvolumes in Echtzeit dynamisch angepasst, um den Datenverkehr zu bewältigen und Ausfallzeiten zu vermeiden, die aufgrund von Kapazitätsproblemen entstehen. Weitere Informationen finden Sie unter Automatisches Skalieren eines Clusters zur Erfüllung von Anwendungsanforderungen in Azure Kubernetes Service (AKS). Erwägen Sie die Verwendung von Kubernetes Event-Driven Autocaling (KEDA) (Ereignisgesteuerte automatische Kubernetes-Skalierung), wenn Sie die Anzahl der Pods eines in Kubernetes gehosteten Messagingsystems (z. B. RabbitMQ oder Apache ActiveMQ) basierend auf der Länge einer bestimmten Warteschlange aufskalieren möchten. Mit KEDA können Sie die Skalierung beliebiger Container in Kubernetes basierend auf der Anzahl der Ereignisse steuern, die verarbeitet werden müssen. Beispielsweise können Sie mit KEDA Anwendungen basierend auf der Länge einer Azure Service Bus-Warteschlange, einer RabbitMQ-Warteschlange oder einer ActiveMQ-Warteschlange skalieren. Weitere Informationen zu KEDA finden Sie unter Kubernetes Event-driven Autoscaling (Ereignisgesteuerte automatische Kubernetes-Skalierung).

Isolation

Sie sollten beim Entwerfen des Messagingsystems für eine mehrinstanzenfähige Lösung berücksichtigen, dass verschiedene Anwendungstypen eine spezifische Isolation erfordern, die auf den Leistungs-, Datenschutz- und Überwachungsanforderungen der Mandanten basiert.

  • Mehrere Mandanten können die gleichen Messagingentitäten wie Warteschlangen, Themen und Abonnements im selben Messagingsystem gemeinsam verwenden. Beispielsweise könnte eine mehrinstanzenfähige Anwendung Nachrichten, die Daten für mehrere Mandanten enthalten, aus einer einzelnen Azure Service Bus-Warteschlange empfangen. Diese Lösung kann zu Problemen mit der Leistung und Skalierbarkeit führen. Wenn einige Mandanten eine größere Anzahl von Ereignissen generieren als andere, kann dies zu einem Nachrichtenrückstand führen. Dieses Problem, das auch als Noisy Neighbor-Problem bezeichnet wird, kann die Vereinbarung zum Servicelevel in Bezug auf die Latenz für einige Mandanten beeinträchtigen. Das Problem wird noch offensichtlicher, wenn die Consumeranwendung Nachrichten aus der Warteschlange in einer strengen chronologischen Reihenfolge liest und verarbeitet und die Zeit, die zum Verarbeiten einer Nachricht erforderlich ist, von der Anzahl der Elemente in den Nutzdaten abhängt. Wenn Sie eine oder mehrere Warteschlangenressourcen für mehrere Mandanten gemeinsam nutzen, sollten die Messaginginfrastruktur und die Verarbeitungssysteme in der Lage sein, die Skalierungs- und Durchsatzanforderungen basierend auf dem zu erwartenden Datenverkehr zu erfüllen. Dieser Architekturansatz eignet sich gut für Szenarien, in denen eine mehrinstanzenfähige Lösung einen einzelnen Pool von Workerprozessen übernimmt, um Nachrichten für alle Mandanten zu empfangen, zu verarbeiten und zu senden.
  • Mehrere Mandanten nutzen dasselbe Messagingsystem gemeinsam, verwenden jedoch unterschiedliche Themen- oder Warteschlangenressourcen. Dieser Ansatz bietet eine höhere Isolation und einen besseren Datenschutz – allerdings zu höheren Kosten, mit einer höheren Komplexität im Betrieb und einer geringeren Flexibilität, da Systemadministrator*innen eine höhere Anzahl von Warteschlangenressourcen bereitstellen, überwachen und verwalten müssen. Diese Lösung gewährleistet eine konsistente und vorhersagbare Erfahrung für alle Mandanten in Bezug auf die Leistung und Vereinbarungen zum Servicelevel, da sie verhindert, dass ein Mandant einen Engpass verursacht, der sich auf die anderen Mandanten auswirken kann.
  • Für jeden Mandanten wird ein separates, dediziertes Messagingsystem verwendet. Eine mehrinstanzenfähige Lösung kann z. B. für jeden Mandanten einen eigenen Azure Service Bus-Namespace verwenden. Diese Lösung bietet den maximalen Isolationsgrad bei höherer Komplexität und höheren Betriebskosten. Dieser Ansatz garantiert eine konsistente Leistung und ermöglicht eine Feinabstimmung des Messagingsystems basierend auf bestimmten Mandantenanforderungen. Beim Onboarding eines neuen Mandanten muss die Bereitstellungsanwendung zusätzlich zu einem vollständig dedizierten Messagingsystem möglicherweise auch eine separate verwaltete Identität oder einen Dienstprinzipal mit den richtigen RBAC-Berechtigungen für den Zugriff auf den neu erstellten Namespace erstellen. Wenn ein Kubernetes-Cluster beispielsweise von mehreren Instanzen derselben SaaS-Anwendung gemeinsam genutzt wird (eine für jeden Mandanten), die jeweils in einem separaten Namespace ausgeführt werden, kann jede Anwendungsinstanz einen anderen Dienstprinzipal oder eine andere verwaltete Identität verwenden, um auf ein dediziertes Messagingsystem zuzugreifen. In diesem Kontext kann das Messagingsystem ein vollständig verwalteter PaaS-Dienst sein, z. B. ein Azure Service Bus-Namespace oder ein in Kubernetes gehostetes Messagingsystem wie RabbitMQ. Beim Löschen eines Mandanten aus dem System sollte die Anwendung das Messagingsystem und alle dedizierten Ressourcen entfernen, die zuvor für den Mandanten erstellt wurden. Der Hauptnachteil dieses Ansatzes ist, dass er die Komplexität im Betrieb erhöht und die Flexibilität verringert, insbesondere wenn die Anzahl der Mandanten im Lauf der Zeit zunimmt.

Weitere Überlegungen und Beobachtungen:

  • Wenn Mandanten ihren eigenen Schlüssel zum Ver- und Entschlüsseln von Nachrichten verwenden müssen, sollte eine mehrinstanzenfähige Lösung die Möglichkeit bieten, einen separaten Azure Service Bus Premium-Namespace für jeden Mandanten zu verwenden. Weitere Informationen finden Sie unter Konfigurieren von kundenseitig verwalteten Schlüsseln für die Verschlüsselung von ruhenden Azure Service Bus-Daten.
  • Wenn Mandanten einen hohen Grad an Resilienz und Geschäftskontinuität benötigen, sollte eine mehrinstanzenfähige Lösung die Möglichkeit bieten, einen Service Bus Premium-Namespace mit aktivierter georedundanter Notfallwiederherstellung und Verfügbarkeitszonen bereitzustellen. Weitere Informationen finden Sie unter Georedundante Notfallwiederherstellung in Azure Service Bus.
  • Wenn Sie separate Warteschlangenressourcen oder ein dediziertes Messagingsystem für jeden Mandanten verwenden, ist es sinnvoll, für jeden einen separaten Pool von Workerprozessen zu verwenden, um die Datenisolationsstufe zu erhöhen und die Komplexität der Verarbeitung mit mehreren Messagingentitäten zu reduzieren. Jede Instanz des Verarbeitungssystems könnte unterschiedliche Anmeldeinformationen verwenden, z. B. eine Verbindungszeichenfolge, einen Dienstprinzipal oder eine verwaltete Identität, um auf das dedizierte Messagingsystem zuzugreifen. Dieser Ansatz bietet eine höhere Sicherheitsstufe und Isolation zwischen Mandanten, führt jedoch auch zu einer höheren Komplexität bei der Identitätsverwaltung.

Auf die gleiche Weise kann eine ereignisgesteuerte Anwendung verschiedene Isolationsstufen bereitstellen:

  • Eine ereignisgesteuerte Anwendung empfängt Ereignisse von mehreren Mandanten über eine einzelne, gemeinsam verwendete Azure Event Hubs-Instanz. Diese Lösung bietet ein hohes Maß an Flexibilität, da für das Onboarding neuer Mandanten keine dedizierten Ressourcen für die Ereigniserfassung erstellt werden müssen. Sie bietet jedoch eine niedrige Datenschutzebene, da Nachrichten von mehreren Mandanten in derselben Datenstruktur miteinander vermischt werden.
  • Mandanten können einen dedizierten Event Hub oder ein Kafka-Thema verwenden, um das Noisy Neighbor-Problem zu vermeiden und ihre Datenisolationsanforderungen zu erfüllen, wenn Ereignisse aus Sicherheits- und Datenschutzgründen nicht mit denen anderer Mandanten vermischt werden dürfen.
  • Wenn Mandanten einen hohen Grad an Resilienz und Geschäftskontinuität benötigen, sollte eine mehrinstanzenfähige Lösung die Möglichkeit bieten, einen Event Hubs Premium-Namespace mit aktivierter georedundanter Notfallwiederherstellung und Verfügbarkeitszonen bereitzustellen. Weitere Informationen finden Sie unter Azure Event Hubs: Georedundante Notfallwiederherstellung.
  • Dedizierte Event Hubs mit aktiviertem Event Hubs Capture sollten für solche Kund*innen erstellt werden, die Ereignisse aus gesetzlichen Gründen und für die Compliance in einem Azure Storage-Konto archivieren müssen. Weitere Informationen finden Sie unter Erfassen von Ereignissen über Azure Event Hubs in Azure Blob Storage oder Azure Data Lake Storage.
  • Eine einzelne mehrinstanzenfähige Anwendung kann mithilfe von Azure Event Grid Benachrichtigungen an mehrere interne und externe Systeme senden. In diesem Fall sollte ein separates Event Grid-Abonnement für jede Consumeranwendung erstellt werden. Wenn Ihre Anwendung mehrere Event Grid-Instanzen verwendet, um Benachrichtigungen an eine große Anzahl externer Organisationen zu senden, sollten Sie die Verwendung von Ereignisdomänen in Erwägung ziehen, die einer Anwendung ermöglichen, Ereignisse an Tausende von Themen zu veröffentlichen, z. B. an eines für jeden Mandanten. Weitere Informationen finden Sie unter Grundlegendes zu Ereignisdomänen für die Verwaltung von Event Grid-Themen.

Komplexität der Implementierung

Beim Entwerfen einer mehrteiligen Lösung ist es wichtig zu berücksichtigen, wie sich das System mittel- bis langfristig weiterentwickeln wird, damit seine Komplexität im Lauf der Zeit nicht so stark zunimmt, dass die gesamte Lösung oder ein Teil davon neu entwickelt werden muss. Diese Neugestaltung hilft Ihnen bei der Verarbeitung einer zunehmenden Anzahl von Mandanten. Beim Entwerfen eines Messagingsystems sollten Sie die zu erwartende Zunahme von Nachrichtenvolumen und Mandanten in den nächsten Jahren berücksichtigen und dann ein System erstellen, das aufskaliert werden kann, um mit dem vorhergesagten Datenverkehr Schritt zu halten, und dass gleichzeitig die Komplexität von Vorgängen wie Bereitstellung, Überwachung und Wartung reduziert.

Die Lösung sollte die erforderlichen Messagingentitäten automatisch erstellen oder löschen, wenn eine Mandantenanwendung bereitgestellt oder ihre Bereitstellung aufgehoben wird, ohne dass manuelle Maßnahmen erforderlich sind.

Ein besonderes Anliegen bei mehrinstanzenfähigen Datenlösungen ist der von Ihnen unterstützte Grad der Anpassung. Alle Anpassungen sollten automatisch konfiguriert und vom Anwendungsbereitstellungssystem (z. B. einem DevOps-System) angewandt werden und auf einer Reihe von anfänglichen Parametern basieren, wenn eine Anwendung mit nur einem Mandanten oder mehreren Mandanten bereitgestellt wird.

Komplexität von Verwaltung und Betrieb

Planen Sie von Anfang an, wie Sie Ihre Messaging- und Ereignisinfrastruktur ausführen, überwachen und warten möchten und wie sich Ihr mehrinstanzenfähiger Ansatz auf den Betrieb und Ihre Prozesse auswirkt. Betrachten Sie beispielsweise die folgenden Möglichkeiten:

  • Möglicherweise planen Sie, das Messagingsystem, das von Ihrer Anwendung verwendet wird, auf dedizierten VMs zu hosten (jeweils eine für jeden Mandanten). Wenn ja, wie planen Sie, diese Systeme bereitzustellen, zu aktualisieren, zu überwachen und aufzuskalieren?
  • Ebenso müssen Sie sich fragen, wie Sie einzelne Messagingsysteme bereitstellen, aktualisieren, überwachen und aufskalieren, wenn Sie Ihr Messagingsystem in Containern in einem freigegebenen Kubernetes-Cluster hosten.
  • Angenommen, Sie verwenden ein Messagingsystem für mehrere Mandanten. Wie kann Ihre Lösung die Nutzungsmetriken pro Mandant erfassen und melden oder die Anzahl von Nachrichten drosseln, die jeder Mandant senden oder empfangen kann?
  • Wenn Ihr Messagingsystem einen PaaS-Dienst nutzt (z. B. Azure Service Bus), stellen Sie die folgenden Fragen:
  • Wie migrieren Sie Mandanten, wenn diese auf einen anderen Messagingdiensttyp, eine andere Bereitstellung oder eine andere Region umgestellt werden müssen?

Kosten

Im Allgemeinen gilt: Je höher die Dichte der Mandanten in Ihrer Bereitstellungsinfrastruktur, desto geringer die Kosten für deren Bereitstellung. Die gemeinsam genutzte Infrastruktur erhöht jedoch die Wahrscheinlichkeit von Problemen wie Noisy Neighbor. Berücksichtigen Sie daher die Nachteile sorgfältig.

Zu berücksichtigende Ansätze und Muster

Mehrere Cloudentwurfsmuster aus dem Azure Architecture Center können auf ein mehrinstanzenfähiges Messagingsystem angewandt werden. Sie können entweder ein oder mehrere Muster konsistent befolgen, oder Sie können erwägen, Muster basierend auf Ihren Anforderungen zu kombinieren und anzupassen. Beispielsweise können Sie einen mehrinstanzenfähigen Service Bus-Namespace für die meisten Ihrer Mandanten verwenden, aber dann einen dedizierten Service Bus-Namespace für einzelne Mandanten bereitstellen, wenn diese mehr bezahlen oder höhere Anforderungen an die Isolierung und Leistung stellen. Ebenso ist es oft sinnvoll, die Skalierung mithilfe von Bereitstellungsstempeln vorzunehmen, selbst wenn Sie einen mehrinstanzenfähigen Service Bus-Namespace oder dedizierte Namespaces innerhalb eines Stempels verwenden.

Muster mit Bereitstellungsstempeln

Weitere Informationen zum Muster mit Bereitstellungsstempeln und zur Mehrinstanzenfähigkeit finden Sie im Abschnitt zum Muster mit Bereitstellungsstempeln in den Architekturansätzen für Mehrinstanzenfähigkeit. Weitere Informationen zu Mandantenmodellen finden Sie unter Zu berücksichtigende Mandantenmodelle für eine mehrinstanzenfähige Lösung.

Gemeinsames Messagingsystem

Sie können ein gemeinsam genutztes Messagingsystem wie Azure Service Bus für alle Ihre Mandanten bereitstellen.

Das Diagramm zeigt ein einzelnes gemeinsam genutztes Multi-Tenant-Messaging-System für alle Mandanten.

Dieser Ansatz ermöglicht die höchste Dichte von Mandanten in der Infrastruktur und reduziert damit die Gesamtbetriebskosten. Auch der Verwaltungsaufwand ist oft geringer, da nur ein einziges Messagingsystem bzw. eine Messagingressource verwaltet und geschützt werden muss.

Beachten Sie jedoch die folgenden Einschränkungen, wenn Sie eine Ressource oder eine vollständige Infrastruktur für mehrere Mandanten gemeinsam verwenden:

  • Berücksichtigen Sie immer die Einschränkungen, Skalierungsfunktionen, Kontingente und Grenzwerte der jeweiligen Ressource. Beispielsweise können die maximale Anzahl von Service Bus-Namespaces in einem Azure-Abonnement, die maximale Anzahl von Event Hubs in einem einzelnen Namespace oder die Grenzwerte für den maximalen Durchsatz letztendlich alles blockieren, wenn Ihre Architektur aufgrund steigender Mandantenzahlen wächst. Planen Sie sorgfältig die maximale Skalierung, die Sie in Bezug auf die Anzahl von Namespaces pro einzelnem Azure-Abonnement oder von Warteschlangen pro einzelnem Namespace erreichen müssen. Vergleichen Sie dann Ihre aktuellen Werte und Ihre Schätzungen für die Zukunft mit den vorhandenen Kontingenten und Grenzwerten Ihres gewünschten Messagingsystems, bevor Sie sich für dieses Muster entscheiden.
  • Wie in den obigen Abschnitten erwähnt, kann das Noisy Neighbor-Problem zu einem Faktor werden, wenn Sie eine Ressource für mehrere Mandanten gemeinsam verwenden, insbesondere wenn einige stärker ausgelastet sind oder einen höheren Datenverkehr generieren als andere. Ziehen Sie in diesem Fall das Muster mit Drosselung oder das Muster mit Bandbreiteneinschränkung in Betracht, um diese Auswirkungen zu minimieren. Beispielsweise können Sie die maximale Anzahl von Nachrichten begrenzen, die ein einzelner Mandant in der Zeiteinheit senden oder empfangen kann.
  • Möglicherweise haben Sie Schwierigkeiten, die Aktivitäten eines einzelnen Mandanten zu überwachen und seinen Ressourcenverbrauch zu messen. Bei einigen Diensten, z. B. Azure Service Bus, erfolgt die Abrechnung nach Messagingvorgängen. Wenn Sie einen Namespace für mehrere Mandanten freigeben, sollte Ihre Anwendung daher in der Lage sein, die Anzahl von Messagingvorgängen zu verfolgen, die im Auftrag jedes Mandanten durchgeführt werden, um eine verbrauchsbasierte Kostenzuteilung zu ermöglichen. Andere Dienste bieten nicht den gleichen Detailgrad.

Mandanten stellen möglicherweise unterschiedliche Anforderungen an Sicherheit, Resilienz innerhalb der Region, Notfallwiederherstellung oder Standort. Wenn diese nicht mit der Konfiguration Ihres Messagingsystems übereinstimmen, reicht eine einzelne Ressource möglicherweise nicht für alle Mandanten aus.

Sharding-Muster

Das Shardingmuster umfasst die Bereitstellung mehrerer Messagingsysteme, die als Shards bezeichnet werden und die Messagingentitäten eines oder mehrerer Mandanten enthalten, z. B. Warteschlangen und Themen. Im Gegensatz zu Bereitstellungsstempeln implizieren Shards nicht, dass die gesamte Infrastruktur dupliziert wird. Sie können Messagingsysteme horizontal partitionieren, ohne auch eine andere Infrastruktur in Ihrer Lösung zu duplizieren oder horizontal zu partitionieren.

Das Diagramm zeigt ein Shard-Messaging-System. Ein Messagingsystem enthält die Warteschlangen für Mandant A und B, das andere die Warteschlangen für Mandant C.

Jedes Messagingsystem oder jeder Shard kann unterschiedliche Merkmale in Bezug auf Zuverlässigkeit, SKU und Standort aufweisen. Beispielsweise können Sie Ihre Mandanten auf mehrere Messagingsysteme mit unterschiedlichen Merkmalen verteilen, die ihrem Standort oder ihren Anforderungen in Bezug auf Leistung, Zuverlässigkeit, Datenschutz oder Geschäftskontinuität entsprechen.

Wenn Sie das Shardingmuster verwenden, müssen Sie eine Shardingstrategie anwenden, um einen bestimmten Mandanten dem Messagingsystem mit seinen Warteschlangen zuordnen zu können. Die Lookupstrategie verwendet eine Zuordnung, um das Messagingzielsystem basierend auf dem Mandantennamen oder der Mandanten-ID anzupassen. Mehrere Mandanten können denselben Shard gemeinsam nutzen, aber die Messagingentitäten für einen einzelnen Mandanten werden nicht über mehrere Shards verteilt. Die Zuordnung kann mit einem einzelnen Wörterbuch implementiert werden, das den Namen des Mandanten dem Namen oder Verweis des Zielmessagingsystems zu ordnet. Sie kann in einem verteilten Cache gespeichert werden, auf den von allen Instanzen einer mehrinstanzenfähigen Anwendung zugegriffen werden kann, oder in einem persistenten Speicher, z. B. einer Tabelle in einer relationalen Datenbank oder in einem Speicherkonto.

Das Muster mit horizontalem Partitionieren kann auf eine sehr große Anzahl von Mandanten skaliert werden. Darüber hinaus können Sie je nach Workload eine hohe Dichte von Mandanten pro Partition erreichen, sodass die Kosten attraktiv sein können. Das Shardingmuster eignet sich auch, um Kontingente, Grenzwerte und Einschränkungen für Azure-Abonnements und -Dienste zu berücksichtigen.

Mehrinstanzenfähige App mit dediziertem Messagingsystem für jeden Mandanten

Ein weiterer gängiger Ansatz ist die Bereitstellung einer einzelnen mehrinstanzenfähigen Anwendung mit dedizierten Messagingsystemen für jeden Mandanten. In diesem Mandantenmodell werden einige Komponenten gemeinsam genutzt, z. B. Computerressourcen, während andere Dienste mit einem dedizierten Bereitstellungsansatz mit nur einem Mandanten bereitgestellt und verwaltet werden. Beispielsweise können Sie eine einzelne Logikschicht erstellen und dann einzelne Messagingsysteme für jeden Mandanten bereitstellen, wie in der folgenden Abbildung gezeigt.

Das Diagramm zeigt verschiedene Nachrichtensysteme für jeden Mandanten.

Horizontal partitionierte Bereitstellungen können dabei helfen, das Noisy Neighbor-Problem zu beheben, wenn Sie festgestellt haben, dass der größte Teil der Last in Ihrem System auf bestimmte Komponenten zurückzuführen ist, die Sie separat für jeden Mandanten bereitstellen können. Beispielsweise müssen Sie möglicherweise ein separates Messaging- oder Ereignisstreamingsystem für jeden Mandanten verwenden, da eine einzelne Instanz nicht für den von mehreren Mandanten generierten Datenverkehr ausreicht. Wenn ein einzelner Mandant bei Verwendung eines dedizierten Messagingsystems für jeden Mandanten eine große Anzahl von Nachrichten oder Ereignissen verursacht, kann dies zwar auf die gemeinsam genutzten Komponenten, aber nicht auf die Messagingsysteme anderer Mandanten Auswirkungen haben.

Da Sie dedizierte Ressourcen für jeden Mandanten bereitstellen, können die Kosten bei diesem Ansatz höher sein als bei einem Hostingmodell mit gemeinsamer Nutzung. Andererseits ist es bei diesem Mandantenmodell auch einfacher, die Ressourcenkosten eines dedizierten Systems Mandanten eindeutig verbrauchsbasiert in Rechnung zu stellen. Mit diesem Ansatz können Sie eine hohe Dichte für andere Dienste erreichen, z. B. Computingressourcen, und die Kosten für diese Komponenten reduzieren.

Bei einer horizontal partitionierten Bereitstellung müssen Sie einen automatisierten Prozess für die Bereitstellung und Verwaltung der Dienste einer mehrinstanzenfähigen Anwendung einführen. Dies gilt insbesondere für Dienste, die von einem einzelnen Mandanten verwendet werden.

Muster mit Geoknoten

Das Muster mit Geoknoten umfasst die Bereitstellung einer Sammlung von Back-End-Diensten in einer Gruppe geografischer Knoten. Jeder Knoten kann sämtliche Anforderung für alle Clients in einer beliebigen Region unterstützen. Dieses Muster ermöglicht die Aktiv/Aktiv-Verarbeitung von Anforderungen. Damit können Sie die Latenz verbessern und die Verfügbarkeit erhöhen, da die Verarbeitung der Anforderungen weltweit verteilt wird.

Das Diagramm zeigt das Geode-Muster mit Messaging-Systemen, die in mehreren Regionen bereitgestellt werden und sich miteinander synchronisieren.

Azure Service Bus und Azure Event Hubs unterstützen die Notfallwiederherstellung von Metadaten über primäre und sekundäre Notfallwiederherstellungsnamespaces sowie über separate Regionen und Verfügbarkeitszonen hinweg und bieten damit optimale regionsinterne Resilienz. Darüber hinaus implementieren Azure Service Bus und Azure Event Hubs eine Reihe von Verbundmustern, die dasselbe logische Thema, dieselbe Warteschlange oder denselben Event Hub aktiv replizieren, damit diese in mehreren Namespaces verfügbar sind, auch wenn sie sich in verschiedenen Regionen befinden. Weitere Informationen finden Sie in den folgenden Ressourcen:

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Nächste Schritte

Weitere Informationen zu Entwurfsmustern für das Messaging finden Sie in den folgenden Ressourcen: