Wahl des architektonischen Stils (Teil 1)

Hallo, Habr. Momentan ist die Anmeldung für einen neuen Kurs bei OTUS offen. „Software-Architekt“Vor dem Start des Kurses möchte ich mit Ihnen meinen eigenen Artikel teilen.

Einführung

Die Wahl des Architekturstils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelreihe möchte ich die beliebtesten Architekturstile für die Entwicklung von Anwendungen untersuchen und die Frage beantworten, wann welcher Architekturstil am bevorzugt wird. Im Laufe der Erläuterungen werde ich versuchen, eine logische Kette zu ziehen, die die Entwicklung der Architekturstile von Monolithen zu Microservices erklärt.

Ein wenig Geschichte

Wenn Sie die Entwickler fragen: „Warum sind Mikrodienste notwendig?“, werden Sie die unterschiedlichsten Antworten erhalten. Sie werden hören, dass Mikrodienste die Skalierbarkeit verbessern, das Codeverständnis erleichtern, die Ausfallsicherheit erhöhen und manchmal auch, dass sie „den Code bereinigen“. Lassen Sie uns einen Rückblick auf die Geschichte werfen, um zu verstehen, welches Ziel mit der Einführung von Mikrodiensten verfolgt wurde.

Kurz gesagt, in unserem aktuellen Verständnis entstanden Mikrodienste folgendermaßen: 2011 beobachtete James Lewis bei der Analyse der Arbeiten verschiedener Unternehmen das Auftauchen eines neuen Musters „micro-app“, welches SOA hinsichtlich der Beschleunigung der Bereitstellung von Diensten optimierte. Einige Zeit später, im Jahr 2012, wurde das Muster auf einem Architektur-Gipfel in Mikrodienst umbenannt. Damit war das ursprüngliche Ziel der Einführung von Mikrodiensten die Verbesserung des berüchtigten time to market.

Auf der „Hype-Welle“ waren Mikrodienste im Jahr 2015. Laut einigen Studien fand auf keiner Konferenz ein Vortrag über Mikrodienste statt. Darüber hinaus waren einige Konferenzen ausschließlich Mikrodiensten gewidmet. Heute beginnen viele Projekte mit der Anwendung dieses architektonischen Stils, und wenn ein Projekt tonnenweise Legacy-Code enthält, wird definitiv aktiv an einer Migration zu Mikrodiensten gearbeitet.

Trotz alledem sind noch immer relativ wenige Entwickler in der Lage, das Konzept „Mikrodienst“ zu definieren. Aber darüber werden wir später sprechen...

Monolith

Der architektonische Stil, der dem Mikrodienst gegenübersteht, ist der Monolith (oder „alles in einem“). Es macht wahrscheinlich keinen Sinn, zu erklären, was ein Monolith ist, deshalb werde ich sofort die Nachteile dieses architektonischen Stils auflisten, die die weitere Entwicklung architektonischer Stile initiiert haben: Größe, Kopplung, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Trägheit. Im Folgenden lade ich Sie ein, sich mit jedem der Nachteile einzeln vertraut zu machen.

Größe

Der Monolith ist sehr groß. Er kommuniziert normalerweise mit einer sehr großen Datenbank. Die Anwendung wird so groß, dass sie von einem einzelnen Entwickler im Prinzip nicht mehr verstanden werden kann. Nur diejenigen, die viel Zeit mit diesem Code verbracht haben, können gut mit dem Monolithen arbeiten, während 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ält. Natürlich ist ein solcher bedingter Senior ein einzelner Ausfallpunkt, und sein Weggang kann den Monolithen zum Scheitern bringen.

Kopplung

Der Monolith stellt eine "große Schlammschicht" (big ball of mud) dar, deren Änderungen zu unvorhersehbaren Folgen führen können. Wenn man an einem Ort Änderungen vornimmt, kann der Monolith an einem anderen beschädigt 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.

Bereitstellung

Die Bereitstellung des Monolithen aufgrund der komplexen Wechselbeziehungen zwischen seinen Komponenten ist ein langwieriger Prozess mit seinem eigenen Ritus. Dieser Ritus ist normalerweise nicht vollständig standardisiert und wird "von Mund zu Mund" weitergegeben.

Skalierbarkeit

Die Module des Monolithen können widersprüchliche 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öße, während 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üllen, oder man muss manuell einen der Dienste deaktivieren.

Ein weiteres Beispiel (klassischer): Dienst A ist viel beliebter als Dienst B, weshalb Sie möchten, dass es 100 Dienste A und 10 Dienste B gibt. Wiederum gibt es zwei Varianten: Entweder wir setzen 100 voll funktionsfähige Monolithen auf, oder wir müssen auf einigen von ihnen manuell die Dienste B deaktivieren.

Zuverlässigkeit

Da 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älle im verteilten System auftreten. Auf der anderen Seite kann jedoch ein Fehler in der Funktionalität, die 0,001 % der Benutzer nutzen, dazu führen, dass Sie alle Benutzer Ihres Systems verlieren.

Starrheit

Aufgrund der Größe des Monolithen ist es schwierig, auf neue Technologien umzusteigen. Folglich ergibt sich die separate Aufgabe, den besagten hypothetischen Senior-Entwickler zu halten. Der zu Beginn des Projekts gewählte Technologiestack kann sich als Block erweisen, der die Produktentwicklung behindert.

Fazit

Beim nächsten Mal werden wir darüber sprechen, wie die Menschen versucht haben, die benannten Probleme zu lösen, indem sie auf Komponenten und SOA umgestiegen sind.

Weiterlesen:

• Warum SQL Server die Sortierung der Ergebnisse ohne ORDER BY nicht garantiert
• Architektur für Entwickler und Administratoren: Welche Fähigkeiten werden benötigt?

Quelle: habr.com