Wir haben ein gewisses Maß an Microservice-Transformation am Projektmodul durchgeführt. Zuvor wurden alle Module in einem Projekt (einem großen Ordner) abgelegt, und das Gleiche galt für Online-Bereitstellung wie folgt Die Mängel liegen auf der Hand. Später haben wir es entsprechend den Geschäftsfunktionen in Untermodule aufgeteilt und dann über das RPC-Framework auf die Untermodule zugegriffen. Jedes Untermodul verfügt über einen eigenen unabhängigen Online-Maschinencluster, MySQL, Redis und andere Speicherressourcen Problem mit einem solchen Untermodul Es hat keine Auswirkungen auf andere Module und ist wartbarer und skalierbarer.
Aber in Wirklichkeit sind die Servicefähigkeiten jedes Untermoduls unterschiedlich, wie im Architekturdiagramm nach der Aufteilung nach Untermodul dargestellt. Nehmen Sie an, dass die QPS, die Modul A erreicht, 100 beträgt und A von B abhängt. Gleichzeitig beträgt jeder Anforderungs-QPS von Modul A zu Modul B ebenfalls 100, aber die maximale QPS-Fähigkeit, die Modul B bereitstellen kann, beträgt 50. Wenn es keine Verkehrsbeschränkung gibt, akkumuliert Modul B den Verkehr aufgrund der Überlastung. Dadurch wird das gesamte System nicht verfügbar. Das Steuerungssystem besteht darin, die beste Servicefähigkeit des Untermoduls zu finden, dh den Datenverkehr von Modul A zu Modul B auf 50 QPS zu begrenzen, wodurch sichergestellt wird, dass zumindest einige davon nicht verfügbar sind Anfragen können normal verarbeitet werden, ohne dass das gesamte System heruntergefahren wird, weil ein Unterdienst hängen bleibt.
Unser RPC-Framework ist ein PHP-implementiertes Framework, das hauptsächlich den HTTP-Protokollzugriff unterstützt. Für ein Front-End-A-Modul und für das Back-End-B-Modul muss das B-Modul zuerst als Dienst konfiguriert und dann entsprechend dem Dienstnamen referenziert und darauf zugegriffen werden. Die allgemeine Form der Dienstkonfiguration lautet wie folgt folgt:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Damit auf ein Dienstmodul zugegriffen werden kann, wird es normalerweise als Cluster bereitgestellt. Wenn es einen internen DNS-Dienst gibt, müssen wir natürlich alle IPs des Maschinenclusters konfigurieren. Es kann auch mit dem Domänennamen des Clusters ausgestattet werden.
Zu den Grundfunktionen eines RPC-Frameworks gehören Lastausgleich, Gesundheitsprüfung, Downgrade und Strombegrenzung usw. Unsere Verkehrskontrolle dient der Downgrade- und Strombegrenzungsfunktion. Bevor wir sie im Detail vorstellen, wollen wir darüber sprechen Erstens ist die Implementierung des Lastausgleichs und der Gesundheitsprüfung die Grundlage für die Implementierung der Flusskontrolle.
Wir haben Zufalls- und Abfragealgorithmen für den Lastausgleich implementiert. Der Zufallsalgorithmus kann durch zufällige Auswahl einer unter allen IPs implementiert werden, was relativ einfach zu implementieren ist. Für den Abfragealgorithmus basieren wir auf Stand-Alone Die vorherige Auswahl lautet: Die IP-Seriennummer wird mithilfe der Apcu-Erweiterung im lokalen Speicher aufgezeichnet, um das Auffinden der nächsten zu verwendenden IP-Seriennummer zu erleichtern.
Die Maschine, auf die zugegriffen wird, fällt möglicherweise aus. Wir zeichnen die IP der fehlgeschlagenen Anforderung in Redis auf und analysieren das aufgezeichnete Fehlerprotokoll, um festzustellen, ob eine Maschinen-IP entfernt werden muss, d. h. die Maschine mit dieser IP gilt als ausgefallen . Der Dienst kann nicht normal bereitgestellt werden. Wir führen die spezifischen Funktionen der Gesundheitsprüfung über die entsprechenden Dienstkonfigurationselemente ein:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
In unserer Code-Implementierung Bei der Service-IP-Konfiguration führen wir auch eine Liste der fehlgeschlagenen IPs, sodass wir bei der IP-Auswahl über den Algorithmus zunächst die fehlgeschlagenen IPs entfernen und die fehlgeschlagenen IPs in einer Datei aufzeichnen müssen. Gleichzeitig verwenden wir den Apcu-Speichercache Beschleunigen Sie den Zugriff, sodass alle unsere Vorgänge grundsätzlich auf dem Speicherzugriff basieren. Es treten keine Leistungsprobleme auf.
Wir zeichnen das Protokoll in Redis nur auf, wenn die Anfrage fehlschlägt. Wann werden wir die fehlgeschlagene IP herausfinden? Dies beinhaltet die Abfrage aller Fehlerprotokolle in der Redis-Liste und die Nummerierung ist ein komplexerer Vorgang . Unsere Implementierung ist eine Möglichkeit für mehrere PHP-Prozesse, die Sperre zu ergreifen. Wer auch immer sie beschlagnahmt, führt Analysevorgänge durch und zeichnet die fehlerhafte IP in einer Datei auf. Da nur ein Prozess den Analysevorgang ausführt, hat dies keine Auswirkungen auf normale Anforderungen. Gleichzeitig wird die Sperre nur dann aufgehoben, wenn sie fehlschlägt. Unter normalen Umständen findet grundsätzlich keine Interaktion mit Redis statt und es kommt zu keinem Leistungsverlust.
Unser Gesundheitscheck basiert auf einem zentralen Redis-Dienst. Was passiert, wenn er hängt? Wenn festgestellt wird, dass der Redis-Dienst selbst ausgefallen ist, fährt das RPC-Framework den Gesundheitsprüfungsdienst automatisch herunter und interagiert nicht mehr mit Redis. Dies hat zumindest keine Auswirkungen auf die normale RPC-Funktion.
Basierend auf der Implementierung der Gesundheitsprüfung können wir eine Flusskontrolle implementieren. Das heißt, wenn wir feststellen, dass die meisten oder alle IPs ausfallen, können wir daraus schließen, dass der Backend-Dienst aufgrund übermäßigen Datenverkehrs nicht antworten kann und die Anfrage fehlschlägt. Zu diesem Zeitpunkt sollten wir den Datenverkehr mit einer bestimmten Strategie begrenzen. Die allgemeine Implementierung besteht darin, den gesamten Datenverkehr direkt zu entfernen. Unsere Implementierung besteht darin, den Datenverkehr schrittweise zu reduzieren, bis der Anteil der ausgefallenen IPs auf einen bestimmten Wert sinkt Versuchen Sie dann, den Datenverkehr schrittweise zu erhöhen und zu verringern. Dies kann ein zyklischer Prozess sein, dh eine dynamische Flusssteuerung, und schließlich werden wir einen optimalen Flusswert finden. Lassen Sie uns die Funktion der Flusskontrolle durch entsprechende Konfiguration vorstellen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Das Statusdiagramm der Flusskontrolle wird wie folgt beschrieben:
Wie kann man die Durchflussrate bei einem bestimmten Verhältnis steuern? Durch zufällige Auswahl, z. B. Erhalten einer Zufallszahl und Beurteilen, ob sie in einen bestimmten Bereich fällt. Durch die Begrenzung des Flusses auf einen optimalen Wert können die meisten Anfragen normal funktionieren und die geringsten Auswirkungen auf die Benutzer haben. Gleichzeitig wird festgestellt, dass das Flusskontrollverhältnis eines bestimmten Moduls unter 1 liegt. Da das entsprechende Modul einen systemweiten Engpass darstellt, sollte der nächste Schritt darin bestehen, die Hardwareressourcen zu erhöhen oder die Leistung unseres Programms zu optimieren.
Verwandte Empfehlungen:
Detaillierte Erläuterung von Beispielen des RPC-Frameworks
Detaillierte Erläuterung des Codes für PHP-Remote-Aufrufe und RPC-Framework (Bild )
Einfache Verwendung von PHPRPC
Das obige ist der detaillierte Inhalt vonDas RPC-Framework in PHP implementiert ein Flusskontrollsystem basierend auf Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!