{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Architekturstilwahl (Teil 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr. Derzeit ist bei OTUS eine neue Gruppe f\u00fcr den Kurs er\u00f6ffnet. Software-Architekt<\/a><\/noindex>Im Vorfeld des Kursstarts m\u00f6chte ich mit Ihnen meinen Artikel teilen.<\/i><\/b><\/p>\n

<\/p>\n

Einf\u00fchrung<\/h2>\n

\nDie Wahl des Architektur-Stils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelreihe m\u00f6chte ich die beliebtesten Architektur-Stile f\u00fcr Anwendungen untersuchen und die Frage beantworten, wann welcher Architektur-Stil am vorteilhaftesten ist. W\u00e4hrend der Darstellung werde ich versuchen, eine logische Kette zu entwickeln, die die Evolution der Architektur-Stile von Monolithen zu Mikroservices erkl\u00e4rt.
\n<\/a><\/noindex><\/p>\n

Ein wenig Geschichte<\/h2>\n

\nWenn Sie die Entwickler fragen: \u201eWarum sind Mikrodienste notwendig?\u201c, werden Sie die unterschiedlichsten Antworten erhalten. Sie werden h\u00f6ren, dass Mikrodienste die Skalierbarkeit verbessern, das Verst\u00e4ndnis des Codes erleichtern, die Fehlertoleranz erh\u00f6hen, und manchmal wird sogar gesagt, dass sie den Code \u201ereinigen\u201c k\u00f6nnen. Lassen Sie uns zur Geschichte zur\u00fcckkehren, um zu verstehen, welches Ziel mit dem Auftauchen von Mikrodiensten verfolgt wurde.<\/p>\n

Kurz gesagt, unser heutiges Verst\u00e4ndnis von Mikrodiensten ist wie folgt entstanden: 2011 bemerkte James Lewis, dass viele Unternehmen ein neues Muster namens \u201eMicro-App\u201c entwickelten, das SOA hinsichtlich der Bereitstellungsgeschwindigkeit von Diensten optimierte. Sp\u00e4ter, im Jahr 2012, wurde das Muster beim Architekturgipfel in Mikrodienst umbenannt. Damit war das urspr\u00fcngliche Ziel der Einf\u00fchrung von Mikrodiensten die Verbesserung des ber\u00fchmten time to market<\/b>.<\/p>\n

Der Hype um Mikrodienste begann im Jahr 2015. Laut einigen Studien lie\u00df sich keine Konferenz finden, die ohne einen Vortrag \u00fcber Mikrodienste auskam. Dar\u00fcber hinaus waren einige Konferenzen ausschlie\u00dflich den Mikrodiensten gewidmet. Heute beginnen viele Projekte mit diesem Architekturstil, und wenn ein Projekt gro\u00dfe Mengen an Legacy-Code enth\u00e4lt, erfolgt mit Sicherheit eine aktive Migration zu Mikrodiensten.<\/p>\n

Trotz all dem gibt es bisher nur relativ wenige Entwickler, die den Begriff \"Mikrodienst\" definieren k\u00f6nnen. Aber dar\u00fcber werden wir sp\u00e4ter sprechen...<\/p>\n

Monolith<\/h2>\n

\nDer Architekturstil, der dem Mikrodienst-Stil gegen\u00fcbergestellt wird, ist der Monolith (oder \"alles in einem\"). Es ist wahrscheinlich unn\u00f6tig, zu erkl\u00e4ren, was ein Monolith ist, daher werde ich gleich die Nachteile dieses Architekturstils aufz\u00e4hlen, die die weitere Entwicklung von Architekturstilen angesto\u00dfen haben: Gr\u00f6\u00dfe, Kopplung, Bereitstellung, Skalierbarkeit, Zuverl\u00e4ssigkeit und Tr\u00e4gheit. Unten schlage ich vor, sich mit jedem der Nachteile einzeln vertraut zu machen.<\/p>\n

Gr\u00f6\u00dfe<\/h3>\n

\nEin Monolith ist sehr umfangreich und kommuniziert in der Regel mit einer sehr gro\u00dfen Datenbank. Die Anwendung wird so umfangreich, dass sie prinzipiell von einem einzelnen Entwickler kaum zu verstehen ist. Nur diejenigen, die viel Zeit mit diesem Code verbracht haben, k\u00f6nnen gut mit einem Monolithen arbeiten, w\u00e4hrend Neulinge viel Zeit damit verbringen werden, den Monolithen zu verstehen, ohne dass sicher ist, ob sie es schaffen. Normalerweise gibt es beim Arbeiten mit einem Monolithen immer einen \u201equasi Senior\u201c, der den Monolithen mehr oder weniger gut kennt und Neulinge \u00fcber ein bis eineinhalb Jahre hinweg korrigiert. Es ist nat\u00fcrlich, dass dieser quasi Senior ein einzelner kritischer Punkt ist, und sein Weggang kann zum Untergang des Monolithen f\u00fchren. <\/p>\n

Kopplung<\/h3>\n

\nEin Monolith stellt einen \u201egro\u00dfen Klumpen Schlamm\u201c (big ball of mud) dar, \u00c4nderungen in einem Bereich k\u00f6nnen unvorhersehbare Konsequenzen haben. Wenn man an einer Stelle \u00c4nderungen vornimmt, kann man an einer anderen Stelle den Monolithen besch\u00e4digen (das typische \u201ehabe mir das Ohr gekratzt, und *@ ist abgebrochen\u201c). Dies liegt daran, dass die Komponenten im Monolithen sehr komplexe und vor allem undurchsichtige Beziehungen zueinander haben.<\/p>\n

Deployment<\/h3>\n

\nDas Deployment eines Monolithen ist aufgrund der komplexen Wechselwirkungen zwischen seinen Komponenten ein langwieriger Prozess mit einem bestimmten Ritus. Dieser Ritus ist oft nicht endg\u00fcltig standardisiert und wird \"von Mund zu Mund\" weitergegeben. <\/p>\n

Skalierbarkeit<\/h3>\n

\nDie Module des Monolithen k\u00f6nnen konfliktierende Ressourcenbed\u00fcrfnisse haben, was es notwendig macht, einen Kompromiss in Bezug auf die Hardware zu finden. Stellen Sie sich vor, Ihr Monolith besteht aus den Services A und B. Service A ist anspruchsvoll in Bezug auf die Festplattengr\u00f6\u00dfe, w\u00e4hrend Service B mehr RAM ben\u00f6tigt. In diesem Fall muss entweder der Server, auf dem der Monolith installiert wird, die Anforderungen beider Services erf\u00fcllen, oder man muss manuell einen der Services deaktivieren.<\/p>\n

Ein weiteres Beispiel (klassischer): Service A ist viel beliebter als Service B, daher m\u00f6chten Sie 100 Exemplare von Service A und nur 10 von Service B bereitstellen. Wieder gibt es zwei Optionen: entweder installieren wir 100 vollwertige Monolithen oder m\u00fcssen bei einigen von ihnen manuell die Services B deaktivieren. <\/p>\n

Zuverl\u00e4ssigkeit<\/h3>\n

\nDa alle Dienste zusammengefasst sind, fallen alle Dienste gleichzeitig aus, wenn das Monolith fehlschl\u00e4gt. Tats\u00e4chlich ist das vielleicht nicht so schlimm, denn es wird zumindest keine Teilausf\u00e4lle in einem verteilten System geben. Andererseits k\u00f6nnten Sie jedoch aufgrund eines Fehlers in einer Funktionalit\u00e4t, die nur 0,001 % der Nutzer verwenden, alle Nutzer Ihres Systems verlieren. <\/p>\n

Tr\u00e4gheit<\/h3>\n

\n\u0412\u0432\u0438\u0434\u0443 \u0440\u0430\u0437\u043c\u0435\u0440\u0430 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u0442\u044f\u0436\u0435\u043b\u043e \u043f\u0435\u0440\u0435\u0439\u0442\u0438 \u043d\u0430 \u043d\u043e\u0432\u044b\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041a\u0430\u043a \u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u0435, \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0437\u0430\u0434\u0430\u0447\u0435\u0439 \u0432\u044b\u0440\u0438\u0441\u043e\u0432\u044b\u0432\u0430\u0435\u0442 \u0443\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0442\u043e\u0433\u043e \u0441\u0430\u043c\u043e\u0433\u043e \u0443\u0441\u043b\u043e\u0432\u043d\u043e\u0433\u043e senior’\u0430. \u0412\u044b\u0431\u0440\u0430\u043d\u043d\u044b\u0439 \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0441\u0442\u0435\u043a \u043c\u043e\u0436\u0435\u0442 \u0441\u0442\u0430\u0442\u044c \u0431\u043b\u043e\u043a\u043e\u043c, \u043f\u0440\u0435\u043f\u044f\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u043c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430. <\/p>\n

Fazit<\/h2>\n

\nBeim n\u00e4chsten Mal werden wir dar\u00fcber sprechen, wie Menschen versucht haben, die genannten Probleme zu l\u00f6sen, indem sie zu Komponenten und SOA \u00fcbergegangen sind.<\/p>\n

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

\n

Weiterlesen:<\/h4>\n

<\/p>\n