Die Welt steht nicht still. Fortschritt schafft neue technologische Herausforderungen. Entsprechend den sich ändernden Anforderungen sollte sich auch die Architektur von Informationssystemen weiterentwickeln. Heute werden wir über ereignisorientierte Architektur, Wettbewerbsfähigkeit, Parallelität, Asynchronität und darüber sprechen, wie Sie mit all dem in Erlang friedlich leben können.
Einführung
Abhängig von der Größe des zu entwerfenden Systems und den Anforderungen dafür wählen wir als Entwickler die Methode für den Informationsaustausch im System. In den meisten Fällen kann eine Arbeitsoption zum Organisieren der Interaktion von Diensten ein Schema mit einem Broker sein, das beispielsweise auf RabbitMQ oder kafka basiert. Aber manchmal sind der Ereignisfluss, die SLA und die Kontrolle über das System so, dass Ready Messaging nicht zu uns passt. Natürlich können Sie das System etwas komplizieren, indem Sie die Verantwortung für die Transportschicht und die Clusterbildung übernehmen, beispielsweise mit ZeroMQ oder Nanomsg. Wenn das System jedoch über genügend Bandbreite und Funktionen eines Standard-Erlang-Clusters verfügt, erfordert das Problem der Einführung einer zusätzlichen Entität eine detaillierte Untersuchung und wirtschaftliche Begründung.
Das Thema reaktive verteilte Anwendungen ist ziemlich umfangreich. Um im Format des Artikels zu bleiben, werden in der heutigen Diskussion nur homogene Umgebungen behandelt, die auf der Basis von Erlang / Elixir erstellt wurden. Das Erlang / OTP-Ökosystem ermöglicht eine kostengünstige reaktive Architektur. In jedem Fall benötigen wir jedoch eine Messaging-Schicht.
Theoretische Grundlage
Design beginnt mit der Definition von Zielen und Grenzen. Das Hauptziel ist nicht Entwicklung für Entwicklung. Wir brauchen ein sicheres und skalierbares Tool, auf dessen Grundlage wir moderne Anwendungen auf verschiedenen Ebenen erstellen und vor allem entwickeln können: von Einzelservern für eine kleine Zielgruppe, die sich später zu Clustern mit bis zu 50 bis 60 Knoten entwickeln können, die mit Clusterverbänden enden. Das Hauptziel besteht daher darin, den Gewinn zu maximieren, indem die Entwicklungskosten und der Besitz des endgültigen Systems gesenkt werden.
Es gibt 4 Hauptanforderungen für das endgültige System:
- Mit alltäglicher Orientierung.
Das System ist immer bereit, einen Strom von Ereignissen durch sich selbst zu leiten und die erforderlichen Aktionen auszuführen. - Skalierbarkeit.
Einzelne Blöcke können sowohl vertikal als auch horizontal skaliert werden. Das gesamte System sollte in der Lage sein, das horizontale Wachstum zu begrenzen. - Über Fehlertoleranz.
Alle Ebenen und alle Dienste sollten in der Lage sein, Fehler automatisch zu beheben. - Garantierte Reaktionszeit.
Zeit ist wertvoll und Benutzer sollten nicht zu lange warten.
Erinnern Sie sich an das alte Märchen über "Der kleine Motor, der könnte", auch bekannt als "Der Motor, der könnte"? Damit das entworfene System erfolgreich aus dem Prototypenstadium hervorgeht und fortschrittlich ist, muss seine Grundlage die Mindestanforderungen von SMOG erfüllen .
Messaging wird als Infrastruktur-Tool und Basis für alle Dienste hinzugefügt: Benutzerfreundlichkeit für Programmierer.
Ereignisorientierung
Damit eine Anwendung von einem einzelnen Server zu einem Cluster wachsen kann, muss ihre Architektur eine schwache Konnektivität bieten. Das asynchrone Modell erfüllt diese Anforderung. Darin kümmern sich der Absender und der Empfänger um das Laden der Informationen der Nachricht und sorgen sich nicht um die Übertragung und Weiterleitung innerhalb des Systems.
Skalierbarkeit
Skalierbarkeit und Systemleistung stehen nebeneinander. Anwendungskomponenten müssen in der Lage sein, alle verfügbaren Ressourcen zu nutzen. Je effizienter wir die Kapazitäten nutzen können und je optimaler unsere Verarbeitungsmethoden sind, desto weniger Geld geben wir für Geräte aus.
Erlang schafft ein wettbewerbsintensives Umfeld innerhalb einer einzigen Maschine. Das Gleichgewicht zwischen Parallelität und Parallelität kann festgelegt werden, indem die Anzahl der für Erlang VM verfügbaren Betriebssystem-Threads und die Anzahl der Scheduler ausgewählt werden, die über diese Threads verfügen.
Erlang-Prozesse haben keinen gemeinsamen Status und arbeiten im nicht blockierenden Modus. Dies bietet eine relativ geringe Latenz und eine höhere Bandbreite als herkömmliche Anwendungen, die auf der Blockierung der Synchronisation basieren. Der Erlang-Scheduler sorgt für eine gerechte Verteilung von CPU und E / A, und das Fehlen von Sperren ermöglicht es der Anwendung, auch bei Spitzenlasten oder Ausfällen zu reagieren.
Auf Clusterebene besteht ebenfalls ein Recyclingproblem. Es ist wichtig, dass alle Computer im Cluster gleichmäßig ausgelastet sind und das Netzwerk nicht überlastet ist. Stellen Sie sich eine Situation vor: Der Benutzerverkehr landet auf eingehenden Balancern (Haproxy, Nginx usw.) und verteilt die Verarbeitungsanforderungen so gleichmäßig wie möglich auf die verfügbaren Backends. Im Rahmen der Anwendungsinfrastruktur ist ein Dienst, der die erforderliche Schnittstelle implementiert, nur die letzte Meile, und er muss eine Reihe anderer Dienste anfordern, um die ursprüngliche Anforderung zu beantworten. Interne Abfragen erfordern auch Routing und Balancing.
Um Datenflüsse effektiv verwalten zu können, muss Messaging Entwicklern eine Schnittstelle zur Steuerung des Routings und des Lastausgleichs bieten. Dank dessen können Entwickler mithilfe von Microservice-Mustern (Aggregator, Proxy, Kette, Zweig usw.) sowohl Standardaufgaben lösen als auch selten auftreten.
Aus geschäftlicher Sicht ist Skalierbarkeit eines der Risikomanagement-Tools. Die Hauptsache ist, die Anforderungen der Kunden durch optimalen Einsatz von Geräten zu erfüllen:
- Mit einer Erhöhung der Ausrüstungskapazität infolge des Fortschritts. Es wird aufgrund von Softwarefehlern nicht inaktiv sein. Erlang skaliert perfekt vertikal und kann immer alle CPU-Kerne und den verfügbaren Speicher recyceln.
- In bewölkten Umgebungen können wir die Anzahl der Geräte abhängig von der aktuellen oder vorhergesagten Last steuern und SLA garantieren.
Fehlertoleranz
Betrachten Sie zwei Axiome: "Fehler sind inakzeptabel" und "Fehler werden immer sein". Für Unternehmen ist ein Softwarefehler ein Geldverlust und ein schlechterer Ruf. Wenn Sie zwischen potenziellen Verlusten und den Kosten für die Entwicklung fehlertoleranter Software abwägen, finden Sie häufig einen Kompromiss.
Kurzfristig spart die Architektur mit Fehlertoleranz Geld beim Kauf schlüsselfertiger Clustering-Lösungen. Sie sind teuer und haben auch Fehler.
Langfristig trägt die fehlertolerante Architektur in allen Entwicklungsphasen immer wieder die Kosten ihrer Anwendung.
Durch Messaging innerhalb der Codebasis in der Entwurfsphase können Sie das Zusammenspiel von Komponenten innerhalb des Systems detailliert ausarbeiten. Dies vereinfacht das Reagieren und Verwalten von Fehlern, da alle kritischen Komponenten Fehler behandeln und das resultierende System weiß, wie es nach einem Entwurf automatisch zum Normalzustand zurückkehren kann.
Reaktionsfähigkeit
Unabhängig von Fehlern muss die Anwendung auf Anforderungen reagieren und SLAs erfüllen. Die Realität ist, dass die Leute nicht warten wollen, also muss sich das Geschäft anpassen. Es wird erwartet, dass mehr Anwendungen sehr schnell reagieren.
Responsive Anwendungen arbeiten nahezu im Echtzeitmodus. Erlang VM arbeitet im weichen Echtzeitmodus. Für einige Bereiche wie Börsenhandel, Medizin, Industrieausrüstungsmanagement ist der harte Echtzeitmodus wichtig.
Responsive Systeme verbessern UX und helfen Unternehmen.
Vorläufiges Ergebnis
Bei der Planung dieses Artikels wollte ich die Erfahrungen beim Erstellen eines Messaging-Brokers und beim Erstellen komplexer Systeme auf dieser Basis teilen. Der theoretische und motivierende Teil erwies sich jedoch als ziemlich umfangreich.
Im zweiten Teil des Artikels werde ich über die Nuancen der Implementierung von Austauschpunkten, Messaging-Vorlagen und deren Anwendung sprechen.
Im dritten Teil betrachten wir die allgemeinen Fragen der Serviceorganisation, des Routings und des Ausgleichs. Lassen Sie uns über die praktische Seite der Skalierbarkeit und Fehlertoleranz von Systemen sprechen.
Das Ende des ersten Teils.
Foto @lucabravo .