Hallo, Habr. Heute setze ich eine Reihe von Veröffentlichungen fort, die ich speziell für den Beginn eines neuen Kursverlaufs geschrieben habe. .
Einführung
Die Wahl des Architekturstils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelserie schlage ich vor, die beliebtesten Architekturstile für Bauanwendungen zu analysieren und die Frage zu beantworten, wann welcher Architekturstil am besten geeignet ist. Im Prozess der Präsentation werde ich versuchen, eine logische Kette zu zeichnen, die die Entwicklung von Architekturstilen von Monolithen zu Microservices erklärt.
В Wir haben uns mit dem Monolithen beschäftigt und sind zu dem Schluss gekommen, dass der Monolith eine Reihe von Problemen aufweist: Größe, Konnektivität, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Steifigkeit.
Dieses Mal schlage ich vor, über die Möglichkeiten zu sprechen, ein System als eine Reihe von Modulen/Bibliotheken (komponentenorientierte Architektur) oder Dienste (dienstorientierte Architektur) zu organisieren.
Komponentenorientierte Architektur
Bei der komponentenorientierten Architektur geht es darum, ein System als eine Reihe von Komponenten auszuführen, die sowohl in aktuellen als auch in zukünftigen Projekten verwendet werden können. Bei der Zerlegung eines Systems in Komponenten werden folgende Aspekte berücksichtigt: deren Wiederverwendbarkeit, deren Ersetzbarkeit, Kontextunabhängigkeit, Erweiterbarkeit, Kapselung und Unabhängigkeit.
Durch die ordnungsgemäße Verwendung von Komponenten wird das Problem des „großen Schmutzballs“ (große Größe + hohe Kopplung) gelöst, und die Komponenten selbst können sowohl Montageeinheiten (Module, Bibliotheken) als auch Bereitstellungseinheiten (Dienste) sein. Bereitstellungseinheiten werden nicht immer dem laufenden Prozess zugeordnet: Beispielsweise werden eine Webanwendung und eine Datenbank gemeinsam bereitgestellt.
Am häufigsten werden Monolithen als eine Reihe von Modulen entwickelt. Dieser Ansatz führt zu einer unabhängigen Entwicklung, die Probleme der unabhängigen Skalierung und Bereitstellung, der Fehlertoleranz und der Unabhängigkeit vom gesamten Technologie-Stack bleiben jedoch bestehen. Deshalb ist das Modul eine teilweise eigenständige Komponente.
Das größte Problem bei einem solchen Monolithen besteht darin, dass die Aufteilung in Module rein logisch ist und von Entwicklern leicht verletzt werden kann. Möglicherweise erscheint ein Kernmodul, das sich nach und nach in eine Müllkippe verwandelt, das Diagramm der Abhängigkeiten zwischen Modulen kann wachsen und so weiter. Um solche Probleme zu vermeiden, sollte die Entwicklung entweder von einem sehr ausgereiften Team oder unter der Leitung eines „Architekten“ durchgeführt werden, der sich hauptberuflich mit der Codeüberprüfung beschäftigt und Entwicklern die Hände schlägt, die gegen die logische Struktur verstoßen.
Der „ideale“ Monolith besteht aus einer Reihe logisch getrennter Module, von denen jedes in seine eigene Datenbank schaut.
Serviceorientierte Architektur
Wenn das System in Form einer Menge von Diensten organisiert werden soll, dann sprechen wir von einer serviceorientierten Architektur. Seine Prinzipien sind benutzerzentrierte Anwendungsinteroperabilität, Wiederverwendung von Geschäftsdiensten, Unabhängigkeit von Technologie-Stacks und Autonomie (unabhängige Entwicklung, Skalierbarkeit und Bereitstellung).
Eine serviceorientierte Architektur (SOA = serviceorientierte Architektur) löst alle identifizierten Probleme eines Monolithen: Bei einer Änderung ist nur ein Dienst betroffen, und eine wohldefinierte API unterstützt eine gute Kapselung der Komponenten.
Doch nicht alles läuft so reibungslos: SOA schafft neue Probleme. Remote-Anrufe sind teurer als lokale Anrufe und die Neuverteilung der Verantwortlichkeiten zwischen den Komponenten ist deutlich teurer geworden.
Die Möglichkeit des eigenständigen Einsatzes ist übrigens ein sehr wichtiges Merkmal des Dienstes. Wenn Dienste gemeinsam oder darüber hinaus in einer bestimmten Reihenfolge bereitgestellt werden müssen, kann das System nicht als serviceorientiert angesehen werden. In diesem Fall handelt es sich um einen verteilten Monolithen (der nicht nur aus Sicht von SOA, sondern auch aus Sicht der Microservice-Architektur als Anti-Pattern gilt).
Serviceorientierte Architektur wird von der Architektengemeinschaft und den Anbietern gut unterstützt. Dies setzt das Vorhandensein vieler Kurse und Zertifizierungen sowie gut entwickelter Muster voraus. Zu letzterem gehört beispielsweise der bekannte Enterprise Service Bus (ESB = Enterprise Service Bus). Gleichzeitig ist ESB ein Gepäck von Anbietern und muss nicht unbedingt in SOA verwendet werden.
Die Popularität der serviceorientierten Architektur erreichte um 2008 ihren Höhepunkt, danach begann sie zu sinken, was nach dem Aufkommen von Microservices (~2015) noch deutlich dramatischer wurde.
Abschluss
Nachdem wir die Möglichkeiten der Organisation von Informationssystemen in Form von Diensten und Modulen besprochen haben, schlage ich vor, im nächsten Teil abschließend auf die Prinzipien der Microservice-Architektur einzugehen und dem Unterschied zwischen Microservice-Architektur und serviceorientierter Architektur besondere Aufmerksamkeit zu widmen.
Source: habr.com