Hallo, Habr. Heute setze ich die Serie von Veröffentlichungen fort, die ich speziell zum Start des neuen Kurses verfasst habe .
EinfĂŒhrung
Die Wahl des Architektur-Stils ist eine der grundlegenden technischen Entscheidungen beim Aufbau eines Informationssystems. In dieser Artikelreihe möchte ich die beliebtesten Architektur-Stile fĂŒr Anwendungen untersuchen und die Frage beantworten, wann welcher Architektur-Stil am vorteilhaftesten ist. WĂ€hrend der Darstellung werde ich versuchen, eine logische Kette zu entwickeln, die die Evolution der Architektur-Stile von Monolithen zu Mikroservices erklĂ€rt.
In Wir haben uns mit dem Monolithen auseinandergesetzt und festgestellt, dass dieser eine Reihe von Problemen hat: GröĂe, KohĂ€sion, Bereitstellung, Skalierbarkeit, ZuverlĂ€ssigkeit und Festigkeit.
Dieses Mal möchte ich ĂŒber die Möglichkeiten sprechen, ein System als eine Reihe von Modulen/Bibliotheken (komponentengestĂŒtzte Architektur) oder Diensten (dienstorientierte Architektur) zu organisieren.
KomponentengestĂŒtzte Architektur
Die komponentengestĂŒtzte Architektur sieht die AusfĂŒhrung des Systems als eine Sammlung von Komponenten vor, die sowohl in aktuellen als auch in zukĂŒnftigen Projekten verwendet werden können. Bei der Aufteilung des Systems in Komponenten werden die Eignung zur Wiederverwendung, die Austauschbarkeit, die UnabhĂ€ngigkeit vom Kontext, die Erweiterbarkeit, die Kapselung und die UnabhĂ€ngigkeit berĂŒcksichtigt.
Bei sinnvoller Nutzung der Komponenten wird das Problem des "groĂen Schmutzklumpens" (groĂe GröĂe + hohe KohĂ€renz) gelöst. Die Komponenten können sowohl als Baueinheiten (Module, Bibliotheken) als auch als Bereitstellungseinheiten (Dienste) fungieren. Bereitstellungseinheiten spiegeln nicht immer den laufenden Prozess wider: Zum Beispiel werden das Webanwendungs- und Datenbanksystem gemeinsam bereitgestellt.
Monolithen werden am hĂ€ufigsten als eine Sammlung von Modulen entwickelt. Dieser Ansatz fĂŒhrt zu einer UnabhĂ€ngigkeit in der Entwicklung, doch die Probleme der unabhĂ€ngigen Skalierung und Bereitstellung, der Fehlertoleranz und der UnabhĂ€ngigkeit von dem gemeinsamen Technologie-Stack bleiben bestehen. Aus diesem Grund ist ein Modul eine teilweise unabhĂ€ngige Komponente.
Das Hauptproblem eines solchen Monolithen besteht darin, dass die Unterteilung in Module rein logisch ist und leicht von Entwicklern verletzt werden kann. Es kann ein Core-Modul entstehen, das allmÀhlich zu einem Chaos wird, und das AbhÀngigkeitsdiagramm zwischen Modulen kann wachsen und so weiter. Um solche Probleme zu vermeiden, sollte die Entwicklung entweder von einem sehr erfahrenen Team oder unter der Leitung eines "Architekten" erfolgen, der sich in Vollzeit mit Code-Reviews beschÀftigt und den Entwicklern, die die logische Struktur verletzen, einen Riegel vorschiebt.
Ein "idealer" Monolith besteht aus einer Reihe logisch getrennter Module, von denen jedes auf seine eigene Datenbank zugreift.
Serviceorientierte Architektur
Wenn dennoch die Organisation des Systems in Form einer Reihe von Diensten vorgesehen ist, handelt es sich um eine serviceorientierte Architektur. Ihre Prinzipien sind: InteroperabilitÀt von benutzerorientierten Anwendungen, mehrfacher Einsatz von GeschÀftsdiensten, UnabhÀngigkeit von einer Technologiegruppe und Autonomie (unabhÀngige Evolution, Skalierbarkeit und Bereitstellbarkeit).
Die serviceorientierte Architektur (SOA = Service-Oriented Architecture) löst alle genannten Probleme des Monolithen: Bei Ănderungen ist nur ein Dienst betroffen, und eine klar definierte API gewĂ€hrleistet eine gute Kapselung der Komponenten.
Aber nicht alles verlĂ€uft reibungslos: SOA fĂŒhrt zu neuen Problemen. Fernaufrufe sind teurer als lokale, und die Umverteilung der Aufgaben zwischen den Komponenten ist erheblich kostenintensiver geworden.
Ăbrigens ist die Möglichkeit der unabhĂ€ngigen Bereitstellung eine sehr wichtige Eigenschaft des Dienstes. Wenn Dienste gemeinsam oder sogar in einer bestimmten Reihenfolge bereitgestellt werden mĂŒssen, kann das System nicht als serviceorientiert betrachtet werden. In diesem Fall spricht man von einem verteilten Monolithen (was nicht nur aus der Sicht von SOA, sondern auch der Mikroservice-Architektur als Antipattern gilt).
Architektur basierte auf Diensten wird gut von der Architekturgemeinschaft und Anbietern unterstĂŒtzt. Daher gibt es viele Schulungen und Zertifizierungen sowie gut durchdachte Muster. Dazu gehört beispielsweise der nicht unbekannte Unternehmensservicebus (ESB = Enterprise Service Bus). Dabei ist der ESB ein Erbe der Anbieter und muss nicht unbedingt in SOA verwendet werden.
Die BlĂŒtezeit der serviceorientierten Architektur war etwa im Jahr 2008, danach begann ein RĂŒckgang, der sich nach dem Aufkommen der Mikrodienste (~2015) deutlich verstĂ€rkte.
Fazit
Nachdem wir die Möglichkeiten der Organisation von Informationssystemen in Form von Diensten und Modulen besprochen haben, schlage ich vor, endlich zu den Prinzipien der Mikrodienstarchitektur ĂŒberzugehen und besonders auf die Unterschiede zwischen der Mikrodienstarchitektur und der serviceorientierten Architektur im nĂ€chsten Abschnitt einzugehen.
Quelle: habr.com
