Auf dem Weg ins Jahr 2023 wird dieses Jahr ein schwieriges Jahr werden. In diesem Jahr stehen mehrere Herausforderungen an. Eine davon ist die Migration aller Daten, die bisher auf physischen Servern bereitgestellt wurden, in die Cloud. Dann ist da noch die beschleunigte Entwicklung einiger neuer Mitarbeiter im Team, damit sie so schnell wie möglich die Dienste übernehmen können, die derzeit Teil des Hauptgeschäfts sind, und die in der Lage sein müssen, eigenständig Benutzerprobleme zu lösen und die Dienste zu optimieren. Dadurch kann ich einen Teil der Arbeit auf sie übertragen und mich auf wichtige Ziele konzentrieren, die in diesem Jahr voraussichtlich viel Zeit in Anspruch nehmen werden. Hinzu kommt, dass ich eine Phase des persönlichen Lernens in technischen und anderen Bereichen erreicht habe, die die Richtung meines Lebens in den nächsten 7-8 Jahren bestimmen wird.
In dieser Woche lag mein Hauptaugenmerk auf dem Entwurf und der Spezifikation des Logging-Frameworks und der Protokollverfolgung für mehrere Dienste. Zunächst einmal, um das Problem der Protokollverfolgung zu lösen, um in der Lage zu sein, dienstübergreifend auf den Aufruf Prozessprotokoll durch eine einheitliche Trace generiert, müssen nun TraceId vereinheitlicht. Die Typen der TraceId dieser Dienste sind jedoch nicht einheitlich, einige verwenden den Typ Long und andere einen String. Außerdem sind die von diesen Diensten verwendeten Sprachen und Technologien nicht einheitlich. Die direkte Verwendung eines Standard-Frameworks für die verteilte Ablaufverfolgung TraceId sollte nicht in der Lage sein, die aktuelle Situation aller Dienste zu unterstützen, sondern kann nur in einigen der Technologie-Stacks der neueren Dienste verwendet werden.
Aus Gründen der Kompatibilität und der Einfachheit der Umwandlung werden wir daher den benutzerdefinierten Wert vom Typ Long als TraceId verwenden und die Anzahl der Stellen auf 16 Ziffern begrenzen. Die ersten vier Bits beginnen mit 99, was das Merkmal der vereinheitlichten TraceId ist, und die restlichen zwei Bits identifizieren den Dienst. Die nächsten vier Bits sind die aktuellen Mikrosekunden, und die letzten acht Bits sind zwei Sätze von vier zufällig zusammengesetzten Zahlen. Obwohl diese TraceId keine Eindeutigkeit garantiert, ist sie in der aktuellen Situation ausreichend. Wenn es sich bei dem Dienst um einen Java-Technologie-Stack handelt, muss bei der Generierung der TraceId die Thread-Konkurrenz berücksichtigt werden, am besten weisen Sie jedem Thread einen Zufallszahlengenerator zu. Alternativ können Sie auch direkt TreadLocal verwenden.
Der Java-Dienst extrahiert die TraceId aus der Anfrage, wenn die Anfrage verarbeitet wird. Wenn die TraceId mit 99 beginnt, wird keine neue TraceId generiert. Wenn nicht, wird die TraceId wie oben beschrieben erzeugt und im MDC gespeichert. Bei einer asynchronen Ausführung müssen Sie darauf achten, den Inhalt des MDC in den Side-Thread zu kopieren, da sonst die Trace-Informationen verloren gehen. Wenn ein nachgelagerter Dienst aufgerufen werden muss, muss die gespeicherte TraceId an den nachgelagerten Dienst weitergegeben werden. Schließlich muss das MDC geleert werden, wenn die Anfrage verarbeitet wurde, um zu verhindern, dass die Trace-Informationen der nächsten Anfrage verunreinigt werden.
