{"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 Architekturmodelle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr!<\/p>\n

<\/p>\n

Angesichts der aktuellen Ereignisse aufgrund des Coronavirus haben viele Internetdienste einen Anstieg der Last erfahren. Zum Beispiel, eine Einzelhandelskette in Gro\u00dfbritannien hat 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 leistungsf\u00e4higere Hardware zu beschleunigen, jedoch m\u00fcssen die Kundenanfragen bearbeitet werden (oder sie wenden sich an die Konkurrenz).<\/p>\n

<\/p>\n

In diesem Artikel werde ich kurz \u00fcber beliebte Praktiken sprechen, die es erm\u00f6glichen, einen schnellen und ausfallsicheren Dienst zu erstellen. Ich habe jedoch nur die Entwicklungsans\u00e4tze ausgew\u00e4hlt, die derzeit einfach anzuwenden sind.<\/strong>F\u00fcr jeden Punkt stehen Ihnen entweder bereits vorhandene Bibliotheken zur Verf\u00fcgung oder es besteht die M\u00f6glichkeit, die Aufgabe \u00fcber eine Cloud-Plattform zu l\u00f6sen.<\/p>\n

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

Horizontale Skalierung<\/h1>\n

<\/p>\n

Der einfachste und bekannteste Punkt. Allgemein gesagt gibt es zwei h\u00e4ufig anzutreffende Lastverteilungsschemata \u2013 horizontale und vertikale Skalierung. Im ersten Fall<\/a><\/noindex> erlauben Sie es den Diensten, parallel zu arbeiten, wodurch die Last zwischen ihnen verteilt wird. Im zweiten<\/a><\/noindex> Sie bestellen leistungsst\u00e4rkere Server oder optimieren den Code.<\/p>\n

<\/p>\n

Als Beispiel nehme ich einen abstrakten Cloud-Speicher, also eine Art von OwnCloud, OneDrive usw.<\/p>\n

<\/p>\n

Das Standarddiagramm einer solchen Architektur ist unten dargestellt, zeigt jedoch lediglich die Komplexit\u00e4t des Systems. Wir m\u00fcssen die Dienste verstehen und synchronisieren. Was passiert, wenn ein Nutzer von seinem Tablet eine Datei speichert und sie dann auf seinem Smartphone ansehen m\u00f6chte?<\/p>\n

<\/p>\n

\"Praktische
\nDer Unterschied zwischen den Ans\u00e4tzen: Beim vertikalen Scaling sind wir bereit, die Leistung der Knoten zu erh\u00f6hen, w\u00e4hrend wir beim horizontalen Scaling neue Knoten hinzuf\u00fcgen, um die Last zu verteilen.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> Dies ist ein ziemlich wichtiges Muster, da es verschiedenen Clients nicht nur erm\u00f6glicht, sich mit unterschiedlichen Diensten zu verbinden, sondern auch identische Ereignisstr\u00f6me zu erhalten. Die Vorteile sind f\u00fcr einfache Anwendungen nicht sofort ersichtlich, jedoch sind sie entscheidend (und einfach) f\u00fcr stark belastete Dienste. Die Grundidee ist: Eingehende und ausgehende Datenstr\u00f6me sollten sich nicht \u00fcberschneiden. Das hei\u00dft, Sie k\u00f6nnen eine Anfrage senden und nicht auf eine Antwort warten; stattdessen senden Sie eine Anfrage an Dienst A, erhalten jedoch die Antwort von Dienst B.<\/p>\n

<\/p>\n

Der erste Vorteil dieses Ansatzes ist die M\u00f6glichkeit, die Verbindung (im weitesten Sinne des Wortes) w\u00e4hrend einer langen Anfrage zu unterbrechen. Nehmen wir als Beispiel eine mehr oder weniger standardm\u00e4\u00dfige Abfolge:<\/p>\n

<\/p>\n

    \n
  1. Der Kunde hat eine Anfrage an den Server gesendet.<\/li>\n
  2. Der Server hat die langwierige Verarbeitung gestartet.<\/li>\n
  3. Der Server hat dem Kunden mit dem Ergebnis geantwortet.<\/li>\n<\/ol>\n

    <\/p>\n

    Stellen wir uns vor, dass in Punkt 2 die Verbindung unterbrochen wurde (entweder wurde das Netzwerk neu verbunden oder der Benutzer ist auf eine andere Seite gewechselt, wodurch die Verbindung unterbrochen wurde). In diesem Fall w\u00e4re es f\u00fcr den Server schwierig, dem Benutzer zu vermitteln, was genau verarbeitet wurde. Wenn wir CQRS anwenden, wird die Abfolge etwas anders aussehen:<\/p>\n

    <\/p>\n

      \n
    1. Der Kunde hat sich f\u00fcr Updates angemeldet.<\/li>\n
    2. Der Kunde hat eine Anfrage an den Server gesendet.<\/li>\n
    3. Der Server hat mit \u00abAnfrage angenommen\u00bb geantwortet.<\/li>\n
    4. Der Server hat das Ergebnis \u00fcber den Kanal aus Punkt \u00ab1\u00bb \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 Request-Response-Ansatz hier. Doch wie man sieht, f\u00fchrt eine Unterbrechung der Verbindung w\u00e4hrend der Anfrageverarbeitung nicht zu einem Fehler. Tats\u00e4chlich kann, wenn der Benutzer mit mehreren Ger\u00e4ten (z.B. mit einem Mobiltelefon und einem Tablet) verbunden ist, sichergestellt werden, dass die Antwort auf beide Ger\u00e4te gesendet wird.<\/p>\n

      <\/p>\n

      Interessanterweise wird der Code zur Verarbeitung eingehender Nachrichten \u00e4hnlich (aber nicht zu 100 %) f\u00fcr Ereignisse, die durch den Kunden selbst beeinflusst wurden, sowie f\u00fcr andere Ereignisse, einschlie\u00dflich solcher von anderen Kunden.<\/p>\n

      <\/p>\n

      In der Praxis erhalten wir jedoch zus\u00e4tzliche Vorteile, da der einseitige Datenstrom im funktionalen Stil verarbeitet werden kann (unter Verwendung von RX und \u00e4hnlichen Technologien). Das ist ein erheblicher Vorteil, denn so kann die Anwendung vollst\u00e4ndig reaktiv gestaltet werden, wobei ein funktionaler Ansatz zum Einsatz kommt. F\u00fcr umfangreiche Anwendungen kann das die Ressourcen f\u00fcr Entwicklung und Support erheblich einsparen.<\/p>\n

      <\/p>\n

      Kombinieren wir diesen Ansatz mit horizontaler Skalierung, erhalten wir zus\u00e4tzlich die M\u00f6glichkeit, Anfragen an einen Server zu senden und Antworten von einem anderen zu empfangen. So kann der Kunde den f\u00fcr ihn passenden Dienst w\u00e4hlen, w\u00e4hrend das System intern 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 einzelnen Prozess k\u00f6nnen Sie eine Synchronisierung (unter Verwendung der gleichen Mutexes) durchf\u00fchren, innerhalb derer Sie sicherstellen k\u00f6nnen, dass niemand sonst diesen Code ausf\u00fchrt. In einem verteilten System ist dies jedoch gef\u00e4hrlich, da es zus\u00e4tzlichen Overhead verursacht und die wundervolle M\u00f6glichkeit der Skalierung beeintr\u00e4chtigt \u2014 letztlich werden alle Komponenten auf ein einzelnes Element warten.<\/p>\n

      <\/p>\n

      Hieraus ergibt sich eine wichtige Erkenntnis \u2014 ein schnelles verteiltes System kann nicht synchronisiert werden, da dies die Leistung verringern w\u00fcrde. Andererseits ben\u00f6tigen wir oft eine gewisse Konsistenz der Komponenten. Daf\u00fcr kann der Ansatz der eventual consistency<\/a><\/noindex>verwendet werden, der garantiert, dass in Abwesenheit von Daten\u00e4nderungen nach einer bestimmten Zeitspanne seit der letzten Aktualisierung (\u201eletztendlich\u201c) alle Anfragen den letzten aktualisierten Wert zur\u00fcckgeben.<\/p>\n

      <\/p>\n

      Es ist wichtig zu verstehen, dass f\u00fcr klassische Datenbanken oft strikte Konsistenz<\/a><\/noindex>, wo jeder Knoten \u00fcber die gleichen Informationen verf\u00fcgt (dies wird h\u00e4ufig erreicht, wenn eine Transaktion erst dann als abgeschlossen gilt, wenn die Antwort des zweiten Servers vorliegt). Es gibt hier einige Ausnahmen aufgrund der Isolationslevel, aber das grundlegende Konzept bleibt gleich \u2013 Sie k\u00f6nnen in einer vollst\u00e4ndig konsistenten Welt leben.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      \"Praktische<\/p>\n

      <\/p>\n

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

      <\/p>\n