{"id":30785,"date":"2019-10-31T21:37:25","date_gmt":"2019-10-31T18:37:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie\/"},"modified":"2019-10-31T21:37:25","modified_gmt":"2019-10-31T18:37:25","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","title":{"rendered":"Bausteine verteilter Anwendungen. Null-N\u00e4herung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Bausteine<\/p>\n

<\/p>\n

Die Welt steht nicht still. Der Fortschritt schafft neue technologische Herausforderungen. Mit den sich \u00e4ndernden Anforderungen muss sich auch die Architektur der Informationssysteme weiterentwickeln. Heute werden wir \u00fcber ereignisorientierte Architektur, Konkurrenz, Parallelit\u00e4t, Asynchronit\u00e4t und dar\u00fcber sprechen, wie man in Erlang friedlich damit leben kann.<\/p>\n

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

Einf\u00fchrung<\/h2>\n

<\/p>\n

Je nach Gr\u00f6\u00dfe des geplanten Systems und den Anforderungen daran w\u00e4hlen wir Entwickler die Methode zur Informations\u00fcbertragung im System aus. In den meisten F\u00e4llen kann ein Broker-basierendes Schema, beispielsweise auf RabbitMQ oder Kafka, eine praktikable L\u00f6sung zur Organisation der Interaktion der Dienste sein. Aber manchmal sind der Ereignisfluss, die SLA und der Kontrollgrad \u00fcber das System so beschaffen, dass uns bestehende Messaging-Systeme nicht ausreichen. Nat\u00fcrlich kann man das System etwas komplexer gestalten, indem man die Verantwortung f\u00fcr die Transportschicht und die Clusterbildung \u00fcbernimmt, zum Beispiel mit ZeroMQ oder nanomsg. Aber wenn das System \u00fcber ausreichende Bandbreite und Funktionen des standardm\u00e4\u00dfigen Erlang-Clusters verf\u00fcgt, erfordert die Einf\u00fcgung einer zus\u00e4tzlichen Entit\u00e4t eine detaillierte Untersuchung und wirtschaftliche Rechtfertigung.<\/p>\n

<\/p>\n

Das Thema reaktive verteilte Anwendungen ist recht umfangreich. Um im Format eines Artikels zu bleiben, wird sich die heutige Diskussion nur auf homogene Umgebungen konzentrieren, die auf Erlang\/Elixir basieren. Das \u00d6kosystem Erlang\/OTP erm\u00f6glicht die Implementierung einer reaktiven Architektur mit minimalem Aufwand. Aber in jedem Fall ben\u00f6tigen wir eine Kommunikationsschicht. <\/p>\n

<\/p>\n

Theoretische Grundlagen<\/h2>\n

<\/p>\n

Das Design beginnt mit der Definition von Zielen und Beschr\u00e4nkungen. Das Hauptziel liegt nicht im Bereich der Entwicklung um der Entwicklung willen. Wir ben\u00f6tigen ein sicheres und skalierbares Werkzeug, auf dessen Grundlage moderne Anwendungen unterschiedlichen Niveaus erstellt werden k\u00f6nnen und, was am wichtigsten ist, weiterentwickelt werden k\u00f6nnen: beginnend bei Ein-Server-Anwendungen, die eine kleine Zielgruppe bedienen und sich sp\u00e4ter zu Clustern von bis zu 50-60 Knoten entwickeln k\u00f6nnen, bis hin zu F\u00f6derationen von Clustern. Daher besteht das Hauptziel darin, den Gewinn durch Senkung der Entwicklungskosten und der Eigentumskosten des Endsystems zu maximieren.<\/p>\n

<\/p>\n

Lassen Sie uns vier Hauptanforderungen an das Endsystem hervorheben:<\/p>\n

<\/p>\n