{"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 verteilter Anwendungen. Zweite Ann\u00e4herung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

<\/p>\n

Kollegen, ich plane f\u00fcr Mitte des Sommers die Ver\u00f6ffentlichung eines weiteren Artikels \u00fcber das Design von Systemen f\u00fcr den Massendienst: \u201eExperiment VTrade\u201c \u2013 der Versuch, ein Framework f\u00fcr Handelssysteme zu schreiben. Der Zyklus wird die Theorie und Praxis des Aufbaus von B\u00f6rsen, Auktionen und Gesch\u00e4ften behandeln. Am Ende des Artikels lade ich dazu ein, \u00fcber die f\u00fcr Sie interessantesten Themen abzustimmen.
\n<\/em><\/p>\n

<\/p>\n

\"Bausteine<\/p>\n

<\/p>\n

Dies ist der abschlie\u00dfende Artikel des Zyklus \u00fcber verteilte reaktive Anwendungen in Erlang\/Elixir. In dem ersten Artikel<\/a><\/noindex> lassen sich die theoretischen Grundlagen der reaktiven Architektur finden. Der zweite Artikel<\/a><\/noindex> illustriert die grundlegenden Muster und Mechanismen zum Aufbau solcher Systeme.<\/p>\n

<\/p>\n

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

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

Organisation der Dienste<\/h2>\n

<\/p>\n

Im echten Leben m\u00fcssen bei der Entwicklung eines Dienstes oft mehrere Interaktionsmuster in einem Controller kombiniert werden. Zum Beispiel sollte der Dienst users, der f\u00fcr die Verwaltung der Benutzerprofile des Projekts zust\u00e4ndig ist, auf req-resp-Anfragen reagieren und \u00fcber Aktualisierungen der Profile \u00fcber pub-sub informieren. Dieser Fall ist ziemlich einfach: Hinter dem Messaging steht ein Controller, der die Logik des Dienstes implementiert und Aktualisierungen ver\u00f6ffentlicht.<\/p>\n

<\/p>\n

Die Situation wird komplizierter, wenn wir einen ausfallsicheren verteilten Dienst implementieren m\u00fcssen. Stellen wir uns vor, dass sich die Anforderungen an users ge\u00e4ndert haben: <\/p>\n

<\/p>\n

    \n
  1. Jetzt muss der Dienst Anfragen auf 5 Knoten im Cluster verarbeiten, <\/li>\n
  2. die M\u00f6glichkeit haben, Hintergrundverarbeitungsaufgaben auszuf\u00fchren, <\/li>\n
  3. und auch in der Lage sein, dynamisch die Listen der Abonnements f\u00fcr die Aktualisierungen der Profile zu verwalten.<\/li>\n<\/ol>\n

    <\/p>\n

    Hinweis:<\/em> Die Frage der konsistenten Speicherung und Replikation von Daten betrachten wir nicht. Angenommen, diese Fragen wurden zuvor gel\u00f6st und in der System existiert bereits eine zuverl\u00e4ssige und skalierbare Speicherungsschicht, und die Handler haben Mechanismen f\u00fcr die Interaktion mit dieser.<\/p>\n

    <\/p>\n

    Die formale Beschreibung des Dienstes users hat sich kompliziert. Aus Sicht des Programmierers sind die \u00c4nderungen dank der Verwendung von Messaging minimal. Um das erste Anliegen zu erf\u00fcllen, m\u00fcssen wir das Load Balancing an der req-resp-Schnittstelle einrichten. <\/p>\n

    <\/p>\n

    Die Anforderung zur Verarbeitung von Hintergrundaufgaben tritt h\u00e4ufig auf. In den Benutzern kann es sich dabei um die \u00dcberpr\u00fcfung von Benutzerdokumenten, die Verarbeitung hochgeladener Medien oder die Synchronisierung von Daten mit sozialen Netzwerken handeln. Diese Aufgaben m\u00fcssen innerhalb des Clusters verteilt und der Fortschritt \u00fcberwacht werden. Daher haben wir zwei L\u00f6sungsm\u00f6glichkeiten: entweder das Aufgabenverteilungsschema aus dem vorherigen Artikel verwenden oder, falls dies nicht passt, einen benutzerdefinierten Task-Planer schreiben, der den Pool der Bearbeiter auf die ben\u00f6tigte Weise verwaltet. <\/p>\n

    <\/p>\n

    Punkt 3 erfordert die Erweiterung des Pub-Sub-Schemas. Und zur Umsetzung m\u00fcssen wir nach der Erstellung des Pub-Sub-Austauschpunkts zus\u00e4tzlich den Controller dieses Punkts im Rahmen unseres Services starten. Dadurch nehmen wir quasi die Logik der Subscription- und Unsubscription-Verarbeitung aus der Messaging-Schicht und implementieren sie in den Benutzern.<\/p>\n

    <\/p>\n

    Letztendlich hat die Dekomposition der Aufgabe gezeigt, dass wir zur Erf\u00fcllung der Anforderungen 5 Instanzen des Services auf verschiedenen Knoten starten und eine zus\u00e4tzliche Entit\u00e4t \u2013 den Pub-Sub-Controller \u2013 schaffen m\u00fcssen, der f\u00fcr die Subscription verantwortlich ist.
    \nF\u00fcr den Start von 5 Bearbeitern ist keine Anpassung des Codes des Services erforderlich. Die einzige zus\u00e4tzliche Ma\u00dfnahme ist die Konfiguration der Lastverteilungsregeln am Austauschpunkt, \u00fcber die wir sp\u00e4ter sprechen werden.
    \nAu\u00dferdem gibt es eine zus\u00e4tzliche Komplexit\u00e4t: Der Pub-Sub-Controller und der benutzerdefinierte Task-Planer m\u00fcssen in einer einzigen Instanz arbeiten. Wiederum sollte der Messaging-Service, als fundamentale Komponente, einen Mechanismus zur Wahl eines Leaders bereitstellen.<\/p>\n

    <\/p>\n

    Wahl eines Leaders<\/h3>\n

    <\/p>\n

    In verteilten Systemen ist die Wahl eines Leaders das Verfahren zur Ernennung eines einzigen 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 ein zentrales Element ist, kennt es alle Controller des Services \u2013 Kandidaten f\u00fcr die F\u00fchrungsrolle. Messaging kann einen Leader ohne Abstimmung ernennen.<\/p>\n

    <\/p>\n

    Alle Dienste erhalten nach dem Start und der Verbindung zu dem Austauschpunkt eine Systemnachricht #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. Falls LeaderPid<\/code> mit pid<\/code> dem aktuellen Prozess \u00fcbereinstimmt, wird er zum Leader ernannt, und die Liste Servers<\/code> enth\u00e4lt alle Knoten und ihre Parameter.
    \nIm Moment des Erscheinens eines neuen und der Abschaltung eines funktionierenden 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

    So wissen alle Komponenten \u00fcber alle \u00c4nderungen Bescheid, und im Cluster gibt es zu jedem Zeitpunkt garantiert einen F\u00fchrer.<\/p>\n

    <\/p>\n

    Vermittler<\/h2>\n

    <\/p>\n

    Um komplexe verteilte Verarbeitungsprozesse zu realisieren und bestehende Architekturen zu optimieren, ist es sinnvoll, Vermittler einzusetzen.
    \nUm den Code der Dienste nicht zu \u00e4ndern und beispielsweise Aufgaben der zus\u00e4tzlichen Verarbeitung, Routing oder Protokollierung von Nachrichten zu l\u00f6sen, kann vor dem Dienst ein Proxy-Handler aktiviert werden, der die gesamte zus\u00e4tzliche Arbeit \u00fcbernimmt.<\/p>\n

    <\/p>\n

    Ein klassisches Beispiel f\u00fcr die Optimierung von Pub-Sub ist eine verteilte Anwendung mit einem Gesch\u00e4fts-Kern, der Ereignisse \u00fcber Aktualisierungen generiert, wie z.B. Preis\u00e4nderungen auf dem Markt, und einer Zugriffsschicht \u2013 N Server, die WebSocket-APIs f\u00fcr Web-Clients bereitstellen.
    \nWenn man es \u201edirekt angeht\u201c, sieht die Bedienung des Clients wie folgt aus:<\/p>\n

    <\/p>\n