Wahl des architektonischen Stils (Teil 3)

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 letzten Gespräch haben wir verschiedene Arten von Monolithen und die Verwendung von Komponenten für deren Aufbau diskutiert, sowohl von Montage- als auch von Bereitstellungskomponenten. Wir haben uns mit der serviceorientierten Architektur vertraut gemacht.

Jetzt werden wir endlich die Hauptmerkmale der Mikroservice-Architektur definieren.

Architekturanalyse

Es ist wichtig zu verstehen, dass, basierend auf den Informationen aus vorherigen Artikeln, jeder Dienst eine Komponente darstellt, aber nicht jeder Dienst ein Mikroservice ist.

Merkmale der Mikroservice-Architektur

Die Hauptmerkmale der Mikroservice-Architektur sind:

• Organisation nach Geschäftsmöglichkeiten (Organized around Business Capabilities)
• Produkte, nicht Projekte (Products not Projects)
• Intelligente Endpunkte und einfache Kanäle (Smart endpoints and dumb pipes)
• Dezentralisierte Steuerung (Decentralized Governance)
• Dezentralisierte Datenverwaltung (Decentralized Data Management)
• Automatisierung der Infrastruktur (Infrastructure Automation)
• Fehlersicherheit (Design for failure)
• Architektur mit evolutionärem Design (Evolutionary Design)

Der erste Punkt stammt aus der serviceorientierten Architektur, da Mikroservices einen speziellen Fall von Diensten darstellen. Die anderen Punkte verdienen eine eigene Betrachtung.

Organisation nach Geschäftsmöglichkeiten (Organized around Business Capabilities)

Jetzt sollten wir uns an das Conway'sche Gesetz erinnern: Organisationen, die Systeme erstellen, gestalten deren Architektur basierend auf der Struktur der Interaktionen innerhalb dieser Organisationen. Ein Beispiel wäre der Fall der Compiler-Erstellung: Ein Team von sieben Personen entwickelte einen Sieben-Durchlauf-Compiler, während ein Team von fünf einen Fünf-Durchlauf-Compiler entwickelte.

Wenn wir über Monolithen und Mikroservices sprechen, bedeutet dies, dass, wenn die Entwicklung nach funktionalen Abteilungen (Backend, Frontend, Datenbankadministratoren) organisiert ist, ein klassischer Monolith entsteht.

Um Mikroservices zu erhalten, müssen die Teams nach Geschäftsmöglichkeiten organisiert werden (Auftragsteam, Versandteam, Katalogteam). Eine solche Organisation ermöglicht es den Teams, sich auf die Erstellung spezifischer Teile der Anwendung zu konzentrieren.

Produkte, nicht Projekte (Products not Projects)

Der projektorientierte Ansatz, bei dem das Team entwickelte Funktionalitäten an andere Teams bei einer Mikroservice-Architektur übergibt, ist völlig ungeeignet. Das Team sollte das System während des gesamten Lebenszyklus unterstützen. Amazon, einer der Vorreiter bei der Einführung von Mikroservices, erklärte: "Sie erstellen ein Produkt, und Sie bringen es auch zur Ausführung" ("you build, you run it"). Der produktorientierte Ansatz ermöglicht es dem Team, die Bedürfnisse des Unternehmens zu spüren.

Intelligente Endpunkte und einfache Kanäle (Smart endpoints and dumb pipes)

Die SOA-Architektur legte großen Wert auf Kommunikationskanäle, insbesondere auf den Enterprise Service Bus (ESB). Dies führt oft zu einem fehlerhaften Spaghetti-Box, das heißt, die Komplexität des Monolithen verwandelt sich in die Komplexität der Beziehungen zwischen den Services. In der Mikroservice-Architektur werden nur einfache Interaktionsmethoden verwendet.

Dezentralisierte Steuerung (Decentralized Governance)

Wichtige Entscheidungen zu Mikroservices sollten von denjenigen getroffen werden, die tatsächlich Mikroservices entwickeln. Hierbei beziehen sich die Schlüsselentscheidungen auf die Auswahl
von Programmiersprachen, Bereitstellungsmethoden, Verträgen für öffentliche Schnittstellen usw.

Dezentralisierte Datenverwaltung (Decentralized Data Management)

Der Standardansatz, bei dem eine Anwendung auf einer einzigen Datenbank basiert, kann die Besonderheiten jedes einzelnen Services nicht berücksichtigen. MSA setzt auf eine dezentralisierte Datenverwaltung, die bis zur Anwendung unterschiedlicher Technologien reicht.

Automatisierung der Infrastruktur (Infrastructure Automation)

MSA unterstützt kontinuierliche Bereitstellungs- und Lieferprozesse. Dies ist nur durch die Automatisierung der Prozesse möglich. Dabei erscheint die Bereitstellung einer großen Anzahl von Services nicht mehr bedrohlich. Der Bereitstellungsprozess sollte eintönig werden. Ein zweiter Aspekt betrifft die Verwaltung von Services in einer Produktumgebung. Ohne Automatisierung wird das Management von Prozessen, die in verschiedenen Betriebssystemumgebungen ausgeführt werden, unmöglich.

Fehlersicherheit (Design for failure)

Zahlreiche MSA-Services sind Fehlermeldungen ausgesetzt. Die Fehlermanagement in einem verteilten System ist jedoch eine äußerst komplexe Aufgabe. Die Anwendungsarchitektur sollte widerstandsfähig gegenüber solchen Fehlermeldungen sein. Rebecca Parsons hält es für äußerst wichtig, dass wir nicht einmal interne Prozessinteraktionen zwischen Services nutzen, sondern stattdessen auf HTTP zurückgreifen, das in keinster Weise so zuverlässig ist.

Architektur mit evolutionärem Design (Evolutionary Design)

Die Architektur des MSA-Systems sollte sich evolutionär entwickeln. Es ist wünschenswert, die notwendigen Änderungen auf die Grenzen eines einzelnen Dienstes zu beschränken. Es sollte auch der Einfluss auf andere Dienste berücksichtigt werden. Der traditionelle Ansatz besteht darin, zu versuchen, dieses Problem über Versionsmanagement zu lösen, aber MSA sieht vor, Versionsmanagement als
letzte Maßnahme zu verwenden.

Fazit

Nach allem Gesagten lässt sich formulieren, was Mikrodienste sind. Die mikrodienstliche Architektur ist ein Ansatz zur Entwicklung einer einzelnen Anwendung in Form einer Reihe kleiner Dienste, von denen jeder in seinem eigenen Prozess arbeitet und über leichtgewichtige Mechanismen, oft über die HTTP-Ressourcen-API, interagiert. Diese Dienste basieren auf Geschäftsmöglichkeiten und können unabhängig mit einem vollständig
automatisierten Bereitstellungsmechanismus implementiert werden. Es gibt ein minimales Maß an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden.

Teil 2 lesen

Quelle: habr.com