Design für Skalierbarkeit mit Erlang/OTP

Kapitel 12. Release-Upgrades

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Nachdem dein System in Betrieb gegangen ist, arbeitet es im Hintergrund und bearbeitet tagein, tagaus Anfragen. Es heilt sich selbst, wenn Probleme auftreten, und startet automatisch neu, wenn der Strom ausfällt oder das System neu gebootet wird. Aber wie bei jeder Software musst du sie ständig optimieren, gemeldete Fehler beheben und neue Funktionen hinzufügen. Unabhängig davon, ob du Tausende von Instanzen deiner Kaffeemaschine auf dedizierter Hardware laufen hast, die über eine drahtlose Verbindung überwacht wird, oder ob du ein anderes System hast, das seine Anforderungen mit 100%iger Verfügbarkeit erfüllen muss, Upgrades inbegriffen, solltest du die Software-Upgrade-Fähigkeiten von Erlang/OTP genau studieren. Stell dir vor, du kannst deinen Morgenkaffee nicht trinken, weil ein Firmware-Upgrade für deine Kaffeemaschine im Büro läuft!

Die in der Erlang VM eingebaute Funktionalität, die das dynamische Laden von Modulen ermöglicht, mag für einfache Patches funktionieren, bei denen das Upgrade abwärtskompatibel ist. Aber hast du auch an die Fälle gedacht, in denen du die funktionale API geändert hast? Oder wenn ein Prozess, der einen Call to Completion mit einer alten Version des Codes ausführt, aufgrund einer Änderung des Protokolls nicht mit einem Prozess kommunizieren kann, der eine neue Version ausführt? Wie gehst du ...