{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Bausteine \u200b\u200bverteilter Anwendungen. Zweite Ann\u00e4herung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ank\u00fcndigung<\/strong><\/p>\n

<\/p>\n

Liebe Kollegen, in der Mitte des Sommers plane ich die Ver\u00f6ffentlichung eines weiteren Zyklus von Artikeln zur Gestaltung von Massensystemen: \"Experiment VTrade\" \u2013 ein Versuch, ein Framework f\u00fcr Handelssysteme zu entwickeln. Der Zyklus wird die Theorie und Praxis des Aufbaus von B\u00f6rsen, Auktionen und Gesch\u00e4ften behandeln. Am Ende des Artikels lade ich Sie ein, f\u00fcr die Themen zu stimmen, die Sie am meisten interessieren.
\n<\/em><\/p>\n

<\/p>\n

\"Bausteine<\/p>\n

<\/p>\n

Dies ist der Abschlussartikel des Zyklus \u00fcber verteilte reaktive Anwendungen in Erlang\/Elixir. In im ersten Artikel<\/a><\/noindex> finden Sie die theoretischen Grundlagen der reaktiven Architektur. Der zweite Artikel<\/a><\/noindex> veranschaulicht die grundlegenden Muster und Mechanismen zur Erstellung solcher Systeme.<\/p>\n

<\/p>\n

Heute werden wir die Entwicklung der Codebasis und der Projekte insgesamt ansprechen. <\/p>\n

<\/a><\/noindex><\/p>\n

Organisation von Services<\/h2>\n

<\/p>\n

In der realen Welt m\u00fcssen beim Entwickeln eines Services oft mehrere Interaktionsmuster in einem Controller vereint werden. Zum Beispiel muss der Benutzerservice, der f\u00fcr die Verwaltung der Benutzerprofile im Projekt zust\u00e4ndig ist, sowohl auf requ-resp-Anfragen reagieren als auch \u00fcber Aktualisierungen der Profile \u00fcber pub-sub informieren. Dieser Fall ist relativ einfach: der Messaging-Bereich wird von einem Controller abgedeckt, der die Logik des Services implementiert und Updates ver\u00f6ffentlicht.<\/p>\n

<\/p>\n

Die Situation wird komplexer, wenn wir einen hochverf\u00fcgbaren verteilten Dienst implementieren m\u00fcssen. Nehmen wir an, die Anforderungen an die Benutzer haben sich ge\u00e4ndert: <\/p>\n

<\/p>\n

    \n
  1. Jetzt muss der Dienst Anfragen auf 5 Knoten des Clusters verarbeiten, <\/li>\n
  2. die F\u00e4higkeit zur Ausf\u00fchrung von Hintergrundverarbeitungsaufgaben haben, <\/li>\n
  3. und au\u00dferdem in der Lage sein, dynamisch Abonnent-Listen f\u00fcr Profilaktualisierungen zu verwalten.<\/li>\n<\/ol>\n

    <\/p>\n

    Hinweis:<\/em> Die Frage der konsistenten Speicherung und Replikation von Daten betrachten wir nicht. Angenommen, diese Probleme wurden zuvor gel\u00f6st und es gibt bereits eine zuverl\u00e4ssige und skalierbare Speicherschicht im System, w\u00e4hrend die Verarbeiter Mechanismen zur Interaktion mit ihr haben.<\/p>\n

    <\/p>\n

    Die formale Beschreibung des Benutzer-Dienstes hat sich verkompliziert. Aus Sicht der Programmierung bleiben die \u00c4nderungen dank der Verwendung von Messaging minimal. Um die erste Anforderung zu erf\u00fcllen, m\u00fcssen wir das Load-Balancing am Austauschpunkt f\u00fcr Anfragen und Antworten einrichten. <\/p>\n

    <\/p>\n

    Die Anforderung zur Bearbeitung von Hintergrundaufgaben tritt h\u00e4ufig auf. Bei den Nutzern k\u00f6nnen dies die \u00dcberpr\u00fcfung von Dokumenten, die Verarbeitung hochgeladener Medien oder die Synchronisierung von Daten mit sozialen Netzwerken sein. Diese Aufgaben m\u00fcssen innerhalb des Clusters verteilt und \u00fcberwacht werden. Daher haben wir zwei L\u00f6sungsans\u00e4tze: entweder das Aufgabenverteilungsschema aus dem vorherigen Artikel verwenden oder, falls das nicht passt, einen benutzerdefinierten Task-Planer schreiben, der die Handler entsprechend unseren Bed\u00fcrfnissen steuert. <\/p>\n

    <\/p>\n

    Der Punkt 3 erfordert eine Erweiterung des Pub-Sub-Schemas. Zur Umsetzung m\u00fcssen wir, nachdem wir den Pub-Sub-Austauschpunkt erstellt haben, zus\u00e4tzlich den Controller dieses Punktes im Rahmen unseres Services starten. So extrahieren wir die Logik f\u00fcr die Verwaltung von Abonnements und Abmeldungen aus der Messaging-Ebene in die Implementierung der Nutzer.<\/p>\n

    <\/p>\n

    Die Dekomposition der Aufgabe hat gezeigt, dass wir zur Erf\u00fcllung der Anforderungen 5 Instanzen des Services auf verschiedenen Knoten starten und eine zus\u00e4tzliche Entit\u00e4t \u2013 einen Pub-Sub-Controller \u2013 schaffen m\u00fcssen, der f\u00fcr die Abonnements verantwortlich ist.
    \nF\u00fcr den Start von 5 Handlern ist keine \u00c4nderung am Dienstcode erforderlich. Die einzige zus\u00e4tzliche Ma\u00dfnahme besteht in der Konfiguration der Lastenausgleichsregeln an der Austauschstelle, wor\u00fcber wir sp\u00e4ter sprechen werden.
    \nEs gibt auch eine zus\u00e4tzliche Komplexit\u00e4t: Der Pub-Sub-Controller und der benutzerdefinierte Aufgabenplaner m\u00fcssen in einer einzigen Instanz arbeiten. Der Messaging-Dienst, als grundlegendes Element, sollte einen Mechanismus zur Wahl des F\u00fchrers bereitstellen.<\/p>\n

    <\/p>\n

    Wahl des F\u00fchrers<\/h3>\n

    <\/p>\n

    In verteilten Systemen ist die Wahl des F\u00fchrers das Verfahren zur Ernennung eines einzelnen Prozesses, der f\u00fcr die Planung der verteilten Verarbeitung einer bestimmten Last verantwortlich ist. <\/p>\n

    <\/p>\n

    In Systemen, die nicht zur Zentralisierung neigen, kommen universelle Algorithmen und konsensorientierte Algorithmen wie Paxos oder Raft zum Einsatz.
    \nDa Messaging ein Broker und zentrales Element ist, kennt es alle Dienstcontroller, die als Kandidaten f\u00fcr die F\u00fchrerschaft fungieren. Messaging kann einen F\u00fchrer ernennen, ohne eine Abstimmung durchzuf\u00fchren.<\/p>\n

    <\/p>\n

    Alle Dienste erhalten nach dem Start und der Verbindung zur Austauschstelle eine Systemnachricht #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. Falls LeaderPid<\/code> mit pid<\/code> dem aktuellen Prozess \u00fcbereinstimmt, wird er als F\u00fchrer ernannt, und die Liste Servers<\/code> beinhaltet alle Knoten und deren Parameter.
    \nBei der Einf\u00fchrung eines neuen und dem Ausschalten eines aktiven Knotens im Cluster erhalten alle Service-Controller #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> und #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> entsprechend.<\/p>\n

    <\/p>\n

    Somit wissen alle Komponenten \u00fcber alle \u00c4nderungen Bescheid, und im Cluster gibt es jederzeit garantiert einen Leader.<\/p>\n

    <\/p>\n

    Vermittler<\/h2>\n

    <\/p>\n

    F\u00fcr die Umsetzung komplexer verteilter Verarbeitungsprozesse sowie bei der Optimierung vorhandener Architekturen ist es praktisch, Vermittler einzusetzen.
    \nUm den Code der Dienste nicht zu \u00e4ndern und beispielsweise zus\u00e4tzliche Verarbeitung, Routing oder Logging von Nachrichten zu l\u00f6sen, kann vor dem Service ein Proxy-Handler aktiviert werden, der alle zus\u00e4tzlichen Arbeiten \u00fcbernimmt.<\/p>\n

    <\/p>\n

    Ein klassisches Beispiel f\u00fcr die Optimierung von Pub-Sub ist eine verteilte Anwendung mit einem Business-Core, der Ereignisse wie Preis\u00e4nderungen auf dem Markt generiert, und einer Zugriffsschicht \u2014 N Servern, die ein WebSocket-API f\u00fcr Web-Clients bereitstellen.
    \nWenn man es \u201ekonkret\u201c angeht, sieht die Kundenbetreuung folgenderma\u00dfen aus:<\/p>\n

    <\/p>\n