Diese Woche ging es hauptsächlich darum, die Stabilität verschiedener Dienste im Vorfeld des chinesischen Neujahrsfestes sicherzustellen. Kürzlich stellte ich fest, dass ein bestimmter Dienst während der Hauptverkehrszeiten häufig Zeitüberschreitungen meldete, und ich erinnerte den Eigentümer des Dienstes daran, sich darum zu kümmern. Aber nach ein paar Tagen konnte der Eigentümer des Dienstes den Grund immer noch nicht erklären. Ich musste mich persönlich um das Problem kümmern, denn der Alarm war sehr ernst, und die Timeout-Rate einiger Knoten erreichte bis zu 20%. In diesem Zeitraum dürfte es an den bevorstehenden Feiertagen liegen, der Datenverkehr ist deutlich gestiegen, im Vergleich zu Ende Dezember um 100%. Es besteht also zunächst der Verdacht, dass die Übertragungskapazität des Dienstes unzureichend ist, also wurde zunächst eine Kapazitätserweiterung durchgeführt. Die Erweiterung löste das Problem jedoch nicht, und die Alarmhäufigkeit und die Timeout-Rate blieben im Wesentlichen unverändert. In diesem Fall wurde nach einer Analyse des Quellcodes des Dienstes festgestellt, dass die Schnittstelle des Dienstes zunächst einen nachgelagerten Dienst aufruft und dann asynchron Daten in die Datenbank einfügt. Da der asynchrone Vorgang den Worker-Thread nicht blockiert, liegt der Verdacht zunächst auf diesem nachgelagerten Aufruf (tatsächlich habe ich mich lange mit der Datenbankseite herumgeschlagen).
Ich meldete mich vom Terminal aus bei einem Knoten an, um die Protokolle zu prüfen, und stellte fest, dass alle nachgelagerten Aufrufe tatsächlich an dieselbe IP und denselben Port gingen und an den Scarecrow-Knoten gerichtet waren. Also führte ich zunächst eine Up-Cloud-Operation für diesen Dienst durch, um die Auswirkungen des Verlusts der Scarecrow-Weiterleitung auszuschließen. Nach der Fertigstellung der Cloud stellte ich fest, dass in einer bestimmten geografischen Region (nicht der ursprünglichen geografischen Region) eine große Anzahl von Timeouts auftrat, die auch nach der Erweiterung nicht behoben werden konnten, was mich sehr verwunderte. Ich war sehr neugierig, warum die Timeout-Rate nach dem Wechsel in die Cloud höher wurde. Nachdem ich das Problem von der Cloud aus überwacht und analysiert hatte, stellte ich fest, dass nach der Drosselung des Datenverkehrs einer der nachgelagerten Knoten des Dienstes in der Cloud eine sehr hohe CPU-Auslastung hatte, während die anderen eine sehr niedrige hatten. Ich vermutete ein Lastausgleichsproblem und ging zurück, um den Quellcode des Dienstes zu überprüfen. Nachdem der Dienst die Liste der verfügbaren Knoten für den nachgelagerten Dienst aus der Registrierung abgerufen hatte, rief er nur den ersten Punkt in der Liste auf. So konzentriert sich fast der gesamte Verkehr aus einer bestimmten geografischen Region auf einen der Knoten des nachgelagerten Dienstes. Und wenn er ursprünglich über Scarecrow weitergeleitet wurde, nimmt Scarecrow einen Lastausgleich vor, wenn es den Knoten in der Cloud aufruft. Das anfängliche Problem bestand also darin, dass der Datenverkehr stark anstieg und der Dienst keinen Lastausgleich hatte, so dass eine der Scarecrows überlastet wurde, was wiederum zu einer Zeitüberschreitung führte. Bei den Scarecrows handelt es sich um Proxy-Knoten, die keine eigene Logik haben, so dass die Anzahl der Konkurrenzen, die sie verarbeiten können, viel größer ist und das Timeout-Problem nicht sehr auffällig ist. In der Cloud konzentriert sich der Datenverkehr direkt auf einen Business Node. Eine große Anzahl von Datenverkehrsströmen führt sofort zu einer großen Anzahl von Timeouts bei den Business Nodes.
Mit der obigen Behauptung, gehen Sie zurück, um die Überwachung der Vogelscheuche zu finden, und festgestellt, dass eine Vogelscheuche in der Tat überlastet wurde, CPU-Auslastung tatsächlich mehr als 95 erreicht. Da wir die Ursache kennen, ist der nächste Schritt, zur Cloud zu gehen, um zunächst die Eliminierung von Timeout-Alarmen zu maximieren und dann den Code zu ändern, um einen Algorithmus für den zufälligen Lastausgleich hinzuzufügen. Dies geschah, weil eine Änderung des Codes vor dem Urlaub verfahrenstechnisch mühsamer gewesen wäre. Also verdoppelte ich zunächst die Anzahl der Kerne eines einzelnen Knotens des nachgelagerten Dienstes, was die Verarbeitungskapazität stark erhöht. Als ich dann den Datenverkehr reduzierte, stieg die CPU-Auslastung eines nachgelagerten Knotens plötzlich an und blieb schließlich in einem viel höheren Verhältnis als die der anderen Knoten, was ja auch zu erwarten war. Als sich der gesamte Dienst beruhigt hatte, war der Upload in die Cloud erfolgreich, und zu diesem Zeitpunkt waren die Alarme beseitigt und die Timeout-Rate auf Null gesunken. Der nächste Schritt besteht darin, den Code des geänderten Dienstes zu modifizieren, den Lastausgleichsmechanismus hinzuzufügen und eine neue Codeversion für den Dienst zu veröffentlichen, nachdem die verschiedenen Prozesse genehmigt wurden.
Nachdem ich die neue Version freigegeben hatte, war die CPU-Auslastung jedes Knotens des nachgelagerten Dienstes nahe und das Problem war endlich gelöst.
