Global wechseln
- 3 Minuten
In der vorherigen Einheit haben wir die Skalierungsberechnung beschrieben und im Prozess mehr verfügbar machen. Außerdem wurde empfohlen, einen Azure-Cache für Redis hinzuzufügen, um die Leistung zu verbessern und Azure SQL-Datenbanken über Sharding zu skalieren.
Der nächste Schritt, da Ihr Unternehmen wächst, könnte sein, global zu gehen. Es gibt jedoch einige Dinge, die Sie berücksichtigen müssen, bevor Sie versuchen, eine vollständige globale Architektur zu implementieren.
Fragen zu stellen
Die erste Frage ist: Müssen Sie wirklich global gehen?
Es ist wichtig zu verstehen, welche Schmerzen unsere Kunden haben, bevor sie eine solche Aufgabe übernehmen, also stellen Sie sich ein paar weitere Fragen:
- Können Sie Inhalte über ein Content Delivery Network näher an Ihre Benutzer heranholen?
- Müssen Sie dieses bestimmte System wirklich auf zwei (oder mehr) Regionen skalieren? Muss ein Benutzer in den USA beispielsweise dasselbe Konto im Vereinigten Königreich haben? Wären unabhängige Systeme besser geeignet? Dieses Muster ist im E-Commerce üblich.
- Wenn Sie wirklich ein global verteiltes System benötigen, welche Konsistenz benötigen Sie für die Datenbank? Starke Konsistenz auf der ganzen Welt ist schwer zu finden, und ist in Diensten wie Cosmos DB nicht erlaubt, buchstäblich aufgrund der Lichtgeschwindigkeit.
Datenkonsistenz
Sehen wir uns etwas genauer an, was die Datenkonsistenz betrifft.
Konsistenz in Datenbanksystemen bezieht sich auf die Anforderung, dass jede datenbanktransaktion betroffene Daten nur auf die zulässige Weise ändern muss. Es gibt zwei Konsistenzmodelle, die für verteiltes Computing verwendet werden.
Starke Konsistenz bietet eine Garantie für lineare Konsistenz. Die Lesevorgänge geben garantiert die neueste Version eines Elements zurück, für die ein Commit ausgeführt wurde.
Und dann gibt es letztendlich Konsistenz, die Idee, dass eine Datenbank oder ein System im Laufe der Zeit konsistent wird. Es gibt keine Bestellgarantie für Lesevorgänge. Wenn keine weiteren Schreibvorgänge vorhanden sind, werden die Replikate schließlich zusammengeführt.
Tools für den globalen Umschwung
Wenn Sie feststellen, dass Sie Ihre Anwendung wirklich global skalieren müssen, gibt es einige Azure-Dienste, die Ihnen dabei helfen können. Werfen wir einen Blick auf Azure Traffic Manager und Azure Front Door:
- Azure Traffic Manager ist ein globaler DNS-basierter Lastenausgleichsdienst. Es verwendet DNS- und Integritätssonden, um Ihre Benutzer basierend auf den von Ihnen definierten Routingrichtlinien an das beste fehlerfreie Back-End weiterzuleiten. Diese Definition kann auf Leistung, Position, Roundrobin usw. basieren. Nachdem ein fehlerfreies Back-End identifiziert wurde, stellen Clients immer eine direkte Verbindung mit dem Back-End her.
- Azure Front Door Service ist ein AdN (Application Delivery Network) as a Service, der verschiedene Lastenausgleichsfunktionen für Ihre Anwendungen bietet. Es bietet dynamische Standortbeschleunigung (Dynamic Site Acceleration, DSA) zusammen mit einem globalen Lastenausgleich mit nahezu Echtzeitfailover. Es ist ein hoch verfügbarer und skalierbarer Dienst, der vollständig von Azure verwaltet wird.
Azure Front Door ist im Grunde ein globaler HTTP-basierter Lastenausgleich. Der Client stellt eine Verbindung mit Der Front Door selbst her, sodass Front Door die Anforderung der Benutzer proxyt. Wenn sich das angeforderte Element nicht im Cache befindet, wird die richtige Routingregel identifiziert. Anschließend überprüft er die Integritätssonde des relevanten Back-Ends, und vorausgesetzt, dass alle fehlerfrei sind, leitet die Benutzeranforderung basierend auf der Routingmethode an das beste Back-End weiter.
Da Azure Front Door die Verbindung unterstützt, können Sie einige erweiterte Funktionen wie das Ausführen einer Webanwendungsfirewall und das Zwischenspeichern ausführen, was für die Skalierung hilfreich ist. Keine dieser Funktionen kann mit Traffic Manager erreicht werden.
Das Diagramm zeigt, wie Sie beides zusammen verwenden können.
Dieses Setup verwendet Traffic Manager für einfachen DNS-basierten Lastenausgleich für Ihre statischen Ressourcen in Speicherkonten. Außerdem wird Front Door für pfadbasiertes Routing für Ihre Webanwendung über App Service und VMs hinweg verwendet.