Wahl des architektonischen Stils (Teil 2)

Hallo, Habr. Heute setze ich die Serie von Beiträgen fort, die ich speziell zum Start des neuen Kurses geschrieben habe. „Software-Architekt“.

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.

Im letztes Mal Wir haben uns mit dem Monolithen beschäftigt und festgestellt, dass der Monolith eine Reihe von Problemen hat: Größe, Kohärenz, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Trägheit.

Dieses Mal möchte ich über die Möglichkeiten sprechen, ein System in Form eines Satzes von Modulen/Bibliotheken (komponentenorientierte Architektur) oder Diensten (serviceorientierte Architektur) zu organisieren.

Komponentenorientierte Architektur

Die komponentenorientierte Architektur sieht vor, dass das System aus einer Reihe von Komponenten besteht, die sowohl in aktuellen als auch in zukünftigen Projekten verwendet werden können. Bei der Aufteilung des Systems in Komponenten werden folgende Aspekte berücksichtigt: die Eignung zur Wiederverwendbarkeit, die Austauschbarkeit, die Unabhängigkeit vom Kontext, die Erweiterbarkeit, die Kapselung und die Unabhängigkeit.

Bei sachgemäßem Einsatz von Komponenten wird das Problem des „großen Klumpens Schmutz“ (große Größe + hohe Kohärenz) gelöst, und die Komponenten selbst können sowohl als Bausätze (Module, Bibliotheken) als auch als Bereitstellungseinheiten (Dienste) auftreten. Bereitstellungseinheiten spiegeln nicht immer den ausgeführten Prozess wider: Zum Beispiel werden eine Webanwendung und eine Datenbank gemeinsam bereitgestellt.

Am häufigsten werden Monolithen in Form einer Vielzahl von Modulen entwickelt. Dieser Ansatz gewährleistet die Unabhängigkeit der Entwicklung, jedoch bleiben die Probleme der unabhängigen Skalierung und Bereitstellung, der Fehlertoleranz und der Unabhängigkeit vom gemeinsamen Technologiestack bestehen. Aus diesem Grund ist ein Modul eine teilweise unabhängige Komponente.

Das Hauptproblem eines solchen Monolithen ist, dass die Modultrennung rein logisch ist und leicht von Entwicklern verletzt werden kann. Es kann ein Core-Modul entstehen, das sich allmählich in einen Schrottplatz verwandelt, die Abhängigkeitsgraphen zwischen den Modulen können wachsen und so weiter. Um solche Probleme zu vermeiden, muss die Entwicklung von einem sehr erfahrenen Team geleitet oder unter der Leitung eines "Architekten" stehen, der sich ganztägig mit Code-Reviews beschäftigt und Entwicklern, die die logische Struktur verletzen, auf die Finger klopft.

Ein "idealer" Monolith besteht aus einer Reihe logisch getrennter Module, von denen jedes in seine eigene Datenbank schaut.

Serviceorientierte Architektur

Wenn dennoch eine Organisation des Systems in Form einer Reihe von Services vorgesehen ist, spricht man von serviceorientierter Architektur. Ihre Prinzipien umfassen: Interoperabilität von benutzerorientierten Anwendungen, mehrfache Nutzung von Business-Services, Unabhängigkeit von Technologie-Stacks und Autonomie (unabhängige Evolution, Skalierbarkeit und Bereitstellbarkeit).

Serviceorientierte Architektur (SOA = service-oriented architecture) löst alle genannten Probleme des Monolithen: Bei Änderungen ist nur ein Service betroffen, während eine klar definierte API eine gute Kapselung der Komponenten unterstützt.

Aber es ist nicht alles so reibungslos: SOA bringt neue Probleme mit sich. Remote-Aufrufe sind teurer als lokale, und die Umverteilung von Aufgaben zwischen den Komponenten ist wesentlich kostspieliger geworden.

Übrigens ist die Möglichkeit eines unabhängigen Deployments eine sehr wichtige Eigenschaft des Services. Wenn Services gemeinsam oder gar in einer bestimmten Reihenfolge bereitgestellt werden müssen, kann das System nicht als serviceorientiert angesehen werden. In diesem Fall spricht man von einem verteilten Monolithen (dies wird nicht nur aus der Sicht von SOA als Antipattern angesehen, sondern auch aus der Perspektive der Mikroservice-Architektur).

Serviceorientierte Architektur wird gut von der Architekturgemeinschaft und Anbietern unterstützt. Daraus ergibt sich eine Vielzahl von Kursen und Zertifizierungen sowie gut ausgearbeiteten Mustern. Zu letzterem gehört beispielsweise der nicht unbekannte Enterprise Service Bus (ESB). Dabei ist der ESB ein Erbe von Anbietern und muss nicht zwingend in SOA verwendet werden.

Der Höhepunkt der Beliebtheit von serviceorientierter Architektur lag etwa im Jahr 2008, danach begann sie zu sinken, wobei der Rückgang mit dem Aufkommen von Microservices (~2015) deutlich ausgeprägter wurde.

Fazit

Nachdem wir die Möglichkeiten zur Organisation von Informationssystemen in Form von Services und Modulen besprochen haben, schlage ich vor, endlich zu den Prinzipien der Microservices-Architektur überzugehen und in der nächsten Teil besonders auf die Unterschiede zwischen der Microservices-Architektur und der serviceorientierten Architektur einzugehen.

Quelle: habr.com