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

Verteilte Anwendungen, die mehrere interne und externe Dienste enthalten, erfordern asynchrone Messaging- und ereignisgesteuerte Kommunikation. Wenn Sie Ihre Mehrinstanzenlösung entwerfen, müssen Sie entscheiden, wie Nachrichten freigegeben oder partitioniert werden, die zu verschiedenen Mandanten gehören.

Sie können ein Messaging-System oder einen Event-Streaming-Dienst für alle Mandanten freigeben, um die Betriebskosten und die Verwaltungskomplexität zu reduzieren. Alternativ können Sie ein dediziertes Messaging-System für jeden Mandanten verwenden, um eine bessere Datenisolation zu erhalten, das Risiko von Datenlecks zu verringern, das laute Nachbarproblem zu beseitigen und Azure-Kosten für Ihre Mandanten einfacher aufzuladen.

Dieser Artikel hilft Lösungsarchitekten bei der Entscheidung, wie Sie Messaging- oder Ereignisinfrastruktur in einer mehrinstanzenübergreifenden Lösung verwenden.

Nachrichten, Datenpunkte und diskrete Ereignisse

Sie müssen den Unterschied zwischen Diensten verstehen, die ein Ereignis und Systeme liefern, die eine Nachricht senden. Ein Ereignis ist eine einfache Benachrichtigung über eine Bedingungs- oder Zustandsänderung. Ein Ereignis beschreibt in der Regel etwas, das bereits geschehen ist. Eine Nachricht enthält Rohdaten, die ein Dienst erzeugt, um an anderer Stelle genutzt oder gespeichert zu werden. Nachrichten sind implizite Anweisungen oder Anforderungen.

In der folgenden Tabelle werden wichtige Messagingtypen und Beispiellösungen mit mehreren Mandanten beschrieben, die diesen Entitätstyp verwenden können.

Weitere Informationen finden Sie unter Auswählen des richtigen Azure-Messagingdiensts für Ihre Daten.

Azure bietet mehrere Messagingdienste, die Ihre Messaginganforderungen unterstützen können. Zu diesen Diensten gehören Azure Event Hubs, Azure Event Grid und Azure Service Bus. Weitere Informationen finden Sie unter Wählen zwischen Azure-Messagingdiensten.

Sie können auch Ihren eigenen Messagingdienst auf virtuellen Computern (VMs), Containern oder in Diensten wie Azure Kubernetes Service (AKS) bereitstellen und verwalten. Bei diesem Ansatz müssen Sie Ihre Messaginginfrastruktur bereitstellen, verwalten und pflegen.

Wesentliche Aspekte und Anforderungen

Das Bereitstellungs- und Mandantenmodell, das Sie für Ihre Lösung auswählen, wirkt sich auf Sicherheit, Leistung, Datenisolation, Verwaltung und die Möglichkeit aus, Ressourcenkosten auf Mandanten umzulegen. Berücksichtigen Sie bei dieser Analyse auch das Modell, das Sie für Ihre Messaging- und Ereignisinfrastruktur auswählen. In den folgenden Abschnitten werden die wichtigsten Entscheidungen beschrieben, die Sie treffen müssen, wenn Sie ein Messagingsystem in Ihrer Mehrinstanzenlösung planen.

Skalieren

Berücksichtigen Sie beim Planen der Messaging- oder Ereignisinfrastruktur die Anzahl der Mandanten, die Komplexität von Nachrichtenflüssen und Ereignisstreams, das Nachrichtenvolumen, das erwartete Datenverkehrsprofil und die Isolationsstufe.

Planen Sie zunächst die Kapazität, und richten Sie die maximale Durchsatzkapazität für das Messagingsystem ein. Diese Planung hilft Ihnen bei der ordnungsgemäßen Behandlung des erwarteten Nachrichtenvolumens während des normalen und spitzen Datenverkehrs.

Wenn Ihre Lösung viele Mandanten verarbeitet und über ein separates Messaging-System für jeden Mandanten verfügt, wenden Sie eine konsistente Automatisierungsstrategie an. Diese Strategie sollte die Bereitstellung, Überwachung, Warnung und Skalierung jeder Infrastruktur automatisieren.

Sie können z. B. während des Bereitstellungsprozesses ein Messagingsystem für einen Mandanten bereitstellen, indem Sie ein Infrastrukturtool als Code (IaC) wie Terraform, Bicep oder Azure Resource Manager-Vorlagen (ARM-Vorlagen) und ein DevOps-System wie Azure DevOps oder GitHub-Aktionen verwenden. Weitere Informationen finden Sie unter Architekturansätze für die Bereitstellung und Konfiguration mehrinstanzenfähiger Lösungen.

Sie können das Messagingsystem so dimensionieren, dass es einen maximalen Durchsatz in Nachrichten pro Zeiteinheit erreicht. Wenn das System die dynamische Automatische Skalierung unterstützt, kann es seine Kapazität basierend auf Den Verkehrsbedingungen und Metriken automatisch erhöhen oder verringern, um den erwarteten Servicelevelvertrag (SLA) zu erfüllen.

Vorhersagbarkeit und Zuverlässigkeit der Leistung

Für nur wenige Mandanten kann ein einzelnes Messaging-System funktionale Durchsatzanforderungen erfüllen und die Gesamtbetriebskosten (Total Cost of Ownership, TCO) reduzieren. Eine mehrinstanzenfähige Anwendung kann dieselben Messagingentitäten wie Warteschlangen und Themen für mehrere Kunden gemeinsam nutzen. Alternativ können Sie einen dedizierten Satz von Komponenten für jeden Mandanten verwenden, um die Mandantenisolation zu erhöhen. Eine freigegebene Messaging-Infrastruktur über mehrere Mandanten hinweg kann jedoch die gesamte Lösung für das laute Nachbarproblem verfügbar machen. Die Aktivität eines Mandanten kann die Leistung und Funktionsfähigkeit anderer Mandanten stören.

In diesem Fall sollten Sie das Nachrichtensystem ordnungsgemäß anpassen, um die erwartete Datenverkehrslast zu Spitzenzeiten aufrechtzuerhalten. Im Idealfall sollte das System Autoskalierung unterstützen, die sich dynamisch nach außen skaliert, wenn der Datenverkehr zunimmt, und nach innen, wenn der Datenverkehr nachlässt. Ein dediziertes Messaging-System für jeden Mandanten kann auch das laute Nachbarrisiko mindern, aber die Verwaltung vieler Messagingsysteme erhöht die Komplexität der Lösung.

Eine mehrinstanzenfähige Anwendung kann einen Hybridansatz verwenden. Bei diesem Ansatz verwenden Kerndienste dieselbe Gruppe von Warteschlangen und Themen in einem einzigen, freigegebenen Messaging-System, um interne, asynchrone Kommunikation zu implementieren. Im Gegensatz dazu können andere Dienste eine dedizierte Gruppe von Messagingentitäten oder sogar ein dediziertes Messagingsystem für jeden Mandanten einführen, um das laute Nachbarproblem zu mindern und die Datenisolation zu gewährleisten.

Verwaltungs- und Betriebskomplexität

Planen Sie von Anfang an, wie Sie Ihre Messaging- und Ereignisinfrastruktur betreiben, überwachen und verwalten möchten und wie sich Ihr Mehrinstanzenansatz auf Ihre Vorgänge und Prozesse auswirkt. Betrachten Sie beispielsweise die folgenden Faktoren:

• Wenn Sie ein Messagingsystem für mehrere Mandanten freigeben, definieren Sie, wie Ihre Lösung die Nutzungsmetriken für jeden Mandanten sammelt und meldet oder wie sie die Anzahl der Nachrichten drosselt, die jeder Mandant senden oder empfangen kann.

• Wenn Mandanten zu einem anderen Nachrichtendiensttyp, einer anderen Bereitstellung oder in eine andere Region wechseln müssen, sollte ermittelt werden, wie der Wechsel durchgeführt werden kann.

• Wenn Ihr Messagingsystem eine Plattform als Dienstangebot (PaaS) verwendet, berücksichtigen Sie die folgenden Überlegungen:

  • Passen Sie die Preisstufe für jeden Mandanten auf Grundlage der Funktionen und der angeforderten gemeinsam genutzten oder dedizierten Isolationsstufe an.

  • Erstellen Sie mandantenspezifische verwaltete Identitäten und Azure-Rollenzuweisungen, um die richtigen Berechtigungen nur den Messaging-Entitäten zuzuweisen, auf die der Mandant zugreifen soll. Weitere Informationen finden Sie unter Authentifizieren einer verwalteten Identität mit Microsoft Entra ID für den Zugriff auf Service Bus-Ressourcen.

• Wenn Sie das Messagingsystem hosten möchten, das Ihre Anwendung in einem dedizierten Satz von VMs oder Containern (eines für jeden Mandanten) verwendet, definieren Sie, wie diese Systeme bereitgestellt, aktualisiert, überwacht und skaliert werden.

Kosten

Im Allgemeinen gilt: Je höher die Mandantendichte in Ihrer Bereitstellungsinfrastruktur, desto geringer die Kosten für deren Bereitstellung. Die gemeinsame Infrastruktur erhöht jedoch die Wahrscheinlichkeit von Problemen wie dem lauten Nachbarproblem. Berücksichtigen Sie die Trade-Offs sorgfältig.

Zu berücksichtigende Ansätze und Muster

Wenn Sie eine mehrinstanzenfähige Lösung planen, die Messaging umfasst, sollten Sie die Isolationsebene zwischen Mandanten berücksichtigen. Überprüfen Sie die folgenden Überlegungen und Beobachtungen:

• Verschlüsselungsschlüssel: Wenn Mandanten einen eigenen Schlüssel zum Verschlüsseln und Entschlüsseln von Nachrichten benötigen, bestätigen Sie, wie der Messagingdienst die Schlüsselisolation unterstützt. Wenn Sie beispielsweise Service Bus verwenden, müssen Sie möglicherweise einen separaten Service Bus Premium-Namespace für jeden Mandanten erstellen, der eigene Schlüssel benötigt. Mit dieser Trennung können Sie vom Kunden verwaltete Schlüssel (CMKs) verwenden.

• Geschäftskontinuität: Identifizieren Sie Mandanten, die ein hohes Maß an Wiederherstellbarkeit und Geschäftskontinuität benötigen. Erwägen Sie Zonenredundanz, Georedundanz- und Geo-Notfallwiederherstellungsfunktionen für diese Mandanten, sofern verfügbar.

• Verarbeitung der Arbeit: Wenn Sie separate Warteschlangenressourcen oder ein dediziertes Messagingsystem für jeden Mandanten verwenden, können Sie einen separaten Pool von Arbeitsprozessen für jeden Mandanten übernehmen. Dieser Ansatz erhöht die Datenisolationsstufe und verringert die Komplexität der Verwaltung mehrerer Messaging-Entitäten.

  Jede Instanz des Verarbeitungssystems kann unterschiedliche Anmeldeinformationen übernehmen, z. B. eine Verbindungszeichenfolge, einen Service Principal oder eine verwaltete Identität, um auf das dedizierte Messagingsystem zuzugreifen. Dieser Ansatz verbessert die Sicherheit und Isolation zwischen Mandanten, erhöht aber die Komplexität der Identitätsverwaltung.

Gemeinsames Messagingsystem

Sie können ein freigegebenes Messaging-System bereitstellen, z. B. einen einzelnen ServiceBus-Namespace, und es mit allen Ihren Mandanten teilen.

Dieser Ansatz bietet die höchste Dichte von Mandanten für die Infrastruktur und reduziert die Gesamt-TCO.This approach provides the highest density of tenants to the infrastructure and reduces the overall TCO. Dies reduziert häufig den Verwaltungsaufwand, da Sie nur ein einzelnes Messaging-System oder eine einzelne Ressource verwalten und sichern müssen.

Beachten Sie jedoch die folgenden Einschränkungen, wenn Sie eine Ressource oder eine gesamte Infrastruktur mit mehreren Mandanten teilen:

• Berücksichtigen Sie die Einschränkungen, Skalierungsfunktionen, Kontingente und Grenzwerte der Ressource. Beispielsweise kann die maximale Anzahl von Event Hubs in einem einzelnen Namespace oder die maximalen Durchsatzgrenzwerte zu einem Blocker werden, wenn Ihre Architektur wächst, um mehr Mandanten zu unterstützen.

• Das laute Nachbarproblem kann ein Faktor werden, wenn Sie eine Ressource für mehrere Mandanten freigeben, insbesondere, wenn Sie über beschäftigte Mandanten oder Mandanten verfügen, die einen höheren Datenverkehr generieren als andere. Um diese Effekte zu mindern, sollten Sie das Einschränkungsmuster oder das Rate Limiting-Muster berücksichtigen. Sie können beispielsweise die maximale Anzahl von Nachrichten einschränken, die ein einzelner Mandant innerhalb eines bestimmten Zeitraums senden oder empfangen kann.

• Möglicherweise ist es schwierig, die Aktivität zu überwachen und den Ressourcenverbrauch für einen einzelnen Mandanten zu messen. Einige Dienste, wie bestimmte Ebenen des Service Bus, berechnen für Messaging-Vorgänge. Wenn Sie einen Namespace für mehrere Mandanten freigeben, sollte Ihre Anwendung die Anzahl der Nachrichtenvorgänge nachverfolgen, die jeder Mandant generiert, und die zugehörigen Kosten für die Rückbuchung. Andere Dienste bieten nicht den gleichen Detailgrad.

Mandanten haben möglicherweise unterschiedliche Anforderungen für Sicherheit, Ausfallsicherheit innerhalb der Region, Notfallwiederherstellung oder Standort. Wenn diese Anforderungen nicht mit der Konfiguration Ihres Nachrichtensystems übereinstimmen, können Sie sie möglicherweise nicht allein mit einer einzigen Ressource bewältigen.

Verwenden des Sharding-Musters

Das Sharding-Muster umfasst die Bereitstellung mehrerer Messagingsysteme, auch als Shards bezeichnet. Jeder Shard enthält eine oder mehrere Nachrichtenentitäten eines Mandanten, z. B. Warteschlangen und Themen. Im Gegensatz zu Bereitstellungsstempeln bedeuten Shards nicht, dass Sie die gesamte Infrastruktur duplizieren. Sie können Messagingsysteme horizontal partitionieren, ohne auch eine andere Infrastruktur in Ihrer Lösung zu duplizieren oder horizontal zu partitionieren.

Jedes Messagingsystem oder jeder Shard kann unterschiedliche Merkmale in Bezug auf Zuverlässigkeit, SKU und Standort aufweisen. Beispielsweise können Sie Ihre Mandanten je nach ihrem Standort oder aufgrund von Anforderungen an die Leistung, Zuverlässigkeit, den Datenschutz oder die Geschäftskontinuität auf mehrere Nachrichtenübermittlungssysteme verteilen.

Wenn Sie das Sharding-Muster verwenden, müssen Sie eine Shardingstrategie verwenden, um einen bestimmten Mandanten dem Messagingsystem zuzuordnen, das seine Warteschlangen enthält. Die Lookup-Strategie verwendet eine Map, um das Zielnachrichtensystem anhand des Mandantennamens oder der ID zu identifizieren. Mehrere Mandanten verwenden möglicherweise den gleichen Shard, aber die Nachrichtenentitäten, die ein einzelner Mandant verwendet, bleiben innerhalb eines Shards.

Sie können die Abbildung als Wörterbuch implementieren, das jedem Mandantennamen mit dem Namen oder der Referenz seines Zielnachrichtensystems verknüpft. Sie können die Zuordnung in einem verteilten Cache speichern, auf den alle Instanzen einer Mehrinstanzenanwendung zugreifen können, oder sie in einem persistenten Speicher wie einer Tabelle in einer relationalen Datenbank oder einem Speicherkonto speichern.

Das Sharding-Muster kann so skaliert werden, dass es mehrere Mandanten unterstützt. Abhängig von Ihrer Arbeitsbelastung können Sie eine hohe Dichte von Mandanten auf die Shards verteilen, was die Kosten senken kann. Sie können auch das Sharding-Muster verwenden, um Azure-Abonnement- und Dienstkontingente, Grenzwerte und Einschränkungen zu behandeln.

Verwenden Sie eine mehrmandantenfähige App mit einem dedizierten Messagingsystem für jeden Mandanten

Sie können auch eine einzelne mehrinstanzenfähige Anwendung bereitstellen, die dedizierte Messagingsysteme für jeden Mandanten verwendet. Dieses Mandantenmodell enthält einige freigegebene Komponenten, z. B. Rechnerressourcen. Sie stellen andere Dienste mithilfe eines eigenständigen, dedizierten Bereitstellungsansatzes bereit und verwalten diese. Sie können z. B. eine einzelne Anwendungsebene erstellen und dann einzelne Messagingsysteme für jeden Mandanten bereitstellen, wie in der folgenden Abbildung dargestellt.

Wenn bestimmte Komponenten den größten Teil der Last Ihres Systems generieren und Sie diese Komponenten separat für jeden Mandanten bereitstellen können, verwenden Sie eine horizontal partitionierte Bereitstellung, um laute Nachbarprobleme zu reduzieren. Verwenden Sie z. B. für jeden Mandanten ein separates Messaging- oder Eventstream-System, wenn eine einzelne Instanz nicht mit dem Datenverkehr schritthalten kann, den mehrere Mandanten generieren. Wenn Sie ein dediziertes Messaging-System für jeden Mandanten verwenden, kann sich eine große Anzahl von Nachrichten oder Ereignissen von einem einzelnen Mandanten auf die freigegebenen Komponenten, aber nicht auf die Messagingsysteme anderer Mandanten auswirken.

Da Sie dedizierte Ressourcen für jeden Mandanten bereitstellen, kostet dieser Ansatz häufig mehr als ein gemeinsam genutztes Hostingmodell. Es bietet Ihnen jedoch auch eine einfache Möglichkeit, jedem Mandanten die Ressourcen in Rechnung zu stellen, die sie verwenden. Mit diesem Ansatz können Sie eine hohe Dichte für andere Dienste wie Computerressourcen erreichen und die Kosten dieser Komponenten reduzieren.

Bei einer horizontal partitionierten Bereitstellung benötigen Sie einen automatisierten Prozess zum Bereitstellen und Verwalten der Dienste einer mehrinstanzenfähigen Anwendung, insbesondere dienste, die ein einzelner Mandant verwendet.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Paolo Salvadori | Principal Customer Engineer, FastTrack für Azure

Andere Mitwirkende:

• Daphne Choong | Senior Partner Solution Architect
• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Clemens Vasters | Principal Architect, Messaging-Dienste und -Standards
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack für Azure

Verwandte Ressourcen

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

• Muster für die Anspruchsprüfung
• Muster mit konkurrierenden Verbrauchern
• Muster „Ereignissourcing“
• Muster „Pipes und Filter“
• Herausgeber-Abonnent-Muster
• Muster für einen sequenziellen Konvoi