Wo passt Elixir / erlang in den Microservices-Ansatz? [geschlossen]

In letzter Zeit habe ich einige Experimente mit Docker Compose durchgeführt, um mehrere zusammenarbeitende Microservices bereitzustellen. Ich kann die vielen Vorteile sehen, die Microservices bieten, und jetzt, da es ein gutes Toolset für deren Verwaltung gibt, denke ich, dass es nicht extrem schwierig ist, in den Microservices-Wagen einzusteigen.

Aber ich habe auch mit Elixir experimentiert und ich mag die Vorteile, die sich daraus ergeben. Wie würden Sie Docker mit Elixier (oder Erlang) mischen, da dies das Packen Ihres Codes in mehrere entkoppelte Anwendungen fördert und Hot-Code-Upgrades unterstützt?

Wenn ich zum Beispiel Docker verwenden möchte, weil es Dev-Prod-Parität bietet, wie passt Elixier dazu? Angesichts der Tatsache, dass Docker-Container unveränderlich sind, verliere ich die Möglichkeit, Hotcode-Upgrades durchzuführen, oder? Was ist mit blau / grünen Bereitstellungen oder kanarischen Veröffentlichungen?

Ich meine, ich könnte einfach Microservices mit Elixir schreiben und sie so verwenden, als ob sie in einer anderen Sprache geschrieben wären. Polyglotismus ist sowieso einer der Vorteile von Microservices, aber dann bekomme ich nicht die vollen Vorteile der OTP-Plattform, ich Vermutlich sind reine kollaborative Erlang-Anwendungen viel optimaler als die Verwendung von Zwischenwarteschlangen für die Kommunikation zwischen Mikrodiensten, die in verschiedenen (oder nicht) Sprachen geschrieben sind.

Dies ist eine sehr offene Frage, aber ich werde versuchen zu veranschaulichen, warum Elixir / Erlang die beste Plattform für die Entwicklung verteilter Systeme ist (unabhängig davon, ob Sie mit Microservices arbeiten).

Beginnen wir zunächst mit Hintergrundinformationen. Die Erlang-VM und ihre Standardbibliothek wurden im Voraus für den Aufbau verteilter Systeme entwickelt, und dies zeigt sich wirklich. Soweit ich weiß, ist dies die einzige Laufzeit und VM, die in der Produktion weit verbreitet ist und im Voraus für diesen Anwendungsfall entwickelt wurde.

Anwendungen

Zum Beispiel haben Sie bereits auf "Anwendungen" hingewiesen. In Erlang / Elixir wird Code in Anwendungen gepackt, die:

1. werden als Einheit gestartet und gestoppt. Zum Starten und Stoppen Ihres Systems müssen alle darin enthaltenen Anwendungen gestartet werden
2. Stellen Sie eine einheitliche Verzeichnisstruktur und Konfigurations-API bereit (die nicht XML ist!). Wenn Sie bereits mit einer OTP-Anwendung gearbeitet und diese konfiguriert haben, wissen Sie, wie Sie mit einer anderen arbeiten
3. Enthält Ihren Anwendungsüberwachungsbaum mit allen Prozessen (mit Prozess meine ich "VM-Prozesse", die einfache Berechnungsthreads sind) und deren Status

Die Wirkung dieses Designs ist enorm. Dies bedeutet, dass Elixir-Entwickler beim Schreiben von Anwendungen einen expliziteren Ansatz verfolgen, um:

1. wie ihr Code gestartet und gestoppt wird
2. Welche Prozesse sind Teil einer Anwendung und wie ist der Anwendungsstatus?
3. wie diese Prozesse reagieren und im Falle von Abstürzen oder wenn etwas schief geht, beeinflusst werden

Nicht nur das, die Werkzeuge um diese Abstraktion sind großartig. Wenn Sie Elixir installiert haben, öffnen Sie "iex" und geben Sie Folgendes ein : :observer.start(). Neben der Anzeige von Informationen und Grafiken zu Ihrem Live-System können Sie auch zufällige Prozesse beenden, deren Speichernutzung, Status und mehr anzeigen. Hier ist ein Beispiel für die Ausführung in einer Phoenix-Anwendung:

Der Unterschied besteht darin, dass Anwendungen und Prozesse Ihnen eine Abstraktion bieten, um über Ihren Code in der Produktion nachzudenken . Viele Sprachen bieten Pakete, Objekte und Module hauptsächlich für die Code-Organisation ohne Berücksichtigung des Laufzeitsystems. Wenn Sie ein Klassenattribut oder ein Singleton-Objekt haben: Wie können Sie über die Entitäten nachdenken, die es manipulieren können? Wie können Sie die dafür verantwortliche Entität finden, wenn Sie einen Speicherverlust oder einen Engpass haben?

Wenn Sie jemanden fragen, der ein verteiltes System ausführt, ist dies die Art von Einsicht, die er möchte, und mit Erlang / Elixir haben Sie diese als Baustein.

Kommunikation

All dies ist wirklich nur der Anfang. Beim Aufbau eines verteilten Systems müssen Sie ein Kommunikationsprotokoll und den Datenserialisierer auswählen. Viele Leute wählen HTTP und JSON, was, wenn Sie darüber nachdenken, eine sehr ausführliche und teure Kombination für die Ausführung von RPC-Aufrufen ist.

Mit Erlang / Elixir verfügen Sie bereits über ein sofort einsatzbereites Kommunikationsprotokoll und einen Serialisierungsmechanismus. Wenn Sie möchten, dass zwei Maschinen miteinander kommunizieren, müssen Sie ihnen nur Namen geben, sicherstellen, dass sie dasselbe Geheimnis haben, und fertig.

Jamie sprach auf der Erlang Factory 2015 darüber und wie sie dies nutzen konnten, um eine Spielplattform aufzubauen: https://www.youtube.com/watch?v=_i6n-eWiVn4

Wenn Sie HTTP und JSON verwenden möchten, ist dies auch in Ordnung, und Bibliotheken wie Plug und Frameworks wie Phoenix garantieren, dass Sie auch hier produktiv sind.

Microservices

Bisher habe ich nicht über Microservices gesprochen. Das liegt daran, dass sie bis zu diesem Punkt keine Rolle spielen. Sie entwerfen Ihr System und Ihre Knoten bereits um sehr kleine Prozesse, die isoliert sind. Nennen Sie sie Nanoservices, wenn Sie möchten!

Darüber hinaus werden sie in Anwendungen gepackt, die sie als Entitäten gruppieren, die als Einheit gestartet und gestoppt werden können. Wenn Sie über Anwendungen A, B und C verfügen und diese dann als [A, B] + [C] oder [A] + [B] + [C] bereitstellen möchten, haben Sie aufgrund dieser Probleme nur sehr geringe Probleme zu ihrem inhärenten Design. Oder, noch besser, wenn Sie vermeiden möchten, die Komplexität von Microservices-Bereitstellungen im Voraus in Ihr System aufzunehmen, können Sie sie einfach insgesamt auf demselben Knoten bereitstellen.

Und am Ende des Tages, wenn Sie all dies mit dem Erlang Distributed Protocol ausführen, können Sie sie auf verschiedenen Knoten ausführen und sie können andere erreichen, solange Sie auf sie verweisen, {:node@network, :name}anstatt :name.

Ich könnte noch weiter gehen, aber ich hoffe, ich habe Sie an dieser Stelle überzeugt. :) :)