Einen Architekturstil wählen (Teil 3)

Hallo, Habr. Heute setze ich eine Reihe von Veröffentlichungen fort, die ich speziell für den Beginn eines neuen Kursverlaufs geschrieben habe. "Softwarearchitekt".

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.

Letztes Mal haben wir über die verschiedenen Arten von Monolithen und die Verwendung von Komponenten zu ihrer Erstellung gesprochen, sowohl Build-Komponenten als auch Bereitstellungskomponenten. Wir verstehen serviceorientierte Architektur.

Nun definieren wir abschließend die Hauptmerkmale einer Microservice-Architektur.

Beziehung von Architekturen

Es ist wichtig zu verstehen, dass basierend auf den Definitionen in den vorherigen Artikeln jeder Dienst eine Komponente ist, aber nicht jeder Dienst ein Mikrodienst.

Merkmale der Microservice-Architektur

Die Hauptmerkmale der Microservice-Architektur sind:

  • Organisiert nach Geschäftsfähigkeiten
  • Produkte, keine Projekte
  • Intelligente Endpunkte und dumme Pipes
  • Dezentrale Governance
  • Dezentrales Datenmanagement
  • Infrastrukturautomatisierung
  • Design für das Scheitern
  • Architektur mit evolutionärer Entwicklung (Evolutionary Design)

Der erste Punkt stammt aus der serviceorientierten Architektur, da Microservices ein Sonderfall von Services sind. Andere Punkte verdienen eine gesonderte Betrachtung.

Organisiert nach Geschäftsfähigkeiten

Nun muss man sich an Conways Gesetz erinnern: Organisationen, die Systeme erstellen, organisieren ihre Architektur und kopieren die Struktur der Interaktion innerhalb dieser Organisationen. Als Beispiel können wir uns an den Fall der Erstellung eines Compilers erinnern: Ein Team von sieben Personen entwickelte einen Compiler mit sieben Durchgängen und ein Team von fünf Personen entwickelte einen Compiler mit fünf Durchgängen.

Wenn wir über Monolithen und Microservices sprechen und die Entwicklung nach Funktionsabteilungen (Backend, Frontend, Datenbankadministratoren) organisiert ist, erhalten wir einen klassischen Monolithen.

Um Microservices zu erhalten, müssen Teams nach Geschäftsfähigkeit organisiert werden (Bestellungen, Lieferungen, Katalogteam). Diese Organisation ermöglicht es den Teams, sich auf die Erstellung bestimmter Teile der Anwendung zu konzentrieren.

Produkte, keine Projekte

Ein Projektansatz, bei dem ein Team die entwickelte Funktionalität auf andere Teams überträgt, ist im Falle einer Microservice-Architektur völlig ungeeignet. Das Team muss das System während seines gesamten Lebenszyklus unterstützen. Amazon, einer der führenden Anbieter von Microservices, sagte: „Sie erstellen, Sie führen es aus.“ Der Produktansatz ermöglicht es dem Team, die Bedürfnisse des Unternehmens zu spüren.

Intelligente Endpunkte und dumme Pipes

Bei der SOA-Architektur wurde großen Wert auf Kommunikationskanäle gelegt, insbesondere auf den Enterprise Service Bus. Dies führt oft zu einer fehlerhaften Spaghetti-Box, das heißt, die Komplexität des Monolithen wird zur Komplexität der Verbindungen zwischen Diensten. Die Microservice-Architektur verwendet nur einfache Kommunikationsmethoden.

Dezentrale Governance

Wichtige Entscheidungen über Microservices sollten von den Leuten getroffen werden, die die Microservices tatsächlich entwickeln. Wichtige Entscheidungen bedeuten hier Entscheidungen
Programmiersprachen, Bereitstellungsmethodik, öffentliche Schnittstellenverträge usw.

Dezentrales Datenmanagement

Der Standardansatz, bei dem die Anwendung auf einer einzigen Datenbank basiert, kann die Besonderheiten jedes einzelnen Dienstes nicht berücksichtigen. Bei MSA handelt es sich um ein dezentrales Datenmanagement, einschließlich des Einsatzes verschiedener Technologien.

Infrastrukturautomatisierung

MSA unterstützt kontinuierliche Bereitstellungs- und Bereitstellungsprozesse. Dies kann nur durch die Automatisierung von Prozessen erreicht werden. Gleichzeitig sieht die Bereitstellung einer großen Anzahl von Diensten nicht mehr beängstigend aus. Der Bereitstellungsprozess sollte langweilig werden. Der zweite Aspekt bezieht sich auf das Servicemanagement in einer Produktumgebung. Ohne Automatisierung wird die Verwaltung von Prozessen, die in verschiedenen Betriebsumgebungen ausgeführt werden, unmöglich.

Design für das Scheitern

Zahlreiche MSA-Dienste sind fehleranfällig. Gleichzeitig ist die Fehlerbehandlung in einem verteilten System keine triviale Aufgabe. Die Anwendungsarchitektur muss gegenüber solchen Ausfällen widerstandsfähig sein. Rebecca Parsons hält es für sehr wichtig, dass wir nicht einmal mehr die In-Process-Kommunikation zwischen Diensten nutzen; stattdessen greifen wir für die Kommunikation auf HTTP zurück, was bei weitem nicht so zuverlässig ist.

Architektur mit evolutionärer Entwicklung (Evolutionary Design)

Die Architektur des MSA-Systems soll sich evolutionär weiterentwickeln. Es empfiehlt sich, die notwendigen Änderungen auf die Grenzen eines einzelnen Dienstes zu beschränken. Auch die Auswirkungen auf andere Dienste müssen berücksichtigt werden. Der traditionelle Ansatz besteht darin, dieses Problem durch Versionierung zu lösen, MSA empfiehlt jedoch die Verwendung von Versionierung
als letztes.

Abschluss

Nach alledem können wir formulieren, was Microservices sind. Bei der Microservice-Architektur handelt es sich um einen Ansatz zur Entwicklung einer einzelnen Anwendung als Sammlung kleiner Dienste, die jeweils in einem eigenen Prozess ausgeführt werden und über einfache Mechanismen, häufig eine HTTP-Ressourcen-API, interagieren. Diese Dienste basieren auf Geschäftsfunktionen und können unabhängig voneinander bereitgestellt werden
automatisierter Bereitstellungsmechanismus. Es besteht ein Mindestmaß an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden.

Einen Architekturstil wählen (Teil 3)

Lesen Sie Teil 2

Source: habr.com

Kommentar hinzufügen