{"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":"Wahl des architektonischen Stils (Teil 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr. Momentan ist die Anmeldung f\u00fcr einen neuen Kurs bei OTUS offen. \u201eSoftware-Architekt\u201c<\/a><\/noindex>Vor dem Start des Kurses m\u00f6chte ich mit Ihnen meinen eigenen Artikel teilen.<\/i><\/b><\/p>\n

<\/p>\n

Einf\u00fchrung<\/h2>\n

\nDie Wahl des Architekturstils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelreihe m\u00f6chte ich die beliebtesten Architekturstile f\u00fcr die Entwicklung von Anwendungen untersuchen und die Frage beantworten, wann welcher Architekturstil am bevorzugt wird. Im Laufe der Erl\u00e4uterungen werde ich versuchen, eine logische Kette zu ziehen, die die Entwicklung der Architekturstile von Monolithen zu Microservices 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 Codeverst\u00e4ndnis erleichtern, die Ausfallsicherheit erh\u00f6hen und manchmal auch, dass sie \u201eden Code bereinigen\u201c. Lassen Sie uns einen R\u00fcckblick auf die Geschichte werfen, um zu verstehen, welches Ziel mit der Einf\u00fchrung von Mikrodiensten verfolgt wurde.<\/p>\n

Kurz gesagt, in unserem aktuellen Verst\u00e4ndnis entstanden Mikrodienste folgenderma\u00dfen: 2011 beobachtete James Lewis bei der Analyse der Arbeiten verschiedener Unternehmen das Auftauchen eines neuen Musters \u201emicro-app\u201c, welches SOA hinsichtlich der Beschleunigung der Bereitstellung von Diensten optimierte. Einige Zeit sp\u00e4ter, im Jahr 2012, wurde das Muster auf einem Architektur-Gipfel in Mikrodienst umbenannt. Damit war das urspr\u00fcngliche Ziel der Einf\u00fchrung von Mikrodiensten die Verbesserung des ber\u00fcchtigten time to market<\/b>.<\/p>\n

Auf der \u201eHype-Welle\u201c waren Mikrodienste im Jahr 2015. Laut einigen Studien fand auf keiner Konferenz ein Vortrag \u00fcber Mikrodienste statt. Dar\u00fcber hinaus waren einige Konferenzen ausschlie\u00dflich Mikrodiensten gewidmet. Heute beginnen viele Projekte mit der Anwendung dieses architektonischen Stils, und wenn ein Projekt tonnenweise Legacy-Code enth\u00e4lt, wird definitiv aktiv an einer Migration zu Mikrodiensten gearbeitet.<\/p>\n

Trotz alledem sind noch immer relativ wenige Entwickler in der Lage, das Konzept \u201eMikrodienst\u201c zu definieren. Aber dar\u00fcber werden wir sp\u00e4ter sprechen...<\/p>\n

Monolith<\/h2>\n

\nDer architektonische Stil, der dem Mikrodienst gegen\u00fcbersteht, ist der Monolith (oder \u201ealles in einem\u201c). Es macht wahrscheinlich keinen Sinn, zu erkl\u00e4ren, was ein Monolith ist, deshalb werde ich sofort die Nachteile dieses architektonischen Stils auflisten, die die weitere Entwicklung architektonischer Stile initiiert haben: Gr\u00f6\u00dfe, Kopplung, Bereitstellung, Skalierbarkeit, Zuverl\u00e4ssigkeit und Tr\u00e4gheit. Im Folgenden lade ich Sie ein, sich mit jedem der Nachteile einzeln vertraut zu machen.<\/p>\n

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

\nDer Monolith ist sehr gro\u00df. Er kommuniziert normalerweise mit einer sehr gro\u00dfen Datenbank. Die Anwendung wird so gro\u00df, dass sie von einem einzelnen Entwickler im Prinzip nicht mehr verstanden werden kann. Nur diejenigen, die viel Zeit mit diesem Code verbracht haben, k\u00f6nnen gut mit dem Monolithen arbeiten, w\u00e4hrend Neueinsteiger viel Zeit mit dem Versuch verbringen, den Monolithen zu verstehen, ohne sicher zu sein, dass sie es letztendlich schaffen. In der Regel gibt es beim Arbeiten mit dem Monolithen immer einen gewissen \"bedingten\" Senior, der den Monolithen mehr oder weniger gut kennt und andere neue Entwickler im Laufe eines Jahres bis eineinhalb Jahre in Schach h\u00e4lt. Nat\u00fcrlich ist ein solcher bedingter Senior ein einzelner Ausfallpunkt, und sein Weggang kann den Monolithen zum Scheitern bringen. <\/p>\n

Kopplung<\/h3>\n

\nDer Monolith stellt eine \"gro\u00dfe Schlammschicht\" (big ball of mud) dar, deren \u00c4nderungen zu unvorhersehbaren Folgen f\u00fchren k\u00f6nnen. Wenn man an einem Ort \u00c4nderungen vornimmt, kann der Monolith an einem anderen besch\u00e4digt werden (das bekannte \"ich habe das Ohr gekratzt, und das Ganze ist abgerissen\"). Dies liegt daran, dass die Komponenten im Monolithen sehr komplexe und vor allem nicht offenkundige Wechselbeziehungen haben.<\/p>\n

Bereitstellung<\/h3>\n

\nDie Bereitstellung des Monolithen aufgrund der komplexen Wechselbeziehungen zwischen seinen Komponenten ist ein langwieriger Prozess mit seinem eigenen Ritus. Dieser Ritus ist normalerweise nicht vollst\u00e4ndig standardisiert und wird \"von Mund zu Mund\" weitergegeben. <\/p>\n

Skalierbarkeit<\/h3>\n

\nDie Module des Monolithen k\u00f6nnen widerspr\u00fcchliche Anforderungen an Ressourcen haben, weshalb es notwendig ist, einen Kompromiss aus der Perspektive der Hardware zu finden. Stellen Sie sich vor, Ihr Monolith besteht aus den Diensten A und B. Dienst A hat hohe Anforderungen an die Festplattengr\u00f6\u00dfe, w\u00e4hrend Dienst B hohe Anforderungen an den Arbeitsspeicher stellt. In diesem Fall muss entweder der Rechner, auf dem der Monolith installiert wird, die Anforderungen beider Dienste erf\u00fcllen, oder man muss manuell einen der Dienste deaktivieren.<\/p>\n

Ein weiteres Beispiel (klassischer): Dienst A ist viel beliebter als Dienst B, weshalb Sie m\u00f6chten, dass es 100 Dienste A und 10 Dienste B gibt. Wiederum gibt es zwei Varianten: Entweder wir setzen 100 voll funktionsf\u00e4hige Monolithen auf, oder wir m\u00fcssen auf einigen von ihnen manuell die Dienste B deaktivieren. <\/p>\n

Zuverl\u00e4ssigkeit<\/h3>\n

\nDa alle Dienste zusammengefasst sind, fallen mit dem Monolithen auch alle Dienste gleichzeitig aus. In Wirklichkeit ist das vielleicht gar nicht so schlimm; zumindest werden keine partiellen Ausf\u00e4lle im verteilten System auftreten. Auf der anderen Seite kann jedoch ein Fehler in der Funktionalit\u00e4t, die 0,001 % der Benutzer nutzen, dazu f\u00fchren, dass Sie alle Benutzer Ihres Systems verlieren. <\/p>\n

Starrheit<\/h3>\n

\nAufgrund der Gr\u00f6\u00dfe des Monolithen ist es schwierig, auf neue Technologien umzusteigen. Folglich wird die Erhaltung des besagten \u201eSenior\u201c-Entwicklers zu einer eigenen Herausforderung. Der zu Beginn des Projekts gew\u00e4hlte Technologiestack kann sich als Blockade erweisen, die die Produktentwicklung behindert. <\/p>\n

Fazit<\/h2>\n

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

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

\n

Weiterlesen:<\/h4>\n

<\/p>\n