Zusammenfassung: 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 weit verbreitet, aber es ist schließlich nicht einfach, sie zu beheben...
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.
Diese durch Abhängigkeit verursachte Langsamkeit kommt im Internet sehr häufig vor, ist jedoch nicht einfach zu beheben. Der Grund dafür ist, dass viele Protokollentwickler die Protokolle online verfolgen, was für einige Unternehmen nicht sehr intuitiv ist Entwickler 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, wie Experten darüber sprechen, wie sie die Online-Leistung optimieren und verbessern können. Tatsächlich gibt es einen wichtigen Link, den sie nicht erwähnt haben. Wie entdecken sie 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 Tracking-Systems ist technisch schwierig, um die Leistungserfassung, das Schreiben von Protokollen, das Sammeln und Sortieren von Protokollen, die Protokollübertragung, die Protokollspeicherung, die Protokollindizierung, die Protokollanalyse in Echtzeit und die endgültige Zusammenführungsanzeige des Systems zu erreichen ist erforderlich. In der Lage, die Auswirkungen großer Durchflusssysteme zu bewältigen. Beispielsweise generiert jede Anfrage 1.000 Protokolle pro Schnittstelle, dann generiert der QPS 2000-Server 2 Millionen Protokolle. Wenn eine Anfrage auf 5 Schnittstellen basiert, sind es 10 Millionen Protokolle pro Sekunde Mit der Zeit erhöht sich 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 allein auf verteilte Messaging-Systeme, verteilte Speicherung und verteiltes Computing angewiesen wird mindestens 6 oder mehr Server verwenden, was für normale kleine Unternehmen nicht kosteneffektiv ist.
Diesmal 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 2000w-Geschäftssysteme unterstützen. 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 des verteilten Trackings auf dem Markt, von denen einige unternehmensintern verwendet werden, bei anderen handelt es sich um kleine kostenlose und große kostenpflichtige Dienste. 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 online-abhängige Schnittstellenleistung (Statistiken zur Schnittstellenleistung von Drittanbietern oder nicht vergraben) und das Leistungsranking ermitteln Die Analyse der versteckten Schnittstellen wurde ebenfalls unabhängig durchgeführt. 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.
Dieses 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 verteiltes Tracking für eine 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. Schließlich 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 anhand 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 zwar viele offene Quellen, die ähnliche Funktionen bereitstellen, diese müssen jedoch auf andere Umgebungen zurückgreifen , was für den Betrieb sehr schwierig ist. Es stellt eine gewisse Belastung für Wei dar. 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 der Speicherstatistik durchgeführt. Derzeit zählen wir nur die Antworten von lokalen Schnittstellen, abhängigen Schnittstellen, MySQL und Curl. Wir stellen auch Statistiken zur Anrufbeziehungswiedergabe und zur Fehlerprotokollwarnung bereit. 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 auch viele interessante Versuche unternommen, sie intern zu verwenden. Nach Abschluss des Tests wird die Traceid erstellt Wird direkt an das Entwicklungsteam gesendet, können Entwickler mithilfe von Traceid den gesamten Aufrufprozess, die Parameter, die Rückgabebedingungen und die Leistung dieser Anforderung ermitteln und diese zur einfachen Analyse visuell anzeigen online. 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 Hacking-Prozess 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.
Das obige ist der detaillierte Inhalt vonEine kurze Einführung in die verteilte Ablaufverfolgung in PHP. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
