Die Welt steht nicht still. Fortschritt schafft neue technologische Herausforderungen. Entsprechend den sich ändernden Anforderungen muss sich die Architektur von Informationssystemen weiterentwickeln. Heute werden wir über ereignisgesteuerte Architektur, Parallelität, Parallelität, Asynchronität und darüber sprechen, wie Sie in Erlang friedlich mit all dem leben können.
Einführung
Abhängig von der Größe des entworfenen Systems und den Anforderungen daran wählen wir als Entwickler die Methode des Informationsaustauschs im System. Um die Interaktion von Diensten zu organisieren, kann in den meisten Fällen ein Schema mit einem Broker, beispielsweise basierend auf RabbitMQ oder Kafka, eine funktionierende Option sein. Aber manchmal sind der Ablauf der Ereignisse, das SLA und der Grad der Kontrolle über das System so, dass vorgefertigte Nachrichten für uns nicht geeignet sind. Natürlich kann man das System etwas komplizieren, indem man die Verantwortung für die Transportschicht und die Clusterbildung übernimmt, zum Beispiel mit ZeroMQ oder nanomsg. Wenn das System jedoch über genügend Durchsatz und Fähigkeiten eines Standard-Erlang-Clusters verfügt, bedarf die Frage der Einführung einer zusätzlichen Einheit einer detaillierten Untersuchung und wirtschaftlichen Begründung.
Das Thema reaktive verteilte Anwendungen ist recht breit gefächert. Um im Format des Artikels zu bleiben, wird das Thema der heutigen Diskussion nur homogene Umgebungen sein, die auf Erlang/Elixir basieren. Das Erlang/OTP-Ökosystem ermöglicht Ihnen die Implementierung einer reaktiven Architektur mit geringstem Aufwand. Aber auf jeden Fall brauchen wir eine Messaging-Ebene.
Theoretische Basis
Design beginnt mit der Definition von Zielen und Einschränkungen. Das Hauptziel liegt nicht im Bereich der Entwicklung um der Entwicklung willen. Wir benötigen ein sicheres und skalierbares Tool, auf dessen Grundlage wir moderne Anwendungen auf verschiedenen Ebenen erstellen und vor allem entwickeln können: angefangen bei Einzelserveranwendungen für ein kleines Publikum, die sich später zu Clustern von bis zu 50 entwickeln können -60 Knoten, endend mit Clusterverbünden. Das Hauptziel besteht also darin, den Gewinn zu maximieren, indem die Kosten für die Entwicklung und den Besitz des endgültigen Systems gesenkt werden.
Lassen Sie uns vier Hauptanforderungen an das endgültige System hervorheben:
- Сereignisorientiert.
Das System ist jederzeit bereit, den Ereignisfluss zu durchlaufen und die erforderlichen Aktionen durchzuführen; - МSkalierbarkeit.
Einzelne Blöcke können sowohl vertikal als auch horizontal skaliert werden. Das gesamte System muss zu einem unendlichen horizontalen Wachstum fähig sein; - ОFehlertoleranz.
Alle Ebenen und alle Dienste sollten in der Lage sein, sich nach Ausfällen automatisch wiederherzustellen. - Гgarantierte Reaktionszeit.
Zeit ist wertvoll und Benutzer sollten nicht zu lange warten.
Erinnern Sie sich an das alte Märchen „Der kleine Motor, der es konnte“? Damit das entworfene System die Prototypenphase erfolgreich verlässt und fortschrittlich ist, muss seine Grundlage die Mindestanforderungen erfüllen SMOG.
Zum Messaging als Infrastrukturtool und Basis aller Dienste kommt noch ein weiterer Punkt hinzu: Benutzerfreundlichkeit für Programmierer.
Eventorientiert
Damit eine Anwendung von einem einzelnen Server zu einem Cluster wachsen kann, muss ihre Architektur eine lose Kopplung unterstützen. Das asynchrone Modell erfüllt diese Anforderung. Dabei kümmern sich Absender und Empfänger um die Informationslast der Nachricht und kümmern sich nicht um die Übertragung und Weiterleitung innerhalb des Systems.
Skalierbarkeit
Skalierbarkeit und Systemeffizienz liegen nebeneinander. Anwendungskomponenten müssen in der Lage sein, alle verfügbaren Ressourcen zu nutzen. Je effizienter wir Kapazitäten nutzen können und je optimaler unsere Verarbeitungsmethoden sind, desto weniger Geld geben wir für Ausrüstung aus.
Innerhalb einer einzigen Maschine schafft Erlang ein äußerst wettbewerbsfähiges Umfeld. Das Gleichgewicht zwischen Parallelität und Parallelität kann durch Auswahl der Anzahl der für die Erlang-VM verfügbaren Betriebssystem-Threads und der Anzahl der Scheduler, die diese Threads nutzen, eingestellt werden.
Erlang-Prozesse teilen ihren Status nicht und arbeiten im nicht blockierenden Modus. Dies bietet eine relativ geringe Latenz und einen höheren Durchsatz als herkömmliche blockierungsbasierte Anwendungen. Der Scheduler von Erlang sorgt für eine faire Zuweisung von CPU und E/A, und da es keine Blockierung gibt, kann die Anwendung auch bei Spitzenlasten oder Ausfällen reagieren.
Auf Clusterebene besteht auch das Problem der Entsorgung. Wichtig ist, dass alle Maschinen im Cluster gleichmäßig ausgelastet sind und das Netzwerk nicht überlastet wird. Stellen wir uns eine Situation vor: Der Benutzerverkehr landet auf eingehenden Balancern (Haproxy, Nginx usw.), sie verteilen Verarbeitungsanfragen so gleichmäßig wie möglich auf die verfügbaren Backends. Innerhalb der Anwendungsinfrastruktur stellt der Dienst, der die erforderliche Schnittstelle implementiert, nur die letzte Meile dar und muss eine Reihe anderer Dienste anfordern, um auf die ursprüngliche Anfrage zu antworten. Auch interne Anfragen erfordern Routing und Balancing.
Um Datenflüsse effektiv zu verwalten, muss Messaging Entwicklern eine Schnittstelle zur Verwaltung von Routing und Lastausgleich bieten. Dadurch können Entwickler mithilfe von Microservice-Mustern (Aggregator, Proxy, Kette, Zweig usw.) sowohl Standardprobleme als auch selten auftretende Probleme lösen.
Aus betriebswirtschaftlicher Sicht ist Skalierbarkeit eines der Risikomanagementinstrumente. Dabei geht es vor allem darum, Kundenwünsche durch optimale Nutzung der Geräte zu erfüllen:
- Wenn die Leistung der Ausrüstung durch den Fortschritt zunimmt. Aufgrund unvollständiger Software wird es nicht untätig bleiben. Erlang lässt sich vertikal gut skalieren und ist immer in der Lage, alle CPU-Kerne und den verfügbaren Speicher zu nutzen;
- In Cloud-Umgebungen können wir die Menge der Geräte abhängig von der aktuellen oder prognostizierten Auslastung verwalten und SLA garantieren.
Fehlertoleranz
Betrachten wir zwei Axiome: „Misserfolge sind inakzeptabel“ und „Es wird immer Misserfolge geben.“ Für ein Unternehmen bedeutet ein Softwareausfall einen finanziellen Verlust und, was noch schlimmer ist, einen Reputationsverlust. Beim Abwägen zwischen möglichen Verlusten und den Kosten für die Entwicklung fehlertoleranter Software kann oft ein Kompromiss gefunden werden.
Kurzfristig spart eine Architektur mit Fehlertoleranz Geld beim Kauf von Standard-Clustering-Lösungen. Sie sind teuer und haben auch Insekten.
Langfristig amortisiert sich eine fehlertolerante Architektur in allen Entwicklungsstadien um ein Vielfaches.
Durch die Nachrichtenübermittlung innerhalb der Codebasis können Sie das Zusammenspiel der Komponenten innerhalb des Systems bereits in der Entwicklungsphase detailliert ausarbeiten. Dies vereinfacht die Aufgabe, auf Fehler zu reagieren und sie zu verwalten, da alle kritischen Komponenten Fehler behandeln und das resultierende System weiß, wie es nach einem Fehler automatisch in den Normalzustand zurückkehren kann.
Reaktionsfähigkeit
Unabhängig von Ausfällen muss die Anwendung auf Anfragen reagieren und das SLA einhalten. Die Realität ist, dass die Menschen nicht warten wollen, also müssen sich Unternehmen entsprechend anpassen. Es wird erwartet, dass immer mehr Anwendungen sehr reaktionsschnell sind.
Responsive Anwendungen laufen nahezu in Echtzeit. Erlang VM arbeitet im Soft-Echtzeitmodus. Für einige Bereiche wie den Aktienhandel, die Medizin und die Steuerung von Industrieanlagen ist der harte Echtzeitmodus wichtig.
Responsive Systeme verbessern die UX und kommen dem Unternehmen zugute.
Vorläufiges Ergebnis
Bei der Planung dieses Artikels wollte ich meine Erfahrungen mit der Erstellung eines Messaging-Brokers und dem Aufbau komplexer Systeme auf dieser Grundlage teilen. Doch der theoretische und motivierende Teil erwies sich als recht umfangreich.
Im zweiten Teil des Artikels werde ich über die Nuancen der Implementierung von Austauschpunkten, Nachrichtenmuster und deren Anwendung sprechen.
Im dritten Teil werden wir uns mit allgemeinen Fragen der Organisation von Diensten, Routing und Balancing befassen. Lassen Sie uns über die praktische Seite der Skalierbarkeit und Fehlertoleranz von Systemen sprechen.
Das Ende des ersten Teils.
Foto .
Source: habr.com