Muster mit Bereitstellungsstempeln

Das Bereitstellungsstempelmuster stellt Ressourcen bereit, verwaltet und überwacht sie, um mehrere Workloads oder Mandanten zu hosten und zu betreiben. Jede einzelne Kopie wird als Stempel oder manchmal als Diensteinheit, Skalierungseinheit oder Zelle bezeichnet. In einer mehrinstanzenfähigen Umgebung dient jeder Stempel einer vordefinierten Anzahl von Mandanten. Sie stellen mehrere Stempel bereit, um die Lösung fast linear zu skalieren und eine wachsende Anzahl von Mandanten zu bedienen. Dieser Ansatz kann die Skalierbarkeit Ihrer Lösung verbessern, Ihnen ermöglichen, Instanzen in mehreren Regionen bereitzustellen und Ihre Kundendaten zu trennen.

Note

Weitere Informationen finden Sie unter Architect multitenant solutions on Azure.

Kontext und Problem

Berücksichtigen Sie beim Hosten einer Anwendung in der Cloud die Leistung und Zuverlässigkeit Ihrer Anwendung. Wenn Sie eine einzelne Instanz Ihrer Lösung hosten, gelten möglicherweise die folgenden Einschränkungen:

• Skalierungsgrenzwerte: Eine einzelne Instanz Ihrer Anwendung kann natürliche Skalierungsgrenzwerte erreichen. Beispielsweise können die von Ihnen verwendeten Dienste die Anzahl eingehender Verbindungen, Hostnamen, TCP-Sockets (Transmission Control Protocol) oder andere Ressourcen einschränken.

• Nichtlineare Skalierung oder Kosten: Einige Komponenten Ihrer Lösung werden möglicherweise nicht linear mit der Anzahl der Anforderungen oder der Datenmenge skaliert. Stattdessen kann die Leistung sinken oder Die Kosten können steigen, nachdem Sie einen Schwellenwert erreicht haben. Sie können beispielsweise feststellen, dass das Hinzufügen von mehr Kapazität zu einer Datenbank oder das vertikale Skalieren unerschwinglich teuer wird und dass horizontales Skalieren kostengünstiger ist.

• Trennung von Kunden: Möglicherweise müssen Sie die Daten eines Kunden aus den Daten eines anderen Kunden isolieren. Möglicherweise verfügen Sie auch über Kunden, die mehr Systemressourcen verbrauchen als andere. Sie können sie in verschiedenen Gruppen von Infrastruktur gruppieren.

• Einzelmandanten- und Mehrinstanzeninstanzen: Einige große Kunden benötigen möglicherweise ihre eigenen unabhängigen Instanzen Ihrer Lösung. Kleinere Kunden können eine Multitenant-Konfiguration teilen.

• Komplexe Bereitstellungsanforderungen: Möglicherweise müssen Sie Updates für Ihren Dienst kontrolliert bereitstellen und zu unterschiedlichen Zeiten auf verschiedene Teilmengen Ihrer Kundenbasis bereitstellen.

• Aktualisierungshäufigkeit: Einige Kunden tolerieren häufige Updates, während Risikoaverse Kunden seltene Updates für das System wünschen, das ihre Anforderungen erfüllt. Sie können diese Kunden in isolierten Umgebungen bereitstellen.

• Geografische oder geopolitische Einschränkungen: Um eine geringe Latenz zu erzielen oder die Anforderungen an die Datenhoheit einzuhalten, stellen Sie möglicherweise einige Kunden in bestimmten Regionen bereit.

Diese Einschränkungen gelten häufig für Softwareentwicklungsunternehmen, die Software as a Service (SaaS) erstellen, die sie in der Regel als Multitenant entwerfen. Die gleichen Einschränkungen können auch auf andere Szenarien angewendet werden.

Lösung

Um diese Probleme zu vermeiden, sollten Sie Ressourcen in Skalierungseinheiten gruppieren und mehrere Kopien Ihrer Stempel bereitstellen. Jede Skalierungseinheit hostet und dient einer Teilmenge Ihrer Mandanten. Stempel werden unabhängig voneinander ausgeführt, und Sie können sie unabhängig voneinander bereitstellen und aktualisieren. Eine einzelne geografische Region kann einen Stempel oder mehrere Stempel enthalten, die horizontal innerhalb der Region skaliert werden. Jeder Stempel dient einer Teilmenge Ihrer Kunden.

Das Diagramm zeigt fünf gestapelte Zeilen. Jede Zeile stellt einen Bereitstellungsstempel dar. Jede Zeile verfügt über eine Beschriftung oben links, die die Instanz und deren Azure-Region benennt, eine weitere oben rechts, die die Mandanten auflistet, die von der Instanz bedient werden, sowie zwei Komponenten unterhalb der Beschriftungen: Azure App Service auf der linken Seite und eine SQL-Datenbank auf der rechten Seite. Von oben nach unten sind die Stempel 1 in West-US 2, der die Mandanten A, B und C bedient; Stempel 2 in West-US 2, der den Mandanten D bedient; Stempel 3 in Ost-USA, der die Mandanten E, F und G bedient; Stempel 4 in Westeuropa, der die Mandanten H, I und J bedient; und Stempel 5 in Australien Ost, der die Mandanten K, L und M bedient. Die fünf Stempel teilen die gleiche interne Zusammensetzung, unterscheiden sich jedoch in der Region und in der Gruppe der ihnen zugewiesenen Mandanten, und die Region West US 2 enthält zwei separate Stempel, während jede der anderen Regionen einen Stempel enthält.

Bereitstellungsstempel können angewendet werden, unabhängig davon, ob Ihre Lösung Infrastruktur als Dienst (IaaS) oder Plattform als Dienst (PaaS)-Komponenten oder eine Kombination aus beiden verwendet. IaaS-Workloads erfordern in der Regel mehr Eingriffe zum Skalieren, sodass dieses Muster dazu beitragen kann, dass IaaS-schwere Workloads skaliert werden können.

Sie können Stempel verwenden, um Bereitstellungsringe zu implementieren. Wenn unterschiedliche Kunden Dienstupdates in unterschiedlichen Frequenzen wünschen, gruppieren Sie sie auf unterschiedliche Stempel und stellen Sie Aktualisierungen für jeden Stempel in einem anderen Rhythmus bereit.

Stempel laufen unabhängig, sodass sie Ihre Daten implizit aufteilen. Eine einzelne Einheit kann auch intern weiteres Sharding anwenden, um skalierbar und flexibel zu bleiben.

Die Bereitstellung identischer Kopien derselben Komponenten ist komplex, daher sind gute DevOps-Methoden wichtig. Beschreiben Sie Ihre Infrastruktur als Code, damit die Bereitstellung der einzelnen Stempel vorhersehbar und wiederholbar ist.

Bereitstellungsstempel beziehen sich auf Geoden, unterscheiden sich jedoch von Geoden. In einer Bereitstellungsstempelarchitektur dient jede unabhängige Instanz Ihres Systems einer Teilmenge Ihrer Kunden und Benutzer. In einer Geode-Architektur kann jede Instanz Anforderungen von jedem Benutzer bedienen, dieser Ansatz ist jedoch in der Regel komplexer, um Zu entwerfen und zu erstellen. Sie können auch die beiden Muster innerhalb einer Lösung kombinieren. Der weiter unten in diesem Artikel beschriebene Datenverkehrsroutingansatz ist ein Beispiel für ein solches Hybridszenario.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Bereitstellungsprozess: Wenn Sie mehrere Stempel bereitstellen, automatisieren und wiederholen Sie Ihre Bereitstellungsprozesse vollständig. Verwenden Sie Bicep oder Terraform Module, um Ihre Stempel deklarativ zu definieren und die Definitionen konsistent zu halten.

• Stempelübergreifende Vorgänge: Wenn Sie Ihre Lösung unabhängig von mehreren Stempeln bereitstellen, kann es schwierig sein zu bestimmen, wie viele Kunden Sie über alle Ihre Stempel hinweg haben. Möglicherweise müssen Sie jeden Stempel abfragen und die Ergebnisse aggregieren. Alternativ können Sie alle Stempel für konsolidierte Berichte in einem zentralen Data Warehouse veröffentlichen lassen.

• Skalierungsrichtlinien: Stempel verfügen über eine endliche Kapazität, die Sie mithilfe einer Proxymetrik definieren können, z. B. die Anzahl der Mandanten, die Sie auf dem Stempel bereitstellen können. Überwachen Sie die verfügbare und verwendete Kapazität für jeden Stempel, und stellen Sie proaktiv weitere Stempel bereit, um neue Mandanten darauf zu leiten.

• Mindestanzahl von Stempeln: Wenn Sie das Bereitstellungsstempelmuster verwenden, stellen Sie mindestens zwei Stempel Ihrer Lösung bereit. Wenn Sie nur einen einzelnen Stempel bereitstellen, können Sie ganz einfach Hartcodeannahmen in Ihrem Code oder Ihrer Konfiguration ausführen, die beim Skalieren nicht angewendet werden.

• Kosten: Das Bereitstellungsstempelmuster stellt mehrere Kopien Ihrer Infrastrukturkomponenten bereit, wodurch die Kosten für den Betrieb Ihrer Lösung erheblich erhöht werden.

• Wechseln zwischen Marken: Jede Marke wird eigenständig betrieben, daher kann die Übertragung von Mandanten zwischen Marken schwierig sein. Ihre Anwendung benötigt benutzerdefinierte Logik, um die Informationen eines Kunden an einen anderen Stempel zu übertragen und dann die Informationen des Mandanten aus dem ursprünglichen Stempel zu entfernen. Dieser Vorgang erfordert möglicherweise eine Backplane für die Kommunikation zwischen Stempeln, wodurch die Komplexität Ihrer Lösung weiter erhöht wird.

• Datenverkehrsweiterleitung: Wie weiter oben in diesem Artikel beschrieben, kann das Weiterleiten von Datenverkehr an den richtigen Stamp für eine bestimmte Anforderung eine zusätzliche Komponente erfordern, die Mandanten zu Stamps auflöst. Diese Komponente muss möglicherweise auch hoch verfügbar sein.

• Observability across stamps: Da sich die Anzahl der Stempel erhöht, wird es schwieriger, den Gesamtzustand zu überwachen und Vorfälle schnell zu erkennen. Verwenden Sie Azure Monitor, um Metriken, Protokolle, Ablaufverfolgungen und Warnungen über alle Stempel hinweg zu sammeln und zu korrelieren. Verwenden Sie diese Daten, um fehlerhafte Stempel zu identifizieren und Probleme zu diagnostizieren.

• Auswirkungen eines regionalen Ausfalls: Stamps werden unabhängig voneinander ausgeführt, sind aber nicht inhärent redundant über die Regionen hinweg. Wenn eine Region, die einen oder mehrere Stempel hostet, nicht mehr verfügbar ist, verlieren die Mandanten auf diesen Stempeln den Zugriff, bis die Region wiederhergestellt wird, oder Sie migrieren die Mandanten zu Stempeln in einer anderen Region. Um dieses Szenario zu planen, dokumentieren Sie Ihre Wiederherstellungsprozeduren, legen Sie die Erwartungen des Mandanten fest, und überlegen Sie, ob kritische Mandanten georedundante Stempelplatzierung benötigen.

• Freigegebene Komponenten: Möglicherweise verfügen Sie über Komponenten, die Sie über Stempel hinweg freigeben können. Wenn Sie beispielsweise über eine freigegebene Single-Page-App für alle Mandanten verfügen, stellen Sie sie in einer Region bereit und verwenden Sie das Edge-Caching von Azure Front Door, um sie global zu replizieren.

• Governance und Konfigurationsabweichung: Da sich die Anzahl der Stempel erhöht, wird es schwieriger, Sicherheitsrichtlinien, rollenbasierte Zugriffssteuerungszuweisungen (RBAC), Netzwerksteuerelemente, Observability-Einstellungen und Dienstkonfigurationen konsistent zu halten. Verwenden Sie Azure Policy, um Governance als Code zu behandeln und überprüfen Sie kontinuierlich jeden Stempel, um Abweichungen zu vermeiden, um inkonsistentes Verhalten und Compliancelücken zu verhindern.

Wann Sie dieses Muster verwenden sollten

Verwenden Sie dieses Muster in folgenden Fällen:

• Ihre Lösung hat natürliche Grenzen bei der Skalierbarkeit. Wenn beispielsweise einige Komponenten nicht oder nicht über eine bestimmte Anzahl von Kunden oder Anforderungen hinaus skaliert werden können, verwenden Sie Stempel zum Skalieren.

• Sie müssen bestimmte Mandanten von anderen trennen. Wenn Sicherheitsbedenken verhindern, dass Sie einige Kunden in einem Mehrinstanzenstempel bereitstellen, stellen Sie sie auf ihrem eigenen isolierten Stempel bereit.

• Sie müssen einige Mandanten auf verschiedenen Versionen Ihrer Lösung gleichzeitig hosten.

• Sie erstellen Multiregion-Anwendungen, die die Daten und den Datenverkehr jedes Mandanten an eine bestimmte Region weiterleiten müssen.

• Sie möchten resilienz während Ausfällen erreichen. Stempel werden unabhängig ausgeführt. Wenn sich ein Ausfall auf einen einzelnen Stempel auswirkt, bleiben Mandanten auf anderen Stempeln nicht betroffen. Diese Isolation beschränkt den Einflussbereich eines Vorfalls oder eines Ausfalls.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Ihre Lösung ist einfach und muss nicht auf ein hohes Maß skaliert werden.

• Sie können Ihr System innerhalb einer einzelnen Instanz skalieren oder erhöhen, z. B. indem Sie die Größe der Anwendungsschicht erhöhen oder die reservierte Kapazität für Datenbanken und die Speicherebene erhöhen.

• Sie müssen Daten in allen bereitgestellten Instanzen replizieren. Betrachten Sie das Geode-Muster für dieses Szenario.

• Sie müssen nur einige Komponenten skalieren und nicht andere. Überlegen Sie beispielsweise, ob Sie Ihre Lösung skalieren können, indem Sie den Datenspeicher shardingen , anstatt eine neue Kopie aller Lösungskomponenten bereitzustellen.

• Ihre Lösung besteht ausschließlich aus statischen Inhalten, z. B. einer Front-End-JavaScript-Anwendung. Liefern Sie diese Inhalte über ein Content Delivery Network.

Arbeitslastgestaltung

Bewerten Sie die Verwendung des Deployment Stamps-Musters im Design einer Workload, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu adressieren. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Säule	So unterstützt dieses Muster die Säulenziele
Zuverlässigkeitsentwurfsentscheidungen helfen Ihrer Arbeitsauslastung, ausfallsicher zu werden und sicherzustellen, dass sie nach auftreten eines Fehlers wieder in einen voll funktionsfähigen Zustand versetzt wird.	Stempel funktionieren unabhängig, sodass ein Fehler in einem Stempel isoliert ist und sich nicht auf Mandanten auf andere Stempel auswirkt. Die Bereitstellung mehrerer Stempel in allen Regionen bietet auch eine Grundlage für redundanz- und Wiederherstellungsplanung, wodurch der Strahlradius regionaler Ausfälle reduziert wird. - RE:05 Redundanz - RE:07 Selbsterhaltung
Operational Excellence unterstützt die Workloadqualität durch standardisierte Prozesse und Teamzusammenhalt.	Dieses Muster unterstützt unveränderliche Infrastrukturziele und erweiterte Bereitstellungsmodelle und kann sichere Bereitstellungsmethoden erleichtern. - OE:05 Infrastruktur als Code - OE:11 Sichere Bereitstellungsmethoden
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen .	Dieses Muster entspricht oft den definierten Skaleneinheiten in Ihrer Arbeitslast. Wenn Sie mehr Kapazität benötigen, als eine einzelne Skalierungseinheit bietet, setzen Sie eine weitere Instanz ein, um die Kapazität zu erweitern. - PE:05 Skalierung und Partitionierung

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Beispiel

Die folgende Beispielarchitektur verwendet Azure Front Door, Azure API Management und Azure Cosmos DB, um den Datenverkehr global an eine Reihe von regionsspezifischen Stempeln weiterzuleiten.

Auf der linken Seite stellt Azure Front Door (global) den Einstiegspunkt dar. Auf der rechten Seite enthält die Mitte des Diagramms drei regionale Verkehrsweiterleitungsebenen, die vertikal gestapelt sind, jeweils eine für West-US 2, Ost-USA und Australien Ost. In jeder Ebene befindet sich eine API-Verwaltungsinstanz auf der linken Seite und eine Azure Cosmos DB Instanz befindet sich auf der rechten Seite, und eine Doppelpfeil-Abfrage mit der Bezeichnung "Stempel des Mandanten" verbindet sie. Vertikale Doppelpfeile mit der Bezeichnung "Georeplikation" verknüpfen die drei Azure Cosmos DB Instanzen. Azure Front Door ist mit Doppelpfeilen mit allen drei API-Verwaltungsinstanzen verbunden. Ganz rechts werden fünf Stempel vertikal gestapelt. Jeder Stempel zeigt seinen Namen und seine Region, die von ihm bereitgestellten Mandanten und eine App Service-Instanz, die mit einer SQL-Datenbank gekoppelt ist. Die Stempel sind Stempel 1 (West US 2) für Mandanten A, B und C; Stamp 2 (West US 2) für Den Mandanten D; Stempel 3 (Ost-USA) für Mandanten E, F und G; Stempel 4 (Westeuropa) für Mandanten H, I und J; und Stamp 5 (Australia East) für Mandanten K, L und M. Gekrümmte Pfeile führen von den API-Verwaltungsinstanzen zu den entsprechenden Stempeln auf der rechten Seite.

Angenommen, ein Benutzer befindet sich in New York. Stamp 3 speichert ihre Daten in der Region Ost-USA.

Wenn der Benutzer nach Kalifornien reist und auf das System zugreift, leitet das System seine Verbindung über die Region West US 2 weiter, da diese Region ihnen am nächsten kommt, wenn sie die Anforderung stellen. Stempel 3 muss jedoch letztendlich die Anforderung erfüllen, da sie ihre Daten speichert. Das Datenverkehrsroutingsystem leitet die Anforderung an den richtigen Stempel weiter.

Einsatz

Beschreiben Sie Ihre Infrastruktur als Code mithilfe von Bicep oder Terraform. Mit diesem Ansatz wird sichergestellt, dass die Bereitstellung der einzelnen Stempel vorhersehbar und wiederholbar ist. Außerdem wird dadurch die Wahrscheinlichkeit von menschlichen Fehlern verringert, etwa von versehentlichen Konfigurationskonflikten zwischen Stempeln.

Sie können Updates automatisch für alle Stempel parallel bereitstellen. Technologien wie Bicep können die Bereitstellung Ihrer Infrastruktur und Anwendungen koordinieren. Alternativ können Sie sich für die schrittweise Einführung von Updates für einige Stempel und dann schrittweise für andere Stempel entscheiden. Erwägen Sie die Verwendung eines Releaseverwaltungstools wie Azure Pipelines oder GitHub-Aktionen , um Bereitstellungen für jeden Stempel zu koordinieren.

Prüfen Sie die Topologie der Azure-Abonnements und -Ressourcengruppen für Ihre Bereitstellungen sorgfältig:

• In der Regel enthält ein Abonnement alle Ressourcen für eine einzelne Lösung. Erwägen Sie daher die Verwendung eines einzelnen Abonnements für alle Stempel. Einige Azure-Dienste erzwingen jedoch abonnementweite Kontingente. Wenn Sie dieses Muster verwenden, um ein hohes Maß an Skalierung zu ermöglichen, müssen Sie möglicherweise Stempel für verschiedene Abonnements bereitstellen.

• Ressourcengruppen enthalten in der Regel Komponenten, die denselben Lebenszyklus gemeinsam nutzen. Wenn Sie beabsichtigen, Aktualisierungen für alle Stempel gleichzeitig bereitzustellen, können Sie eine einzelne Ressourcengruppe verwenden, die alle Komponenten für alle Stempel enthält. Verwenden Sie Ressourcenbenennungskonventionen und -tags, um die Komponenten zu identifizieren, die zu den einzelnen Stempeln gehören. Wenn Sie auch Updates für jeden Stempel unabhängig bereitstellen möchten, können Sie jeden Stempel in einer eigenen Ressourcengruppe bereitstellen.

Kapazitätsplanung

Ermitteln Sie mithilfe von Auslastungs- und Leistungstests die ungefähre maximale Auslastung eines Stempels. Lastmetriken basieren möglicherweise auf der Anzahl der Kunden oder Mandanten, die ein einzelner Stempel aufnehmen kann, oder auf Metriken, die die Dienste im Stempel ausgeben. Instrumentieren Sie jede Instanz so, dass Sie messen können, wann sie ihre Kapazität erreicht, und stellen Sie sicher, dass Sie neue Instanzen schnell bereitstellen können, um schnell auf die Nachfrage zu reagieren.

Routing von Datenverkehr

Das Bereitstellungsstempelmuster funktioniert gut, wenn Sie jeden Stempel unabhängig voneinander adressieren. Wenn Contoso z. B. die gleiche API-Anwendung über mehrere Stempel hinweg bereitstellt, kann Contoso dns (Domain Name System) verwenden, um den Datenverkehr an den relevanten Stempel weiterzuleiten:

• unit1.aus.myapi.contoso.com leitet den Datenverkehr an den Endpunkt unit1 in einer Region in Australien weiter.
• unit2.aus.myapi.contoso.com leitet den Datenverkehr an den Endpunkt unit2 in einer Region in Australien weiter.
• unit1.eu.myapi.contoso.com leitet den Datenverkehr an die Kennzeichnung unit1 innerhalb einer europäischen Region weiter.

In Azure können Sie diese Einträge in Azure DNS hosten und für jede Region und jeden Stempel eine konsistente Unterdomänenkonvention verwenden. Dieser Ansatz behält vorhersehbares Routing und Vorgänge bei.

Die Kunden sind für die Verbindung mit dem richtigen Stempel verantwortlich.

Wenn für Ihre Lösung ein einzelner Ingresspunkt für den gesamten Datenverkehr erforderlich ist, können Sie einen Routingdienst für den Datenverkehr verwenden, um den Adressstempel für eine bestimmte Anforderung, einen bestimmten Kunden oder einen Mandanten aufzulösen. Der Datenverkehrsroutingdienst leitet den Client entweder an die relevante URL für den Stempel weiter (z. B. durch Zurückgeben eines HTTP 302-Antwortstatuscodes), oder er fungiert als Reverseproxy und leitet den Datenverkehr an den relevanten Stempel weiter, ohne dass der Client sich bewusst ist.

Die Gestaltung eines zentralen Verkehrssteuerungsdienstes kann schwierig sein, insbesondere wenn die Lösung über mehrere Regionen hinweg ausgeführt wird. Erwägen Sie die Bereitstellung des Datenverkehrsweiterleitungsdiensts in mehreren Regionen, einschließlich aller Regionen, die Stempel hosten, und synchronisieren Sie den Datenspeicher, der Mandanten Stempeln zuordnet. Die Datenverkehrsroutingkomponente kann selbst eine Instanz des Geode-Musters sein.

Sie können z. B. API-Verwaltung bereitstellen, um als Datenverkehrsroutingdienst zu fungieren. Die API-Verwaltung bestimmt den entsprechenden Stempel für eine Anforderung, indem Daten in einer Azure Cosmos DBsammlung gesucht werden, die die Zuordnung zwischen Mandanten und Stempeln speichert. Die API-Verwaltung legt dann dynamisch die Back-End-URL auf den API-Dienst des entsprechenden Stempels fest.

Um Anforderungen geoverteilt bereitzustellen und Georedundanz für den Traffic-Routing-Dienst zu gewährleisten, stellen Sie API-Verwaltung über mehrere Regionen hinweg bereit und verwenden Sie Azure Front Door, um den Datenverkehr zum nächstgelegenen API-Verwaltungsgateway zu leiten. In dieser Topologie verwendet Azure Front Door origin-Gruppen, health probes und eine entsprechende routingmethode, um Anforderungen von regionalen Gateways für die unsunde API-Verwaltung fernzuleiten. Die API-Verwaltung leitet dann unter Verwendung der Mandanten-zu-Stempel-Zuordnung und der Backend-Konfiguration (oder Backend-Pools) an den passenden Stempel weiter, einschließlich der Failover-Regeln zwischen den Stempelendpunkten, falls erforderlich. Wenn Ihre Anwendung nicht über HTTP oder HTTPS verfügbar gemacht wird, können Sie ein cross-region-Azure Lastenausgleichsmodul verwenden, um eingehende Anrufe an regionale Azure Lastenausgleichsgeräte zu verteilen. Verwenden Sie das Feature globale Verteilung von Azure Cosmos DB, um die Zuordnungsinformationen in den einzelnen Regionen auf dem neuesten Stand zu halten.

Wenn Ihre Lösung einen Datenverkehrsroutingdienst enthält, überlegen Sie, ob sie als Gateway fungiert und das Gateway offloading für die anderen Dienste ausführen kann, z. B. Tokenüberprüfung, Drosselung und Autorisierung.

Nächste Schritte

• Azure Front Door
• Integration von Bicep in Azure Pipelines
• Integrieren von JSON ARM-Vorlagen in Azure Pipelines

Contributors

Dieser Artikel wird von Microsoft gepflegt. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

• Federico Arambarri | Senior Software Developer, Clarius Consulting
• Daniel Larsen | Principal Customer Engineer, FastTrack für Azure
• Angel Lopez | Senior Software Engineer, Azure Patterns and Practices
• Paolo Salvadori | Principal Customer Engineer, FastTrack für Azure
• Arsen Vladimirskiy | Hauptkundeningenieur, FastTrack für Azure

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Verwandte Ressourcen

• Sie können Sharding als einen einfacheren Ansatz verwenden, um ihre Datenebene zu skalieren. Stempel stempeln implizit ihre Daten, aber Sharding erfordert keinen Bereitstellungsstempel. Weitere Informationen finden Sie unter Sharding-Muster.
• Wenn Ihre Lösung einen Datenverkehrsroutingdienst bereitstellt, können Sie die Gatewayrouting- und Gateway-Offloading-Muster kombinieren, um diese Komponente optimal zu nutzen.