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.
Beim letzten Mal haben wir über verschiedene Arten von Monolithen und die Verwendung von Komponenten zu ihrem Aufbau gesprochen, sowohl über Bauteile als auch über Bereitstellungskomponenten. Wir haben uns mit der serviceorientierten Architektur beschäftigt.
Jetzt werden wir endlich die grundlegenden Merkmale der Mikroservice-Architektur definieren.
Architekturbeziehungen
Es ist wichtig zu verstehen, dass, basierend auf den vorherigen Artikeln, jeder Service ein Bestandteil ist, jedoch nicht jeder Service ein Mikrodienst ist.
Merkmale der Mikrodienstarchitektur
Die Hauptmerkmale der Mikrodienstarchitektur sind:
- Organisation nach Geschäftsmöglichkeiten (Organized around Business Capabilities)
- Produkte statt Projekte (Products not Projects)
- Intelligente Endpunkte und einfache Kanäle (Smart endpoints and dumb pipes)
- Dezentrale Steuerung (Decentralized Governance)
- Dezentrales Datenmanagement (Decentralized Data Management)
- Automatisierung der Infrastruktur (Infrastructure Automation)
- Ausfallsicherheit (Design for failure)
- Architektur mit evolutionärem Design (Evolutionary Design)
Der erste Punkt kommt aus der serviceorientierten Architektur, da Mikrodienste eine spezielle Form von Services darstellen. Die anderen Punkte verdienen eine separate Betrachtung.
Organisation nach Geschäftsmöglichkeiten (Organized around Business Capabilities)
Jetzt sollten wir das Conway-Gesetz berücksichtigen: Organisationen, die Systeme entwickeln, gestalten deren Architektur so, dass sie die Interaktionsstruktur innerhalb dieser Organisationen widerspiegelt. Ein Beispiel hierfür ist die Entwicklung eines Compilers: Ein Team von sieben Personen hat einen Siebendurchlauf-Compiler entwickelt, während ein Team von fünf Personen einen Fünfdurchlauf-Compiler erstellt hat.
Wenn wir über Monolithen und Mikrodienste sprechen und die Entwicklung in funktionale Abteilungen organisiert ist (Backend, Frontend, Datenbankadministratoren), entsteht dann ein klassischer Monolith.
Um Mikrodienste zu erhalten, sollten die Teams nach Geschäftsmöglichkeiten organisiert werden (Bestellung, Versand, Katalog). Diese Organisation ermöglicht es den Teams, sich auf die Erstellung spezifischer Teile der Anwendung zu konzentrieren.
Produkte statt Projekte (Products not Projects)
Ein projektorientierter Ansatz, bei dem ein Team entwickelte Funktionen an andere Teams übergibt, ist bei einer Microservice-Architektur nicht geeignet. Ein Team sollte das System während seines gesamten Lebenszyklus unterstützen. Das Unternehmen Amazon, eines der Vorreiter der Microservices, erklärte: „Sie bauen das Produkt, und Sie führen es auch.“ 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. Dies führt häufig zu dem sogenannten Erroneous Spaghetti Box, was bedeutet, dass die Komplexität eines Monolithen in die Komplexität der Verbindungen zwischen den Services übergeht. In einer Microservice-Architektur werden nur einfache Interaktionsmethoden verwendet.
Dezentrale Steuerung (Decentralized Governance)
Entscheidungen zu Microservices sollten von denjenigen getroffen werden, die tatsächlich Microservices entwickeln. Hierbei beziehen sich die Schlüsselentscheidungen auf
Programmiersprachen, Bereitstellungsmethoden, Verträge öffentlicher Schnittstellen usw.
Dezentrales Datenmanagement (Decentralized Data Management)
Der Standardansatz, bei dem eine Anwendung sich auf eine einzige Datenbank stützt, kann die Besonderheiten jedes einzelnen Dienstes nicht berücksichtigen. MSA sieht eine dezentrale Datenverwaltung vor, einschließlich der Verwendung verschiedener Technologien.
Automatisierung der Infrastruktur (Infrastructure Automation)
MSA unterstützt Prozesse der kontinuierlichen Bereitstellung und Lieferung. Dies kann nur durch die Automatisierung von Prozessen erreicht werden. In diesem Zusammenhang erscheint die Bereitstellung einer großen Anzahl von Dienstleistungen nicht mehr als bedrohlich. Der Bereitstellungsprozess sollte zur Routine werden. Der zweite Aspekt betrifft das Management von Diensten in einer Produktionsumgebung. Ohne Automatisierung wird das Management von Prozessen, die in unterschiedlichen Betriebssystemen laufen, unmöglich.
Ausfallsicherheit (Design for failure)
Zahlreiche Dienste im Rahmen von MSA sind anfällig für Ausfälle. Die Fehlerbehandlung in einem verteilten System ist dabei eine alles andere als triviale Aufgabe. Die Architektur von Anwendungen muss gegenüber solchen Ausfällen robust sein. Rebecca Parsons hebt hervor, dass wir nicht einmal mehr die interne Kommunikation zwischen den Dienstleistungen nutzen, sondern stattdessen auf HTTP zurückgreifen, welches bei weitem nicht so zuverlässig ist.
Architektur mit evolutionärem Design (Evolutionary Design)
Die MSA-Systemarchitektur sollte sich evolutionär entwickeln. Es ist wünschenswert, notwendige Änderungen innerhalb der Grenzen eines einzelnen Dienstes zu begrenzen. Zudem muss der Einfluss auf andere Dienste berücksichtigt werden. Der traditionelle Ansatz besteht darin, zu versuchen, dieses Problem durch Versionierung zu lösen, aber MSA sieht vor, Versionierung nur als letzte Maßnahme zu verwenden.
als letzte Maßnahme.
Fazit
Nach all dem Gesagten lässt sich formulieren, was Mikrodienste sind. Die mikrodienstbasierte Architektur ist ein Ansatz zur Entwicklung einer Anwendung als eine Reihe kleiner Dienste, von denen jeder in seinem eigenen Prozess arbeitet und über leichtgewichtige Mechanismen, häufig über HTTP-APIs, interagiert. Diese Dienste sind auf Geschäftsanforderungen ausgerichtet 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 und unterschiedliche Datenspeichertechnologien verwenden können.
Quelle: habr.com
