Erfahrungsaustausch mit verteilter PHP-Ablaufverfolgung

In diesem Artikel teilen wir hauptsächlich einige Erfahrungen mit der verteilten PHP-Ablaufverfolgung mit Ihnen und hoffen, allen zu helfen.

Seit der Implementierung von Microservices sind wir auf viele Probleme gestoßen. Das größte Problem besteht darin, Fehler zu beheben. Serviceorientierte Schnittstellen sind normalerweise auf mehrere Dienste angewiesen. Die Langsamkeit der abhängigen Schnittstellen wirkt sich direkt auf die Servicequalität der Schnittstellen aus.

Langsamkeit, die durch diese Art von Abhängigkeit verursacht wird, ist online sehr verbreitet, aber es ist nicht einfach, Fehler zu beheben. Der Grund dafür ist, dass viele Protokollentwickler die Protokolle online verfolgen, was für sie nicht sehr intuitiv ist Entwickler Und einige Unternehmensentwickler können den spezifischen Ausführungsstatus online nicht sehen. Im Allgemeinen stellen diese kleinen Wahrscheinlichkeitsfehler im System versteckte Gefahren dar. Wenn der Verkehr zunimmt, werden diese versteckten Gefahren verstärkt oder führen sogar direkt zu großen Online-Fehlern. Um ähnliche Dinge zu vermeiden Am intuitivsten ist es, verteilte Tracing-Systeme für statistische Analysen zu verwenden.

Wir sehen oft große Namen, die darüber sprechen, wie man die Online-Leistung optimiert und verbessert. Tatsächlich gibt es einen wichtigen Link, den sie nicht erwähnt haben. Sie sind: Wie findet man Fehler mit geringer Wahrscheinlichkeit? Verteilte Trackingsysteme sind in großen Internetunternehmen weit verbreitet, kleine und mittlere Unternehmen verfügen jedoch nicht über die technische Stärke, dieses System zu implementieren. Aus unserer Sicht ist das System für das Unternehmen immer noch sehr wichtig und wir müssen es stärken. Nur wenn wir in der Lage sind, Probleme zu finden, ist dies das Ziel, das ich immer habe umgesetzt.

Die spezifische Implementierung des verteilten Trackingsystems ist technisch schwierig. Es erfordert Leistungserfassung, Protokollierung, Protokollsammlung und -sortierung, Protokollübertragung, Protokollspeicherung und Protokollierung , Protokoll-Echtzeitanalyse und endgültige Zusammenführungsanzeige erfordern, dass das System in der Lage ist, die Auswirkungen großer Verkehrssysteme zu bewältigen. Wenn beispielsweise jede Schnittstelle 1.000 Protokolle für jede Anforderung generiert, generiert der QPS 2000-Server 2 Mio. Protokolle. Wenn eine Anforderung auf 5 Schnittstellen basiert, werden 10 Mio. Protokolle pro Sekunde generiert Je größer die Zeit, desto größer wird dieser Wert.

Große Internetunternehmen verfügen über viele verteilte Tracking-Systeme, die Milliarden von Datenverkehr aushalten können. Für kleine Unternehmen ist diese Architektur jedoch sehr mühsam und es gibt viele Verknüpfungen wie Abhängigkeiten und verteilte Nachrichten System, verteilter Speicher, verteiltes Rechnen, diese allein werden mindestens 6 oder mehr Server verwenden, was für normale kleine Unternehmen nicht kosteneffektiv ist.

Dieses Mal haben wir zwei Arten von verteiltem Open-Source-Tracking. Eine davon ist eine eigenständige Version für kleine und mittlere Internetunternehmen. Sie kann PV unterstützen 2000-W-Geschäftssystem (z. B. Zahlungssystem). Es gibt auch ein verteiltes Trackingsystem, das verteilte Milliarden von PV unterstützt. Derzeit wurde die eigenständige Version von Fiery geöffnet (https://github.com/weiboad/fiery). Diese Version ist für die Verwendung durch kleine und mittlere Unternehmen konzipiert. Das gesamte Projekt ist ein Jar-Paket, das dies kann Solange es eine Java8-Laufzeit gibt, kann es natürlich direkt verwendet werden. Die verteilte C++-Version basiert auf vielen Dingen und erfordert bestimmte Fähigkeiten für das Betriebs- und Wartungspersonal. Die eigenständige Version wird je nach Situation später veröffentlicht. Diese Kernhandelssysteme, die vollständig Open Source sind und sensible Daten enthalten, sind ebenfalls vollständig verfügbar.

Derzeit gibt es mehrere Methoden der verteilten Nachverfolgung auf dem Markt, von denen einige intern vom Unternehmen verwendet werden und andere in kleinem Umfang kostenlos und in großem Umfang kostenpflichtig sind Dienstleistungen. Die allgemeine verteilte Ablaufverfolgung zeichnet die Leistung jedes Blocks mithilfe statistischer Methoden auf. Die von uns derzeit angebotenen Methoden sind nicht genau die gleichen wie die auf dem Markt. Wir haben durch kontinuierliche Experimente viele Vereinfachungen vorgenommen und nur die Funktionen beibehalten, die wir für wirklich praktisch halten. Wir haben das System für die verteilte Überwachung wichtiger Systeme entwickelt. Wie Zahlungssystem und Transaktionssystem.

Wir zeichnen die spezifische Situation, den Rückgabewert, die spezifische Leistung und andere Informationen jeder Anfrage auf. Durch Tabellenanalyse können wir schnell die Leistung online-abhängiger Schnittstellen (dritte) ermitteln. Party- oder Leistungsstatistiken von Schnittstellen, die nicht eingebettet sind) und eingebettete Schnittstellen werden auch unabhängig für Leistungsrankings analysiert. Mithilfe der Analysetabelle können wir schnell die langsamste Schnittstelle zum Anfordern der Wiedergabe finden und die Gründe für die langsame Online-Leistung analysieren. Durch die Praxis haben wir herausgefunden, dass die Langsamkeit der Datenressourcen, auf die PHP angewiesen ist, in vielen Fällen zu einer schlechten Leistung der PHP-Schnittstelle führt. Daher steht der Einsatz von Ressourcen im Vordergrund. Benutzer können je nach Bedarf weitere Informationen hinzufügen, wodurch eine große Anzahl nutzloser Protokolle reduziert und sparsamer gemacht werden kann.

Dieser Open-Source-Fiery besteht im Wesentlichen aus drei Teilen: der PHP-Intrusive-Point-Bibliothek, dem optimierten Protokollüberwachungs-Push-Modul und dem Server. Diese drei ermöglichen eine verteilte Verfolgung einer Website mit einem PV von weniger als 2000 W.

Die vergrabene Punktbibliothek generiert am Eingang eine Traceid (UUID). Diese Traceid verbirgt die IP-Adresse des Eingangsservers und die Anforderungszeit. Alle nachfolgenden Protokolle werden mit dieser UUID markiert. Nach der Protokollerfassung werden alle relevanten Protokolle entsprechend dieser UUID gespeichert. Die vergrabene Punktbibliothek ist für den Empfang der von anderen Anfragen gesendeten Traceid sowie für das Senden und Verwalten der RPCID während der Laufzeit verantwortlich. Die RPCID ist ein hierarchischer Zähler, über den wir die Reihenfolge und Hierarchie der aufrufenden Beziehung direkt wiederherstellen und dem Entwickler anzeigen können . Wenn außerdem während des PHP-Vorgangs eine Ausnahme auftritt, wird diese von der vergrabenen Punktbibliothek erfasst und aufgezeichnet, damit der Server Deduplizierungsstatistiken erstellen kann. Abschließend werden diese Protokolle auf der lokalen Festplatte des Servers protokolliert. Wenn mehrere PHP-Prozesse gleichzeitig eine Datei schreiben, kann es vorkommen, dass die Protokolle jetzt auf der Grundlage der Prozess-ID plus protokolliert werden Geben Sie als Dateinamen den Projektnamen ein.

Wir haben eine einfache Version der Fiery-Protokollerfassung und -übertragung implementiert. Dies soll die Arbeit des Betriebs- und Wartungspersonals vereinfachen. Es gibt tatsächlich viele offene Quellen, die ähnliche Funktionen bereitstellen Es ist jedoch auf andere Umgebungen angewiesen, was eine gewisse Belastung für Betrieb und Wartung mit sich bringt. Wir haben auch einen experimentellen PHP-Protokollerfassungs- und -übertragungsdienst, es handelt sich jedoch immer noch um eine experimentelle Funktion. Es wird erwartet, dass Benutzer an der Fehlerbehebung und Verbesserung teilnehmen können.

Wir haben viel Arbeit auf der Serverseite von Fiery geleistet und Lucene und Rocksdb integriert, um Anfragen zu indizieren bzw. zu speichern. Wir haben auch einige Arbeiten an den Speicherstatistiken durchgeführt. Derzeit zählen wir nur die Antworten von lokalen Schnittstellen, abhängigen Schnittstellen, MySQL und Curl. Wir bieten auch Statistiken zur Anrufbeziehungswiedergabe und zur Fehlerprotokollwarnung. Durch diese Funktionen können Leistungsstörungen und Systemanomalien an wichtigen Punkten der Linie schnell entdeckt werden. Derzeit handelt es sich nur um eine eigenständige Version, und ich kann sie bei Bedarf in Zukunft auf einen einfacheren verteilten Modus erweitern.

Die oben genannten Dienste gelten nicht nur für Online-Dienste. Wir haben sie auch intern verwendet, um viele interessante Versuche zu unternehmen, z. B. den Zugriff auf eine Reihe von QS-Testumgebungen und Tests nach Abschluss Die von der fehlerhaften Schnittstelle generierte Traceid wird direkt an die Entwicklung gesendet, um den gesamten Aufrufprozess, die Parameter, die Rückgabebedingungen und die Leistung dieser Anfrage herauszufinden und die Analyse zu erleichtern kann für Unit-Tests durchgeführt werden, bevor Sie online gehen. Als ich vor einiger Zeit auf Weibo gepostet habe, um für Fiery zu werben, erwähnte jemand, dass es als Honeypot verwendet werden könnte, um den Hacker-Eindringprozess und spezifische Details anzuzeigen. Folgefunktionen müssen noch von allen erforscht und verbessert werden. Dieses System soll die Lücken im PHP-Ökosystem schließen.

Verwandte Empfehlungen:

So implementieren Sie Session with Redis in der PHP-Verteilung

Probleme im Zusammenhang mit der PHP-Verteilung und der Verarbeitung großer Datenmengen

PHP verteilte interne Speicherfreigabe (Memcache)

Das obige ist der detaillierte Inhalt vonErfahrungsaustausch mit verteilter PHP-Ablaufverfolgung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!