Muster mit Bereitstellungsstempeln

Stellen Sie mehrere unabhängige Kopien von Anwendungskomponenten bereit, einschließlich Datenspeichern, als einzelne Ressourcengruppe. Jede Kopie wird als Stempel oder manchmal als Diensteinheit, Skalierungseinheit oder Zelle bezeichnet. In einer mehrinstanzenfähigen Umgebung dient jeder Stamp einer vordefinierten Anzahl von Mandanten. Stellen Sie mehr Stempel bereit, um die Lösung fast linear zu skalieren, eine wachsende Anzahl von Mandanten zu bedienen, 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.

• Einzel- und mehrinstanzenfähige Instanzen: Möglicherweise benötigen einige Ihrer großen Kunden eigene unabhängige 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. Von jeder Skalierungseinheit wird jeweils eine Teilmenge Ihrer Mandanten gehostet und bedient. Stamps werden unabhängig voneinander ausgeführt, und Sie können sie unabhängig voneinander bereitstellen und aktualisieren. Eine einzelne geografische Region kann einen Stamp oder mehrere Stamps 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, daher kann dieses Muster dazu beitragen, IaaS-lastige Workloads horizontal zu skalieren.

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. Ein einzelner Stamp 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.

Deployment-Stamps hängen zwar eng mit Geoknoten zusammen, unterscheiden sich jedoch von ihnen. 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 festlegen, dass alle Stamps Daten zur konsolidierten Berichterstellung in einem zentralisierten Data Warehouse veröffentlichen.

• Richtlinien zur horizontalen Skalierung: Stamps verfügen über eine endliche Kapazität, die Sie mithilfe einer Proxymetrik definieren können, wie z. B. die Anzahl der Mandanten, die Sie im Stamp bereitstellen können. Überwachen Sie die verfügbare und verbrauchte Kapazität für jeden Stamp, und stellen Sie proaktiv weitere Stamps bereit, um neue Mandanten dorthin zu leiten.

• Mindestanzahl von Stempeln: Wenn Sie das Bereitstellungsstempelmuster verwenden, stellen Sie mindestens zwei Stempel Ihrer Lösung bereit. Wenn Sie nur einen einzelnen Stamp bereitstellen, könnten Sie leicht Annahmen fest in Ihren Code oder Ihre Konfiguration einbauen, die bei einer horizontalen Skalierung nicht mehr zutreffen.

• 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 Stamps, wodurch die Komplexität Ihrer Lösung weiter erhöht wird.

• Datenverkehrsweiterleitung: Wie weiter oben in diesem Artikel beschrieben, kann die Weiterleitung 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.

• Stampübergreifende Observability: Da sich die Anzahl der Stamps 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 über verschiedene Regionen hinweg nicht inhärent redundant. 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 Wiederherstellungsverfahren, legen Sie die Erwartungen an Mandanten fest, und überlegen Sie, ob kritische Mandanten eine georedundante Stamp-Platzierung 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 Konfigurationsdrift: Da sich die Anzahl der Stamps erhöht, wird es schwieriger, Sicherheitsrichtlinien, Zuweisungen im Rahmen der rollenbasierten Zugriffssteuerung (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 einige Komponenten beispielsweise nicht über eine bestimmte Anzahl von Kunden oder Anforderungen hinaus skaliert werden können oder sollten, verwenden Sie Stamps für die horizontale Skalierung.

• Sie müssen bestimmte Mandanten von anderen trennen. Sollten Sicherheitsbedenken Sie daran hindern, bestimmte Kunden in einem mehrmandantenfähigen Stamp bereitzustellen, stellen Sie diese in einem eigenen, isolierten Stamp 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. Stamps werden unabhängig betrieben – wenn sich also ein Ausfall auf einen einzelnen Stamp auswirkt, sind Mandanten in anderen Stamps nicht betroffen. Durch diese Isolierung lassen sich die Auswirkungen eines Vorfalls oder Ausfalls eindämmen.

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, wie Sie das Muster von Deployment-Stamps im Design einer Workload einsetzen könnten, um die in den Säulen des Azure Well-Architected Framework behandelten Ziele und Prinzipien zu erfüllen. 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.	Stamps arbeiten unabhängig, sodass ein Ausfall in einem Stamp isoliert ist und sich nicht auf Mandanten in anderen Stamps auswirkt. Die regionsübergreifende Bereitstellung mehrerer Stamps bietet auch eine Grundlage für die Redundanz- und Wiederherstellungsplanung, wodurch die Auswirkungen regionaler Ausfälle reduziert werden. - 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 bieten kann, stellen Sie für die horizontale Skalierung einen weiteren Stamp bereit. - 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. Stamp 3 muss jedoch die Anforderung verarbeiten, da er deren Daten speichert. Das Datenverkehrsroutingsystem leitet die Anforderung an den richtigen Stamp 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. Auslastungsmetriken können auf der Anzahl der Kunden oder Mandanten basieren, die ein einzelner Stamp unterstützt, oder auf Metriken, die von den Diensten im Stamp ausgegeben werden. Instrumentieren Sie jeden Stamp so, dass Sie messen können, wann er seine Kapazität erreicht, und stellen Sie sicher, dass Sie neue Stamps zügig bereitstellen können, um schnell auf Nachfrage zu reagieren.

Routing von Datenverkehr

Das Muster der Deployment-Stamps funktioniert gut, wenn jeder Stamp separat behandelt wird. 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 Datenverkehr an den Stamp unit1 in einer Region in Australien weiter.
• unit2.aus.myapi.contoso.com leitet Datenverkehr an den Stamp unit2 in einer Region in Australien weiter.
• unit1.eu.myapi.contoso.com leitet Datenverkehr an den Stamp unit1 in einer Region in Europa 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.

Clients sind dafür verantwortlich, eine Verbindung mit dem richtigen Stamp herzustellen.

Wenn für Ihre Lösung ein einzelner Eingangspunkt für den gesamten Datenverkehr erforderlich ist, können Sie einen Datenverkehrsroutingdienst verwenden, um den Stamp für eine bestimmte Anforderung oder einen bestimmten Kunden oder 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 Datenverkehrsroutingdiensts in mehreren Regionen, ggf. einschließlich aller Regionen, die Stamps hosten, und synchronisieren Sie den Datenspeicher, der Mandanten Stamps zuordnet. Die Datenverkehrsroutingkomponente kann selbst eine Instanz des Geode-Musters sein.

Sie können z. B. API-Verwaltung bereitstellen, um als Datenverkehrsroutingdienst zu fungieren. API Management ermittelt den entsprechenden Stamp für eine Anforderung, indem er in einer Azure Cosmos DB-Sammlung, in der die Zuordnung zwischen Mandanten und Stamps gespeichert ist, nach Daten sucht. API Management kann dann die Back-End-URL dynamisch auf den API-Dienst des jeweiligen Stamps festlegen.

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 Ursprungsgruppen, Integritätstests und eine entsprechende Routingmethode, um Anforderungen von fehlerhaften regionalen API Management-Gateways wegzuleiten. API Management leitet dann unter Verwendung der Mandanten/Stamp-Zuordnung und der zugehörigen Back-End-Konfiguration (oder Back-End-Pools) an den passenden Stamp weiter, einschließlich der Failover-Regeln zwischen den Stamp-Endpunkten (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. Stamps führen für ihre Daten ein implizites Sharding durch, doch für das Sharding ist kein Deployment-Stamp erforderlich. 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.