Haftungsausschluss
Unser Unternehmen führt Anwendungen auf einer Micro Service-Architektur aus, die Tausende von Diensten umfasst. Ich arbeite an einer Backend-Anwendung "X", die mit mehr als 50 Diensten kommuniziert. Frontend-Dienste rufen meinen Dienst "X" auf, um Anforderungen für andere Dienste auszuführen.
Erstens machen Tausende von zufälligen Diensten eine Architektur nicht zu einer Microservices-ähnlichen Architektur. Es ist immer noch ein gewisses Gefühl für ein "Ganzes" und ein wenig Arrangement zwischen den Diensten erforderlich. Richtlinien oder Faustregeln.
Kontextualisieren Sie das Backend innerhalb des 'Ganzen'
Ich nehme an, Ihr Backend ist weder Gateway noch Proxy . Ich denke, es hat sein eigenes Geschäft und einen genau definierten begrenzten Kontext. In Bezug auf andere Dienste ist das Backend also eine Fassade .
Als Fassade gehört das Ausblenden von Implementierungsdetails (z. B. Integrationen mit Remote-Diensten) zu seinen Aufgaben. Für das Front-End (und damit für den Endbenutzer) ist der einzige vertrauenswürdige Gesprächspartner, Xund kein Implementierungsdetail sollte die äußeren Schichten erreichen. Was auch immer unter der Haube passiert ist, es geht den Benutzer nichts an.
Das heißt nicht, dass wir dem Benutzer nicht sagen können, dass etwas schief gelaufen ist. Wir können, aber wir abstrahieren diese Details. Wir werden nicht den Eindruck erwecken, dass etwas Fernes versagt. Im Gegenteil, etwas ist Xfehlgeschlagen und das wars.
Da es sich um Tausende möglicher Integrationen (+50 atm) handelt, ist die Anzahl möglicher und unterschiedlicher Fehler erheblich. Wenn wir jede einzelne einer benutzerdefinierten Nachricht zuordnen, wird der Endbenutzer von so vielen (und nicht kontextualisierten) Informationen überwältigt. Wenn wir alle Fehler einer kleinen Gruppe von benutzerdefinierten Fehlern zuordnen, verzerren wir die Informationen und machen es uns schwer, das Problem zu verfolgen und zu lösen.
Meiner Meinung nach sollten Fehlermeldungen dem Benutzer das Gefühl vermitteln, dass wir etwas tun können, um das Problem zu beheben.
Wenn Endbenutzer dennoch wissen möchten, was unter der Haube vor sich geht, gibt es andere Möglichkeiten, die für das gesamte Unternehmen nützlicher sind.
Rechenschaftspflicht
Andere Dienste geben keine benutzerfreundlichen Nachrichten zurück. Es ist mir nicht möglich, Änderungen von anderen Teams anzufordern, da es mehrere gibt. Es gibt keine vereinbarten Fehlercodes als solche.
Andere Dienste geben eine Zeichenfolgenfehlermeldung zurück. Derzeit wird es an die Benutzeroberfläche zurückgegeben. Manchmal sind die Fehlermeldungen Zeigerreferenzen (falscher Code: /)
Als Entwickler liegt es in Ihrer Verantwortung, diese Argumente den Stakeholdern zugänglich zu machen. Es ist eine Frage der Rechenschaftspflicht. Meiner Meinung nach gibt es ein Leck an technischer Führung und das ist ein echtes Problem, wenn es um verteilte Systeme geht.
Es gibt keine technische Vorstellung. Wenn dies der Fall wäre, würden Dienste nach Faustregeln implementiert, um das System skalierbar zu machen und die Integration zwischen Diensten zu vereinfachen. Im Moment sieht es so aus, als würden Dienstleistungen wild erscheinen, ohne das Gefühl, zum "Ganzen" beizutragen.
Wenn ich gebeten würde, das zu tun, worum Sie gebeten wurden (und manchmal auch), würde ich darüber streiten, ob die Umwandlung der aktuellen Anarchie in benutzerfreundliche Nachrichten den Rahmen von sprengt X.
Zumindest "erheben Sie die Hand", legen Sie Ihre Bedenken offen, legen Sie Ihre Alternativen offen und lassen Sie jeden entscheiden, der die Verantwortung hat.
Machen Sie Ihre Lösungen für das Unternehmen wertvoll
Suchen Sie nach einer Fehlermeldung und weisen Sie meinem Dienst eine Zuordnung zu einer benutzerfreundlichen Nachricht zu. Aber die Dinge können kaputt gehen, wenn der Angerufene Dienst seine Fehlermeldung ändert. Fallback auf eine Standardfehlermeldung, wenn keine benutzerdefinierte Fehlerzuordnung gefunden wird.
Du hast recht. Das ist eine schwache Lösung. Es ist auf lange Sicht spröde und ineffizient.
Ich denke auch, dass dies zu einer Kopplung führt, da Änderungen an diesen Zeichenfolgen Sie möglicherweise dazu zwingen, die Zuordnungen zu brechen. Keine große Verbesserung.
Weitere Ideen für eine skalierbare und nachhaltige Lösung?
Berichterstattung . Behandeln Sie die Fehler, geben Sie ihnen einen Code / ein Ticket / eine ID und melden Sie sie. Lassen Sie dann das Front-End den Bericht visualisieren. Zum Beispiel teilen sich ein Link zum Reporting Service .
Error. <Eine benutzerfreundliche und sehr standardmäßige Fehlermeldung>. Folgen Sie dem Link für weitere Informationen
Auf diese Weise können Sie so viele Dienste integrieren, wie Sie benötigen. Und Sie entlasten sich vom Aufwand, zufällige Zeichenfolgen zu handhaben und in neue zufällige, aber benutzerfreundliche Zeichenfolgen zu übersetzen.
Der Berichtsdienst kann für den Rest der Dienste wiederverwendet werden, sodass Sie bei korrelierten IDs den Benutzern einen Panoramablick auf die Fehler und die Ursachen ermöglichen können. In verteilten Architekturen ist die Rückverfolgbarkeit sehr wichtig.
Später kann der Berichtsservice mit so vielen Zuordnungen erweitert werden, wie Sie benötigen, um lesbare und nützliche Anweisungen zu geben, was zu tun ist, wenn Fehler X auftritt . Ob sich die Saiten hier ändern, spielt überhaupt keine Rolle. Was wir haben (speichern), ist ein Endzustand des Berichts.
Der Berichtsdienst öffnet die Tür zu einer möglichen Normalisierung der Fehler innerhalb der Organisation, da der Dienst eine öffentliche API (daher einen Vertrag) verfügbar macht.