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 über die verschiedenen Arten von Monolithen gesprochen und darüber, wie Komponenten zum Erstellen verwendet werden, sowohl Baugruppenkomponenten als auch Bereitstellungskomponenten. Wir haben uns mit serviceorientierter Architektur befasst.
Nun werden wir endlich die Hauptmerkmale einer Microservice-Architektur definieren.
Beziehung von Architekturen
Es versteht sich, dass basierend auf den Daten in den vorherigen Definitionen jeder Dienst eine Komponente ist, aber nicht jeder Dienst ein Mikrodienst.
Eigenschaften einer Microservice-Architektur
Die Hauptmerkmale einer Microservice-Architektur sind:
- Organisiert um Geschäftsfähigkeiten
- Produkte nicht Projekte
- Intelligente Endpunkte und dumme Rohre
- Dezentrale Governance
- Dezentrales Datenmanagement
- Automatisierung der Infrastruktur
- Design für Fehler
- Evolutionäres Design
Der erste Punkt stammt aus der serviceorientierten Architektur, da Microservices ein Sonderfall von Services sind. Andere Punkte verdienen eine gesonderte Prüfung.
Organisiert um Geschäftsfähigkeiten
Jetzt müssen wir uns an Conways Gesetz erinnern: Organisationen, die Systeme erstellen, organisieren ihre Architektur und kopieren die Struktur der Interaktion innerhalb dieser Organisationen. Betrachten Sie als Beispiel den Fall des Erstellens eines Compilers: Ein Team von sieben Personen entwickelte einen Compiler mit sieben Durchläufen, und ein Team von fünf Personen entwickelte einen Compiler mit fünf Durchgängen.
Wenn es sich um Monolithen und Microservices handelt und die Entwicklung von funktionalen Abteilungen (Backend, Frontend, Datenbankadministratoren) organisiert wird, erhalten wir einen klassischen Monolithen.
Um Microservices zu erhalten, müssen die Teams nach Geschäftsmöglichkeiten (Bestellung, Versand, Katalogteam) organisiert sein. Diese Organisation ermöglicht es den Teams, sich auf die Erstellung bestimmter Teile der Anwendung zu konzentrieren.
Produkte nicht Projekte
Ein Projektansatz, bei dem das Team die entwickelte Funktionalität bei einer Microservice-Architektur auf andere Teams überträgt, ist völlig ungeeignet. Das Team muss das System während seines gesamten Lebenszyklus unterstützen. Amazon, eines der Flaggschiffe der Einführung von Microservices, erklärte: „Sie bauen, Sie führen es aus“. Der Produktansatz ermöglicht es dem Team, die Bedürfnisse des Unternehmens zu spüren.
Intelligente Endpunkte und dumme Rohre
Die SOA-Architektur hat den Kommunikationskanälen, insbesondere dem Enterprise Service Bus (Enterprise Service Bus), große Aufmerksamkeit gewidmet. Was häufig zur fehlerhaften Spaghetti-Box führt, dh die Komplexität des Monolithen wird zur Komplexität der Verbindungen zwischen Diensten. Die Mikrodienstarchitektur verwendet nur einfache Kommunikationsmethoden.
Dezentrale Governance
Die wichtigsten Entscheidungen für Microservices müssen von den Menschen getroffen werden, die tatsächlich Microservices entwickeln. Hier bedeuten wichtige Entscheidungen die Auswahl
von Programmiersprachen, Bereitstellungsmethoden, Verträgen für öffentliche Schnittstellen usw.
Dezentrales Datenmanagement
Der Standardansatz, bei dem eine Anwendung auf einer einzelnen Datenbank basiert, kann die Besonderheiten jedes einzelnen Dienstes nicht berücksichtigen. MSA übernimmt ein dezentrales Datenmanagement bis hin zum Einsatz verschiedener Technologien.
Automatisierung der Infrastruktur
MSA unterstützt kontinuierliche Bereitstellungs- und Bereitstellungsprozesse. Dies kann nur durch Automatisierung von Prozessen erfolgen. Gleichzeitig sieht die Bereitstellung einer großen Anzahl von Diensten nicht mehr beängstigend aus. Der Bereitstellungsprozess sollte langweilig werden. Der zweite Aspekt betrifft das Service-Management in der Produktumgebung. Ohne Automatisierung wird die Verwaltung von Prozessen, die in verschiedenen Betriebsumgebungen ausgeführt werden, unmöglich.
Design für Fehler
Zahlreiche MSA-Dienste sind fehleranfällig. Gleichzeitig ist die Fehlerbehandlung in einem verteilten System keine triviale Aufgabe. Die Anwendungsarchitektur muss gegenüber solchen Fehlern stabil sein. Rebecca Parsons hält es für sehr wichtig, dass wir nicht einmal mehr die In-Process-Kommunikation zwischen Diensten verwenden, sondern HTTP für die Kommunikation, die bei weitem nicht so zuverlässig ist.
Evolutionäres Design
Die Architektur des MSA-Systems muss sich weiterentwickeln. Es ist wünschenswert, die erforderlichen Änderungen auf die Grenzen eines Dienstes zu beschränken. Es ist auch notwendig, die Auswirkungen auf andere Dienste zu berücksichtigen. Der traditionelle Ansatz besteht darin, dieses Problem mit der Versionskontrolle zu beheben. MSA schlägt jedoch vor, die Versionskontrolle als
letzten Ausweg zu verwenden.
Fazit
Nach alledem können wir formulieren, was Microservices sind. Die Microservice-Architektur ist ein Ansatz zur Entwicklung einer einzelnen Anwendung als Sammlung kleiner Services, von denen jeder in einem eigenen Prozess ausgeführt wird und über einfache Mechanismen, häufig eine HTTP-Ressourcen-API, interagiert. Diese Services basieren auf Geschäftsfunktionen und können mithilfe einer
vollautomatisierten Deployment-Engine unabhängig bereitgestellt werden . Es gibt ein Mindestmaß an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen geschrieben werden und unterschiedliche Speichertechnologien verwenden können. Lesen Sie Teil 2
