Dieser Artikel wurde von der Huawei Cloud Community „ Sermants Practice in Remote Multi-Active Scenarios “ geteilt, Autor: Huawei Cloud Open Source.
Die Sermant-Community hat nacheinander das Plug-in zum Verbot des Verbrauchs von Nachrichtenwarteschlangen und das Plug-in zum Verbot des Datenbankschreibvorgangs in den Versionen 1.3.0 und 1.4.0 eingeführt , um das Problem der Flussunterbrechung und des Datenkonsistenzschutzes in Remote-Multi-Aktiv-Szenarien zu lösen. In diesem Artikel wird Sermants Praxis in Remote-Multiaktivitätsszenarien analysiert.
1. Lebe mehr an einem anderen Ort
1.1 Was ist das Leben an verschiedenen Orten?
Für ein Softwaresystem hoffen wir, dass es bei einem Systemausfall weiterhin Dienste für die Außenwelt bereitstellen kann. Diese Funktion des Softwaresystems wird als Hochverfügbarkeit bezeichnet, und die Remote-Multi-Aktiv-Architektur wird zur Lösung des Hochverfügbarkeitsproblems verwendet .
Die früheste Systemarchitektur ist im Allgemeinen eine Einzelmaschinenarchitektur. Wenn die Datenbank ausfällt, kann der Betrieb für längere Zeit unterbrochen werden. Um dieses Problem zu lösen, wurde die Datenbank so entwickelt, dass sie aus einer Master-Datenbank und einer Slave-Datenbank besteht. Die Master-Datenbank ist für Lese- und Schreibvorgänge verantwortlich, und die Slave-Datenbank stellt nur Lesevorgänge bereit in Echtzeit mit der Slave-Datenbank synchronisiert werden, um die Konsistenz und Integrität der Daten zu gewährleisten. Wenn in der Hauptbibliothek ein Problem auftritt, wechselt die Slave-Bibliothek zur Hauptbibliothek und arbeitet weiter. Diese Dienste werden jedoch im selben Computerraum oder sogar im selben Schrank bereitgestellt. Wenn der Computerraum ausfällt, kann das System immer noch keine normalen externen Dienste bereitstellen.
Derzeit ist Aktiv-Aktiv in derselben Stadt eine gute Lösung. Zwei Computerräume werden in einer Stadt bereitgestellt. Die beiden Computerräume stellen dieselbe Softwareumgebung bereit und bieten Dienste an. Wenn einer der Computerräume ausfällt, kann der Datenverkehr auf einen anderen Computerraum umgeleitet werden, um die Ausführung fortzusetzen und so eine hohe Verfügbarkeit des Systems sicherzustellen. Wie in Abbildung 1 dargestellt, ist die Datenbank in Computerraum 1 die Hauptdatenbank. Alle Schreibvorgänge in den beiden Computerräumen werden auf der Hauptdatenbank in Computerraum 1 ausgeführt, und Lesevorgänge können die Datenbank in diesem Computerraum lesen. Die physische Entfernung zwischen den beiden Computerräumen ist relativ gering. Gleichzeitig können die beiden Computerräume dedizierte Leitungen für die Netzwerkverbindung verwenden. Daher ist die Netzwerklatenz von Dienstanrufen in verschiedenen Computerräumen gering Computerraum 2 zur Datenbank von Computerraum 1 liegt in einem akzeptablen Bereich.
Abbildung 1: Dual-aktives Architekturdiagramm in derselben Stadt
Die Aktiv-Aktiv-Architektur in derselben Stadt löst das Problem der hohen Verfügbarkeit von Softwaresystemen. Wenn jedoch in einer Stadt eine Naturkatastrophe wie Erdbeben, Überschwemmungen usw. auftritt, bleiben alle in derselben Stadt bereitgestellten Computerräume erhalten beschädigt werden und die Erbringung von Dienstleistungen einstellen. Und da diese Katastrophen äußerst zerstörerisch sind, wird der Systemreparaturzyklus relativ lang sein, was den normalen Betrieb des Unternehmens ernsthaft beeinträchtigen wird. In diesem Fall ist es offensichtlich, dass diese Computerräume in verschiedenen Regionen eingesetzt werden müssen. Gleichzeitig muss die geografische Entfernung dieser Regionen groß genug sein, um dem Risiko von Naturkatastrophen standzuhalten die Remote-Multi-Active-Architektur.
Wie in der Abbildung oben gezeigt, werden Computerraum 1 und Computerraum 2 in zwei Städten bereitgestellt. Um Risiken besser zu widerstehen, können Computerräume in mehreren Regionen bereitgestellt werden Aktiv-Aktiv wird auf Remote-Aktiv-Aktiv aktualisiert.
Das Architekturdiagramm von Remote Multi-Active ist in Abbildung 2 dargestellt. Der Client-Verkehr wird über die Routing-Schicht zur Ausführung an verschiedene regionale Computerräume verteilt. Der Unterschied zur Aktiv-Aktiv-Architektur in derselben Stadt besteht darin, dass Computerräume in verschiedenen Regionen physisch weit voneinander entfernt sind. Die Kosten für die Bereitstellung dedizierter Netzwerkleitungen sind enorm und die Netzwerkverzögerung des Zugriffs zwischen verschiedenen Computerräumen kann nicht ignoriert werden. Es ist notwendig, die Datenbank im lokalen Computerraum zu betreiben. Sie kann nicht rechnerraumübergreifend betrieben werden. Bei der multiaktiven Remote-Architektur ist die Datenbank jedes Computerraums die Hauptdatenbank, und die Daten in verschiedenen Computerräumen werden mit dem zentralen Computerraum und dann vom zentralen Computerraum mit anderen Computerräumen synchronisiert. Da auf die Datenbanken in allen Computerräumen geschrieben werden kann, kommt es zwangsläufig zu Datenkonflikten, wenn verschiedene Computerräume dieselben Daten ändern. Um Datenkonflikte zu lösen, kann ein Teil des Datenverkehrs gemäß der Fragmentierungsrichtlinie auf der Routing-Ebene fest an einen bestimmten Computerraum weitergeleitet werden. Die Richtlinie zur Datenverkehrsfragmentierung kann auf der Geschäftsart oder dem geografischen Standort basieren. Durch Traffic Sharding wird garantiert, dass relevante Anfragen desselben Benutzers an denselben Computerraum weitergeleitet werden, um alle Geschäftsvorgänge abzuschließen, und der Datenverkehr im Computerraum garantiert nur innerhalb des lokalen Computerraums fließt, wodurch die Netzwerklatenz reduziert wird.
Abbildung 2: Diagramm der Remote-Multi-Active-Architektur
1.2 Typische Szenarien mehrerer Aktivitäten an verschiedenen Orten
Die Remote-Multi-Active-Architektur stellt Computerräume in verschiedenen Regionen bereit, um externe Dienste bereitzustellen, um Risiken durch Naturkatastrophen zu widerstehen. Dies ist ein wirksames Mittel, um eine hohe Systemverfügbarkeit zu erreichen. Allerdings macht die Remote-Multi-Active-Architektur das System auch komplexer und bringt neue Anforderungen hinsichtlich Fehlerabschaltung und Datenkonsistenz mit sich:
- Wenn in einem Cloud-Service-Szenario ein Fehler in einer Verfügbarkeitszone auftritt, müssen Verbraucher in der Fehlerzone aufhören, Nachrichten zur Verwendung abzurufen, und gleichzeitig werden die zugewiesenen Nachrichtenwarteschlangen zur Verarbeitung auf Verbraucher in der normalen Verfügbarkeitszone umverteilt. um geschäftliche Ausnahmen zu vermeiden.
- Remote Multi-Active kann das Problem der Datenkonsistenz durch Sharding des Datenverkehrs effektiv lösen. Für globale Daten, wie z. B. Produktmengen, darf beim Schreiben von Daten jedoch nur die globale Datenbank im zentralen Computerraum betrieben werden. Im Allgemeinen muss der Datenverkehr für den Betrieb globaler Daten zum zentralen Computerraum geleitet werden und andere Computerräume dürfen die Datenbank nur lesen. Wenn der Datenverkehr falsch weitergeleitet wird, kann er dennoch in die Datenbank in einem nicht zentralen Computerraum geschrieben werden, was zu Datenkonflikten führt. Zu diesem Zeitpunkt ist es notwendig, die globale Datenbank zu schützen und die Ausführung von Schreibvorgängen in nicht zentralen Computerräumen zu verhindern.
Als Reaktion auf die beiden oben genannten typischen Probleme hat Sermant das Plug-In zum Verbot des Verbrauchs von Nachrichtenwarteschlangen und das Plug-In zum Verbot des Schreibens von Datenbanken entwickelt, um diese zu lösen, die im Folgenden ausführlich vorgestellt werden.
2. Die Nachrichtenwarteschlange verhindert die Verwendung von Plug-Ins
2.1 Einführung in das Plug-in zum Verbot des Nachrichtenwarteschlangenverbrauchs
Mit dem Plug-In zur Verhinderung des Verbrauchs von Nachrichtenwarteschlangen können Mikrodienste das Verbrauchsverhalten der Verbraucher von Nachrichtenwarteschlangen-Middleware dynamisch an die tatsächlichen Anforderungen im laufenden Zustand anpassen und so sicherstellen, dass Nachrichten im Geschäftsverarbeitungsprozess in abnormalen Umgebungen oder Zuständen ordnungsgemäß verwaltet werden und unnötige Nachrichten vermieden werden Auswirkungen auf das Geschäft. Wenn beispielsweise in einem Remote-Multi-Active-Architektursystem ein regionaler Ausfall auftritt und der Datenverkehr unterbrochen werden muss, kann die Funktion zum Verbot des Nachrichtenwarteschlangenverbrauchs in der Verfügbarkeitszone aktiviert werden, in der der Fehler aufgetreten ist, sodass Verbraucher in der normalen Verfügbarkeitszone bleiben können Um das Geschäft abzuwickeln und zu vermeiden, verbraucht der fehlerhafte Bereich Datenverkehr, was zu Geschäftsanomalien führt und eine hohe Verfügbarkeit des Systems gewährleistet. Nach Behebung der Störung kann der Verbrauch wieder aufgenommen werden.
Das Plug-in zum Verbot des Nachrichtenwarteschlangenverbrauchs unterstützt derzeit zwei Nachrichten-Middlewares: Kafka und RocketMQ. Auf der Kafka-Seite implementiert das Plug-in Verbrauchsverbots- und Wiederherstellungsfunktionen auf Themenebene. Bei RocketMQ liegt die Granularität der Verbrauchssteuerung auf der Ebene der Verbraucherinstanz. Sermant unterstützt die Ausgabe von Nachrichtenwarteschlangentypen und bestimmten Themen, deren Nutzung über das Konfigurationscenter verboten werden muss.
Weitere Informationen zum Plug-In zum Verbot des Konsums von Warteschlangen, Konfigurationsanweisungen und Szenendemonstrationen finden Sie im offiziellen Website-Dokument zum Verbot des Konsums von Nachrichtenwarteschlangen .
2.2 Anwendung des Szenarios zum Verbot des Verbrauchs-Plug-In-Fehlers und der Flussunterbrechung in der Nachrichtenwarteschlange
Anwendungsszenario: Ein Softwaresystem verwendet Kafka als Nachrichtenwarteschlange und der Produzent erstellt Nachrichten für das Topic-Test-Thema. Die Topic-Nachricht enthält vier Partitionen. Verfügbarkeitszone A und Verfügbarkeitszone B haben jeweils zwei Verbraucher, die der Testverbrauchergruppe beitreten und Thementestnachrichten konsumieren. Jedem Verbraucher ist eine Partition zugewiesen, die in verschiedenen Regionen, also an verschiedenen Orten, verteilt ist . Zwei weitere Computerräume. Wie nachfolgend dargestellt.
In diesem Szenario kann der Verbraucherdienst, nachdem er die Ausführung des Verbrauchs-Plug-Ins durch Mounten der Nachrichtenwarteschlange von Sermant deaktiviert hat, die vom Verbraucher verbrauchten Themen in Echtzeit steuern und so sicherstellen, dass die Nachrichten im Geschäftsverarbeitungsprozess ordnungsgemäß verwaltet werden anormale Umgebungen oder Zustände.
Wenn die Verfügbarkeitszone A ausfällt, sollten Verbraucher in der Verfügbarkeitszone A den Konsum einstellen. Geben Sie eine globale Konfiguration in der Verfügbarkeitszone A aus, um Verbraucher A und Verbraucher B daran zu hindern, das Topic-Test-Thema zu nutzen, und geben Sie die zugewiesene Nachrichtenwarteschlange frei.
Die Konfiguration des Plug-Ins zum Verbot des Nachrichtenwarteschlangenverbrauchs lautet wie folgt: „EnableKafkaProhibition“ bedeutet, dass die Funktion zum Verbot des Verbrauchs der Kafka-Warteschlange aktiviert wird, und kafkaTopics gibt die Abonnementthemen an, deren Verbrauch verboten werden muss. Informationen zur Bereitstellung der Konfiguration finden Sie im offiziellen Website-Dokument „ Nachrichtenwarteschlange verbietet den Verbrauch“ :
enableKafkaProhibition: true SchädelThemen: - Thementest
Nachdem die Konfiguration bereitgestellt wurde, beenden Verbraucher in Verfügbarkeitszone A den Konsum und Verbraucher in Verfügbarkeitszone B weisen die Partitionen des Topic-Test-Themas neu zu, wie in der folgenden Abbildung dargestellt.
Nachdem die Verfügbarkeitszone A wieder normal ist, kann die Konfiguration erneut über das dynamische Konfigurationscenter ausgegeben werden, um den Verbrauchern A und B die Nutzung des Topic-Test-Topics zu ermöglichen. Nach der Aktivierung der Bereitstellung der Verbrauchskonfiguration löst Kafka eine Neuverteilung aus und den Verbrauchern in den Verfügbarkeitszonen A und B werden Partitionen neu zugewiesen.
Das Plug-In zur Verhinderung des Verbrauchs von Nachrichtenwarteschlangen realisiert die Fehlerabschaltungsfähigkeit der Nachrichtenwarteschlange im Remote-Multi-Aktiv-Szenario und stellt so die Verfügbarkeit des Systems sicher.
3. Plug-in zum Verbot von Datenbankschreibvorgängen
3.1 Einführung in das Plug-in zum Verbot des Nachrichtenwarteschlangenverbrauchs
Nachdem der Dienst durch Mounten des Datenbank-Schreibverbots-Plug-Ins gestartet wurde, kann er die Schreibverbotsfunktion für die angegebene Datenbank dynamisch aktivieren oder deaktivieren. In einem Remote-Multi-Active-Szenario möchten Benutzer das Schreiben von Vorgängen in einzelne oder alle Datenbanken stoppen und nur das Lesen von Daten zulassen, um die Datenintegrität, Konsistenz und Sicherheit des Datenbanksystems sicherzustellen. Beispielsweise ist das Schreiben globaler Daten in eine Unternehmensdatenbank nur im zentralen Computerraum zulässig. Durch die Aktivierung des Datenbankschreibverhinderungs-Plugins wird verhindert, dass abnormaler Datenverkehr in die Datenbank des nichtzentralen Computerraums geschrieben wird In einem Szenario mit mehreren Schreibvorgängen wird der Datenverkehr unterbrochen, bevor er manuell unterbrochen wird. Der Computerraum des Streams verbietet zunächst das Schreiben in die Datenbank und wartet, bis die Datensynchronisierung in anderen Computerräumen abgeschlossen ist, bevor der Stream unterbrochen wird. Die Verwendung des Datenbank-Schreibverbots-Plug-Ins im obigen Szenario stellt die Konsistenz der Datenbankdaten sicher.
Das Datenbank-Schreibverbots-Plug-in unterstützt derzeit MySQL-, MongoDB-, PostgreSQL- und OpenGauss-Datenbanken. Wenn der Microservice ausgeführt wird, können der schreibgeschützte Datenbanktyp und der Name über das Konfigurationscenter ausgegeben werden. Informationen zu bestimmten Schreibvorgängen und Plug-In-Verwendungen, die das Schreibverbot unterstützen, finden Sie in der offiziellen Website der Dokumentdatenbank „ Schreibverbot“ .
3.2 Das Datenbank-Schreibverbots-Plug-in schützt Datenkonsistenzanwendungen
Anwendungsszenario: Unter der Multi-Active-Remote-Architektur wird ein Business-Microservice verwendet, um globale Daten wie den Produktbestand zu ändern. Gleichzeitig werden die globalen Daten in einer MySQL-Datenbank mit dem Namen global gespeichert. Für diese globalen Daten sind Schreibvorgänge nur für den Betrieb der globalen Datenbank im zentralen Computerraum zulässig, und die globalen Datenbanken in anderen Computerräumen können nur Daten lesen. Um die Datenkonsistenz sicherzustellen, wird der Datenverkehr beim Ändern globaler Daten zur Ausführung auf der Routing-Ebene an den zentralen Computerraum weitergeleitet, und andere Lesevorgänge können an jeden Computerraum weitergeleitet werden, wie in der folgenden Abbildung dargestellt.
Wenn die Routing-Schicht beim Schreiben globaler Daten einen Routing-Fehler macht und diese in einem nicht zentralen Computerraum ausführt, ändern der zentrale Computerraum und der nicht zentrale Computerraum gleichzeitig die Menge desselben Produkts Um dies zu verhindern, können die Unternehmens-Microservices das Datenbank-Schreibverbots-Plug-in von Sermant einbinden, um das Schreiben in die globale Datenbank in nicht zentralen Computerräumen zu verhindern.
Das Schreiben in die globale Datenbank ist in dezentralen Computerräumen verboten und die folgende Konfiguration muss über das dynamische Konfigurationscenter erfolgen:
enableMySqlWriteProhibition: true mySqlDatabases: - global
Unter diesen bedeutet „enableMySqlWriteProhibition“ die Aktivierung der Möglichkeit, das Schreiben in die MySQL-Datenbank zu verbieten, und „mySqlDatabases“ wird verwendet, um den Namen der spezifischen Datenbank anzugeben, für die das Schreiben verboten ist. In diesem Beispiel handelt es sich um die globale Datenbank.
Wenn nach der Konfigurationsausgabe Datenverkehr mit abnormalem Routing in die globale Datenbank im dezentralen Computerraum geschrieben wird, löst das Datenbank-Schreibverbots-Plug-in eine java.sql.SQLException-Ausnahme für den Geschäftsmikrodienst aus und verhindert das Schreiben in die Datenbank . Das Geschäftssystem muss diese Ausnahme verarbeiten, beispielsweise einen Wiederholungsvorgang hinzufügen, um den Datenverkehr zur Ausführung an den zentralen Computerraum umzuleiten, um den normalen Betrieb des Systems sicherzustellen. Die Ausführungslogik ist in der folgenden Abbildung dargestellt.
Das Datenbank-Schreibverbots-Plug-in deaktiviert das Schreiben in die angegebene Datenbank in einem Remote-Multi-Aktiv-Szenario, wodurch Schreibvorgänge mit abnormalem Datenverkehr verhindert und die Datenkonsistenz in Datenbanken in verschiedenen Computerräumen sichergestellt werden können.
4. Zusammenfassung
Im Remote-Multi-Aktiv-Szenario kann das Plug-in zum Verbot des Nachrichtenwarteschlangenverbrauchs das Problem der Unterbrechung des Nachrichtenwarteschlangenflusses bei einem Ausfall der Verfügbarkeitszone lösen, sodass Verbraucher in der normalen Verfügbarkeitszone Daten verbrauchen können Wird verwendet, um das Schreiben in die angegebene Datenbank zu verhindern, und hat keinen Einfluss auf das Lesen der Datenbank, um Datenkonflikte zu verhindern.
Sermant hat umfassende Service-Governance-Funktionen in Remote-Multiaktivitätsszenarien erreicht. Sermant wird auch in Zukunft hart daran arbeiten, schrittweise ein umfassenderes Service-Governance-Fähigkeitssystem aufzubauen.
Als Bytecode-Erweiterungs-Framework mit Schwerpunkt auf dem Bereich Service Governance ist Sermant bestrebt, ein leistungsstarkes, skalierbares, leicht zugängliches und funktionsreiches Service-Governance-Erlebnis bereitzustellen und kümmert sich um Leistung, Funktionalität und Erfahrung In jeder Version ist jeder herzlich willkommen.
- Offizielle Website von Sermant : https://sermant.io
- GitHub- Lageradresse: https://github.com/huaweicloud/Sermant