Grundsatz Nr. 1 der Microservices-Architektur: Jeder Microservice liefert eine einzige vollständige Geschäftsfunktion

Dieser Beitrag ist der erste in einer sechsteiligen Serie über die Prinzipien von Microservices. Die anderen Teile sind: Autonomie, Kleiner begrenzter Kontext, Asynchrone Kommunikation, Beste Technologie und Ein Team.

Microservices sind ein heißes Thema. Deshalb sagen viele Leute eine Menge Dinge. Um Unternehmen dabei zu helfen, das Beste aus diesem neuen Architekturstil herauszuholen, hat Xebia eine Reihe von Prinzipien definiert, die unserer Meinung nach bei der Implementierung einer Microservice-Architektur angewandt werden sollten. In diesem Blog wird erklärt, warum ein Microservice eine vollständige Geschäftsfähigkeit liefern sollte.

Eine vollständige Business Capability ist ein Prozess, der ohne Unterbrechungen oder Abstecher zu anderen Diensten fortlaufend abgeschlossen werden kann. Das bedeutet, dass eine Business Capability nicht von anderen Diensten abhängen sollte, um ihre Arbeit abzuschließen. Wenn ein Prozess in einem Microservice von anderen Microservices abhängt, würden wir in der Abhängigkeitshölle enden, die ESBs eingeführt haben: Um eine Kundenanfrage zu bearbeiten, benötigen wir viele andere Dienste und wenn einer von ihnen ausfällt, steht alles still. Eine robustere Lösung wäre es, einen Dienst zu definieren, der einen für einen Benutzer sinnvollen Prozess abwickelt. Ein Beispiel ist die Bestellung eines Buches in einem Webshop. Dieser Prozess würde mit der Auswahl eines Buches beginnen und mit der Erstellung einer Bestellung enden. Die eigentliche Ausführung der Bestellung ist ein anderer Prozess, der in einem eigenen Dienst untergebracht ist. Der Erfüllungsprozess kann direkt nach dem Bestellprozess ablaufen, muss es aber nicht. Wenn der Kunde eine PDF-Version eines Buches bestellt, kann die Auftragsabwicklung sofort abgeschlossen werden. Handelt es sich bei der Bestellung um die gedruckte Version, kann der Bestellservice lediglich den Versand des Buches anfordern. Durch die Aufteilung dieser beiden Prozesse auf verschiedene Dienste können wir entscheiden, wie der Prozess abgeschlossen werden soll, und so sicherstellen, dass ein Problem oder eine Verzögerung in einem Dienst keine Auswirkungen auf andere Dienste hat. Die Grundlage einer robusten Architektur besteht also darin, einen Microservice so aufzubauen, dass er eine einzige Aufgabe ohne Unterbrechungen oder Wartezeiten gut erledigt.

[bearbeitet: 3 aug 2015 - Präambel hinzugefügt und Zeile"In den nächsten Tagen werden wir jedes dieser Prinzipien in einer Reihe von Blogbeiträgen ausführlicher behandeln." entfernt]