|
|
Veröffentlicht am 15.03.2018 10:03:44
|
|
|
|
Im vorherigen Abschnitt haben wir über die beiden niedrigsten Konzepte des Service Fabric gesprochen, eines ist der Knotentyp und der Knoten auf Hardware-Ebene. Die andere ist die Bewerbung.
Knotentyp ist eine Sammlung von Knoten, die konzeptionelle Abstraktionen von deployierenden Maschinen sind. Für Service Fabric kann ein Node eine physische Maschine, eine virtuelle Maschine oder sogar der derzeit beliebteste Container sein.
Auf dem Knotentyp läuft die Anwendung. Es ist ein abstraktes Verständnis auf der Ebene der Systemsoftware. In einer Anwendung gibt es mehrere Micro Services. Sogar alle zugrundeliegenden Services von Service Fabric, wie FailoverManager Service und Naming Service, sind Microservices.
Alle verteilten Funktionen von Service Fabric entsprechen Micro-Service-Deployments. Wir können dynamisch anpassen, wie viele Instanzen ein Micro Service ausführen muss und wie viele Knoten, um den Lastdruck zu verteilen oder Disaster Recovery-Backups durchzuführen. Jede Instanz hört auf einen anderen Port, und die Lastverteilungsschicht verteilt Anfragen an verschiedene Instanzen.
Tatsächliches Szenario
Stateful Service ist einer der Microservices.
Bevor wir mit der Einführung des Stateful Service beginnen, betrachten wir die folgenden gängigen Geschäftsszenarien.
Sie denken darüber nach, eine Einkaufswagen-Funktion auf Ihrer Website zu implementieren. Nach dem Einloggen legen die Nutzer einige Artikel in ihren Warenkorb.
Beim nächsten Einloggen ruft die Empfangsseite den Warenkorbdienst auf und muss die gespeicherten Warenkorbdaten von diesem Dienst erneut lesen und anzeigen.
Wenn ja, wie würden Sie das erreichen?
Wenn die Anzahl der Nutzer nicht besonders groß ist, fügen wir der Datenbank eine Einkaufswagentabelle hinzu und ordnen sie der Benutzertabelle zu. Die Cart-Tabelle enthält ein Benutzer-ID-Feld und speichert eine große Menge an Nutzer-Cart-Daten.
Das bringt dann einige Folgeprobleme mit sich.
Wenn die Anzahl der Benutzer weiter steigt, wird die Leistung der Datenbanktabellen weiter abnehmen.
Datenbanktabellendaten müssen regelmäßig gesichert werden, falls Daten verloren gehen
Wenn es ein Problem mit der Datenbankleistung gibt, muss die Tabelle entlarvt oder sogar partitioniert werden
Das Einkaufswagensystem selbst muss alle Anpassungen an der Datenbank übernehmen, und es muss möglicherweise sogar ausgebalanciert werden
Die Wurzel dieses Problems ist, dass das System selbst nicht dafür ausgelegt ist, skalierbar zu sein. Darüber hinaus sind Datenbanken ein potenzieller Engpass und eine Bedrohung für die Leistung.
Staatlicher Dienst
Betrachten wir eine völlig neue Architektur.
Von Anfang an verfügt das Einkaufswagensystem über 36 Unterdienste, die alle Anfragen bearbeiten (36, da die Initialen der Benutzer-ID 0-9 a-z sind, insgesamt 36).
Die Anfrage des Nutzers wird entsprechend dem anfänglichen Hash der Benutzer-ID an einen bestimmten Unterdienst verarbeitet.
Der Subservice speichert die Einkaufswagendaten intern über eine leichte Datenbank und speichert sie auf seinem eigenen Speichergerät.
Jeder Subservice hat außerdem 3 Backups, die die gespeicherten Daten ständig synchronisieren, und diese Backups laufen immer auf verschiedenen Knoten.
Gleichzeitig ist nur ein Backup dafür verantwortlich, Anfragen als Aktivierungszustand zu verarbeiten, und wenn es ein Problem bei der Aktivierung des Backups gibt, aktivieren die anderen beiden Backups gemäß dem Planungsalgorithmus eines davon.
Das Disaster Recovery-Subsystem erstellt ein neues Backup, um sicherzustellen, dass der Subservice immer 3 gesunde Backups hat.
Stateful Service ist eine solche Lösung.
Zurück zum obigen Szenario: Das Einkaufswagensystem ist ein staatlicher Service.
Die 36 Subsysteme sind die 36 Instanzen dieses Stateful Service, die wir Partitionen nennen.
Das Backup unter jedem Subsystem ist Replica, und es gibt 3 Replicas in einer Partition.
Das derzeit aktive Backup ist Active Replica, und die beiden inaktiven Standby-Backups sind Secondary Replica.
Jede Replik desselben Partiions muss auf einem anderen Knoten laufen.
Der Stateful <T>Service-Code verwendet Schnittstellen wie IReliableCollection, IReliableDictionary< T1 und T2 > Daten zu speichern und intern zu synchronisieren.
Zusätzlich kann Stateful Service folgende Funktionen implementieren:
Alle oben genannten Zahlen können zurückgesetzt werden, und du kannst Hunderte von Partitionen im Cart-System haben, um mehr Stress zu laden. Du kannst sogar 5 oder mehr Repliken pro Partition haben, um mehr Robustheit zu gewährleisten.
Externe Systeme kümmern sich nicht darum, wie viele Partitionen der Stateful Service hat, sie werden mit dem Partitionsschlüssel aufgerufen. Der Partitionsschlüssel und die entsprechende Partition werden vom zugrunde liegenden Micro Service of Service Fabric aufgelöst. Zum Beispiel haben Sie in Ihrem Unternehmen vielleicht ein paar Millionen Nutzer, richten aber nur 5 Partitionen ein. Beim Aufrufen des Zustandsdienstes des Einkaufswagens muss das externe System lediglich die Benutzer-ID (Partitionsschlüssel) und die gespeicherten Daten informieren. Diese Anfrage wird automatisch auf eine der fünf Partitionen basierend auf der Benutzer-ID und dem Hash-Algorithmus zugeordnet.
Datenoperationen in Stateful Services unterstützen Transaktionen. Du kannst also bei einem Misserfolg zurückrollen
Ich hoffe, die obige Einführung kann Ihnen helfen, Stateful Service besser zu verstehen.
In den folgenden Abschnitten behandeln wir Codebeispiele für Stateful Service. |
Vorhergehend:Ich hoffe, ihr könnt darüber miteinander sprechenNächster:Siebenundvierzig Möglichkeiten, ein C#-Programm zu optimieren
|
