Microservice Architektur ist in der Softwareentwicklung weit verbreitet. Unternehmen, die es verwenden, sehen sich neben den Schwierigkeiten bei der Implementierung der Geschäftslogik auch verteilten Fehlern gegenüber.
Verteilte Rechenfehler sind gut dokumentiert, aber schwer zu erkennen. Infolgedessen wird der Aufbau einer groß angelegten und zuverlässigen verteilten Systemarchitektur zu einer komplexen Herausforderung. Code, der auf einem monolithischen System gut aussieht, kann zu einem Problem werden, wenn Sie zum Netzwerk wechseln. Mail.ru Cloud Solutions-
Teamübersetzte einen Artikel, dessen Autor seit mehreren Jahren an der Erkennung typischer Fehler im Produktionscode beteiligt ist, und untersuchte die Gründe, die zu diesem Ergebnis führten. Dieser Artikel enthält Richtlinien zur Codeüberprüfung, die der Autor als grundlegende Checkliste verwendet.
Das Remote-System fällt aus
Unabhängig davon, wie sorgfältig das System entworfen wurde, wird es irgendwann abstürzen - dies ist eine Tatsache, wenn die Software in Produktion geht.
Ausfälle treten aus verschiedenen Gründen auf: Fehler, Infrastrukturprobleme, plötzliche Verkehrsspitzen, Verfall der Vernachlässigung, aber sie treten fast immer auf. Die Robustheit und Zuverlässigkeit der gesamten Architektur hängt davon ab, wie die aufrufenden Module mit Fehlern umgehen:
- . . , , . — . , .
- . , . ? ? , ? ? .
Diese Situation ist schlimmer als ein vollständiger Fehler, da nicht bekannt ist, ob das Remote-System betriebsbereit ist. Um dieses Szenario zu handhaben, sollten Sie daher immer nach den unten beschriebenen Problemen suchen.
Einige der Probleme können mithilfe von Service Mesh-Technologien wie Istio transparent im Anwendungscode gelöst werden. Sie müssen jedoch sicherstellen, dass solche Probleme unabhängig von der Methode behandelt werden:
- Legen Sie Zeitüberschreitungen für Remote-Systemaufrufe fest . Dies gilt auch für Zeitüberschreitungen für Remote-API- und Datenbankaufrufe sowie für die Veröffentlichung von Ereignissen. Überprüfen Sie, ob für alle Remote-Systeme in Anrufen nachfolgende und angemessene Zeitüberschreitungen festgelegt sind. Dadurch wird vermieden, dass beim Warten Ressourcen verschwendet werden, wenn das Remote-System nicht mehr reagiert.
- -. , — . , .
, - (, ). , , . — , . - (Circuit Breaker). , , Hystrix. . , Circuit Breaker . — .
- - . - — , . , . , -. , .
- . , . , , .
- . , ( API, ), — . : , , . .
,
- , API . - API. , API . API API, — .
- SLA — . SLA , . , .
SLA : — . , SLA. — , , . - API-. SLA — SLA.
- . — , . , , , . .
— «» , «» . , id = 123, id =123. , «» , « ». .
- . , , . , Redis, . , .
- . API (), ? , , ? API ?
- . , , , . . . , , . . .
- Überprüfen Sie die Eingabe an jedem Einstiegspunkt. In einer verteilten Umgebung kann jeder Teil des Systems aus Sicherheitsgründen gefährdet sein oder Fehler aufweisen. Daher muss jedes Modul prüfen, was es als Eingabe empfängt. Und gehen Sie nicht davon aus, dass er saubere, dh sichere Eingaben erhält.
- Speichern Sie niemals Anmeldeinformationen in einem Code-Repository. Dies ist ein sehr häufiger Fehler und schwer zu beseitigen. Anmeldeinformationen sollten jedoch immer von einem externen, vorzugsweise sicheren Speicher in die Systemlaufzeit geladen werden.
Ich hoffe, Sie finden diese Richtlinien hilfreich, um häufige Fehler im Code verteilter Systeme zu reduzieren.
Viel Glück!
Was noch zu lesen: