Einführung
Die Wahl eines Architekturstils ist eine der grundlegenden technischen Lösungen beim Aufbau eines Informationssystems. In dieser Artikelserie schlage ich vor, die beliebtesten Architekturstile für Gebäudeanwendungen zu analysieren und die Frage zu beantworten, wann der Architekturstil am meisten bevorzugt wird. Dabei werde ich versuchen, eine logische Kette zu zeichnen, die die Entwicklung von Architekturstilen von Monolithen bis zu Mikrodiensten erklärt.
Das letzte Mal haben wir uns mit dem Monolithen befasst und sind zu dem Schluss gekommen, dass der Monolith eine Reihe von Problemen aufweist: Größe, Konnektivität, Bereitstellung, Skalierbarkeit, Zuverlässigkeit und Konservativismus.
Dieses Mal möchte ich über die Möglichkeiten sprechen, das System in Form einer Reihe von Modulen / Bibliotheken (komponentenorientierte Architektur) oder Diensten (serviceorientierte Architektur) zu organisieren.
Komponentenorientierte Architektur
Komponentenbasierte Architektur impliziert die Implementierung des Systems als eine Reihe von Komponenten, die sowohl in aktuellen als auch in zukünftigen Projekten verwendet werden können. Bei der Aufteilung eines Systems in Komponenten werden folgende Faktoren berücksichtigt: Eignung zur Wiederverwendung, Austauschbarkeit, Kontextunabhängigkeit, Erweiterbarkeit, Kapselung und Unabhängigkeit.
Bei ordnungsgemäßer Verwendung der Komponenten wird das Problem eines „großen Schmutzballs“ (große Größe + hohe Konnektivität) gelöst, und die Komponenten selbst können sowohl Baugruppeneinheiten (Module, Bibliotheken) als auch Bereitstellungseinheiten (Dienste) sein. Bereitstellungseinheiten werden nicht immer einem laufenden Prozess zugeordnet: Beispielsweise werden eine Webanwendung und eine Datenbank zusammen bereitgestellt.
Meistens werden Monolithen als eine Reihe von Modulen entworfen. Dieser Ansatz führt zur Gewährleistung der Unabhängigkeit der Entwicklung, gleichzeitig bleiben jedoch die Probleme der unabhängigen Skalierung und Bereitstellung, der Fehlertoleranz und der Unabhängigkeit vom allgemeinen technologischen Stapel bestehen. Aus diesem Grund ist das Modul eine teilweise unabhängige Komponente.
Das größte Problem bei einem solchen Monolithen ist, dass die Unterteilung in Module rein logisch ist und von Entwicklern leicht aufgebrochen werden kann. Es kann ein Kernmodul angezeigt werden, das sich allmählich in einen Papierkorb verwandelt, ein 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 Anleitung eines "Architekten" durchgeführt werden, der sich ständig mit der Codeüberprüfung befasst und die Hände von Entwicklern schlägt, die gegen die logische Struktur verstoßen.
Ein "idealer" Monolith ist eine Reihe von logisch getrennten Modulen, von denen jedes in eine eigene Datenbank schaut.
Serviceorientierte Architektur
Wenn es das System dennoch in Form einer Reihe von Diensten organisieren soll, dann handelt es sich um eine serviceorientierte Architektur. Seine Prinzipien sind: Interoperabilität benutzerorientierter Anwendungen, Wiederverwendbarkeit von Geschäftsdiensten, Unabhängigkeit von einer Reihe von Technologien und Autonomie (unabhängige Entwicklung, Skalierbarkeit und Bereitstellbarkeit).
Die serviceorientierte Architektur (SOA) löst alle beschriebenen Probleme des Monolithen: Eine Änderung betrifft nur einen Service, und eine genau definierte API unterstützt eine gute Komponentenkapselung.
Aber nicht alles ist so reibungslos: SOA bringt neue Probleme mit sich. Ferngespräche sind teurer als Ortsgespräche, und die Umverteilung der Verantwortlichkeiten zwischen den Komponenten ist erheblich teurer geworden.
Übrigens ist die Fähigkeit zur unabhängigen Bereitstellung ein sehr wichtiges Merkmal des Dienstes. Wenn Dienste zusammen oder noch mehr in einer bestimmten Reihenfolge bereitgestellt werden sollen, kann das System nicht als serviceorientiert betrachtet werden. In diesem Fall sprechen sie von einem verteilten Monolithen (er wird nicht nur aus Sicht der SOA, sondern auch einer Mikroservice-Architektur als Anti-Pattern angesehen).
Serviceorientierte Architektur wird von der Architekturgemeinschaft und den Anbietern gut unterstützt. Daher gibt es viele Kurse und Zertifizierungen, gut entwickelte Muster. Letzteres umfasst beispielsweise den nicht unbekannten Enterprise Service Bus (ESB = Enterprise Service Bus). Gleichzeitig ist ESB das Gepäck von Anbietern, es muss nicht in SOA verwendet werden.
Die serviceorientierte Architektur erreichte um 2008 ihren Höhepunkt in der Popularität, danach begann sie abzunehmen, was nach dem Aufkommen von Microservices (~ 2015) viel schärfer wurde.
Fazit
Nachdem wir die Möglichkeiten der Organisation von Informationssystemen in Form von Diensten und Modulen erörtert haben, schlage ich vor, im nächsten Teil endlich auf die Prinzipien einer Microservice-Architektur einzugehen und dem Unterschied zwischen einer Microservice-Architektur und einer serviceorientierten Architektur besondere Aufmerksamkeit zu widmen.
