{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Praktische Architektur-Muster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habra!<\/p>\n

<\/p>\n

Angesichts der aktuellen Ereignisse aufgrund des Coronavirus haben viele Internetdienste eine erh\u00f6hte Nachfrage erfahren. Zum Beispiel hat eine der Einzelhandelsketten in Gro\u00dfbritannien einfach die Website f\u00fcr Online-Bestellungen gestoppt<\/a><\/noindex>, da die Kapazit\u00e4ten nicht ausreichten. Und es ist nicht immer m\u00f6glich, einen Server einfach durch leistungsst\u00e4rkere Hardware zu beschleunigen, jedoch m\u00fcssen die Kundenanfragen bearbeitet werden (oder sie wechseln zu den Konkurrenten).<\/p>\n

<\/p>\n

In diesem Artikel werde ich kurz \u00fcber beliebte Praktiken sprechen, die es erm\u00f6glichen, einen schnellen und ausfallsicheren Dienst zu schaffen. Ich habe jedoch nur die Entwicklungsans\u00e4tze ausgew\u00e4hlt, die man jetzt einfach nutzen kann<\/strong>. F\u00fcr jeden Punkt haben Sie entweder bereits fertige Bibliotheken zur Verf\u00fcgung, oder Sie k\u00f6nnen das Problem mithilfe einer Cloud-Plattform l\u00f6sen.<\/p>\n

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

Horizontale Skalierung<\/h1>\n

<\/p>\n

Der einfachste und allgemein bekannte Punkt. Man kann grob sagen, dass es zwei h\u00e4ufig vorkommende Lastverteilungsans\u00e4tze \u2013 horizontale und vertikale Skalierung \u2013 gibt. Im ersten Fall<\/a><\/noindex> erlauben Sie es den Diensten, parallel zu arbeiten, wodurch die Last zwischen ihnen verteilt wird. Im zweiten<\/a><\/noindex> bestellen Sie leistungsst\u00e4rkere Server oder optimieren den Code.<\/p>\n

<\/p>\n

Als Beispiel nehme ich einen abstrakten Cloud-Speicher f\u00fcr Dateien, also eine Art \u00c4quivalent zu OwnCloud, OneDrive und so weiter.<\/p>\n

<\/p>\n

Das Standardbild eines solchen Schemas sehen Sie unten, es zeigt jedoch nur die Komplexit\u00e4t des Systems. Denn wir m\u00fcssen die Dienste irgendwie synchronisieren. Was passiert, wenn ein Benutzer eine Datei von seinem Tablet speichert und sie dann mit seinem Telefon anzeigen m\u00f6chte?<\/p>\n

<\/p>\n

\"Praktische
\nDer Unterschied zwischen den Ans\u00e4tzen: Bei der vertikalen Skalierung sind wir bereit, die Leistung der Knoten zu steigern, w\u00e4hrend wir bei der horizontalen Skalierung neue Knoten hinzuf\u00fcgen, um die Last zu verteilen.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> ist ein ziemlich wichtiges Muster, da es verschiedenen Clients nicht nur erm\u00f6glicht, sich mit verschiedenen Diensten zu verbinden, sondern auch gleiche Ereignisstr\u00f6me zu erhalten. Die Vorteile sind f\u00fcr einfache Anwendungen nicht so offensichtlich, aber es ist \u00e4u\u00dferst wichtig (und einfach) f\u00fcr stark ausgelastete Dienste. Das Wesentliche ist: Eingehende und ausgehende Datenstr\u00f6me sollten sich nicht \u00fcberschneiden. Das bedeutet, dass Sie eine Anfrage nicht senden und eine Antwort erwarten k\u00f6nnen; stattdessen senden Sie eine Anfrage an Dienst A, erhalten aber die Antwort von Dienst B.<\/p>\n

<\/p>\n

Der erste Vorteil dieses Ansatzes ist die M\u00f6glichkeit, die Verbindung (im weitesten Sinne) w\u00e4hrend der Ausf\u00fchrung einer langwierigen Anfrage zu unterbrechen. Nehmen wir als Beispiel eine mehr oder weniger Standardabfolge:<\/p>\n

<\/p>\n

    \n
  1. Der Client hat eine Anfrage an den Server gesendet.<\/li>\n
  2. Der Server hat die langwierige Verarbeitung gestartet.<\/li>\n
  3. Der Server hat dem Client das Ergebnis zur\u00fcckgemeldet.<\/li>\n<\/ol>\n

    <\/p>\n

    Angenommen, es gab in Punkt 2 einen Verbindungsabbruch (entweder wurde das Netzwerk neu verbunden oder der Benutzer wechselte zu einer anderen Seite und unterbrach die Verbindung). In diesem Fall wird es f\u00fcr den Server schwierig sein, dem Benutzer mitzuteilen, was genau verarbeitet wurde. Durch die Anwendung von CQRS wird die Abfolge jedoch etwas anders sein:<\/p>\n

    <\/p>\n

      \n
    1. Der Client hat sich f\u00fcr Updates angemeldet.<\/li>\n
    2. Der Client hat eine Anfrage an den Server gesendet.<\/li>\n
    3. Der Server hat mit \"Anfrage akzeptiert\" geantwortet.<\/li>\n
    4. Der Server hat das Ergebnis \u00fcber den Kanal aus Punkt \"1\" \u00fcbermittelt.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Praktische<\/p>\n

      <\/p>\n

      Wie zu sehen ist, ist das Schema etwas komplexer. Dar\u00fcber hinaus fehlt der intuitive Ansatz von Anfrage und Antwort. Doch wie bereits erw\u00e4hnt, wird ein Verbindungsabbruch w\u00e4hrend der Verarbeitung der Anfrage nicht zu einem Fehler f\u00fchren. Au\u00dferdem, falls der Benutzer tats\u00e4chlich von mehreren Ger\u00e4ten mit dem Dienst verbunden ist (z.B. von einem Mobiltelefon und einem Tablet), kann sichergestellt werden, dass die Antwort auf beide Ger\u00e4te kommt.<\/p>\n

      <\/p>\n

      Interessanterweise wird der Code zur Verarbeitung eingehender Nachrichten fast identisch (nicht zu 100%) f\u00fcr Ereignisse, die vom Client selbst beeinflusst werden, sowie f\u00fcr andere Ereignisse, einschlie\u00dflich solcher von anderen Clients.<\/p>\n

      <\/p>\n

      In der Praxis erhalten wir jedoch zus\u00e4tzliche Vorteile, da der unidirektionale Fluss im funktionalen Stil verarbeitet werden kann (unter Verwendung von RX und \u00e4hnlichen Technologien). Das ist bereits ein erheblicher Vorteil, da die Anwendung im Grunde vollst\u00e4ndig reaktiv gestaltet werden kann, und das auch mit einem funktionalen Ansatz. F\u00fcr umfangreiche Programme kann dies die Ressourcen f\u00fcr Entwicklung und Wartung erheblich sparen.<\/p>\n

      <\/p>\n

      Wenn wir diesen Ansatz mit horizontaler Skalierung kombinieren, erhalten wir die M\u00f6glichkeit, Anfragen an einen Server zu senden und die Antworten von einem anderen zu erhalten. Auf diese Weise kann der Client den f\u00fcr ihn passenden Dienst ausw\u00e4hlen, w\u00e4hrend das System innerlich die Ereignisse dennoch korrekt verarbeiten kann.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Wie Sie wissen, ist eine der Hauptmerkmale eines verteilten Systems das Fehlen einer gemeinsamen Zeit und eines gemeinsamen kritischen Abschnitts. F\u00fcr einen Prozess k\u00f6nnen Sie eine Synchronisation (mit denselben Mutexen) durchf\u00fchren, innerhalb derer Sie sicher sind, dass niemand sonst diesen Code ausf\u00fchrt. F\u00fcr ein verteiltes System ist das jedoch riskant, da dies mit Overhead verbunden ist und die gesamte Sch\u00f6nheit des Skalierens verloren geht \u2013 letzten Endes m\u00fcssen alle Komponenten auf eine warten.<\/p>\n

      <\/p>\n

      Hieraus ergibt sich eine wichtige Erkenntnis \u2013 ein schnelles verteiltes System kann nicht synchronisiert werden, da wir sonst die Leistung verringern w\u00fcrden. Andererseits ist es oft notwendig, eine bestimmte Konsistenz der Komponenten zu gew\u00e4hrleisten. Und daf\u00fcr kann man den Ansatz mit eventual consistency<\/a><\/noindex>, der gew\u00e4hrleistet, dass in Abwesenheit von Daten\u00e4nderungen nach einer bestimmten Zeitspanne nach der letzten Aktualisierung (\"letztlich\") alle Anfragen den zuletzt aktualisierten Wert zur\u00fcckgeben werden.<\/p>\n

      <\/p>\n

      Es ist wichtig zu verstehen, dass f\u00fcr klassische Datenbanken h\u00e4ufig strikte Konsistenz<\/a><\/noindex>, bei der jeder Knoten die gleiche Information besitzt (dies wird oft erreicht, wenn eine Transaktion erst als abgeschlossen betrachtet wird, nachdem der zweite Server geantwortet hat). Hier gibt es einige Erleichterungen durch Isolationsebenen, aber das Grundprinzip bleibt dasselbe \u2013 Sie k\u00f6nnen in einer vollst\u00e4ndig konsistenten Welt leben.<\/p>\n

      <\/p>\n

      Kommen wir jedoch zur\u00fcck zur urspr\u00fcnglichen Aufgabe. Wenn ein Teil des Systems mit eventual consistency<\/a><\/noindex>aufgebaut werden kann, dann kann das folgende Schema erstellt werden.<\/p>\n

      <\/p>\n

      \"Praktische<\/p>\n

      <\/p>\n

      Wichtige Merkmale dieses Ansatzes:<\/p>\n

      <\/p>\n