Fünf Kernkomponenten der Microservices-Architektur

1. Microservices

Microservices bilden die Grundlage einer Microservices-Architektur. Der Begriff beschreibt die Methode der Zerlegung einer Anwendung in kleine, in sich geschlossene Dienste. Diese sind in einer beliebigen Sprache geschrieben und kommunizieren über leichtgewichtige Protokolle. Die Vorteile liegen auf der Hand: Mit unabhängigen Microservices können Softwareteams iterative Entwicklungsprozesse implementieren sowie Funktionen flexibel erstellen und aktualisieren.

Um von den Vorteilen zu profitieren, gilt es einige Basics zu beachten: Entwicklerteams müssen die richtige Größe für Microservices festlegen. Sie sollten dabei bedenken, dass eine zu granulare Sammlung von vielen segmentierten Diensten einen hohen Overhead- und Verwaltungsaufwand verursacht.

Um Abhängigkeiten zwischen den Services zu minimieren sollten Entwickler diese gründlich entkoppeln und die Autonomie der Dienste gewährleisten. Und sie sollten leichtgewichtige Kommunikationsprotokolle wie REST und HTTP verwenden.

2. Container

Container sind Softwareeinheiten, die Services und deren Abhängigkeiten in einem Paket zusammenfassen und durch Entwicklung, Test und Produktion eine konsistente Einheit aufrechterhalten. Container sind zwar für die Bereitstellung von Microservices nicht erforderlich. Ebenso wenig werden Microservices für die Nutzung von Containern benötigt. Container können jedoch die Bereitstellungszeit und die Effizienz von Anwendungen in einer Microservices-Architektur stärker verbessern als andere Bereitstellungstechniken wie zum Beispiel Virtuelle Maschinen (VM).

Der Hauptunterschied zwischen Containern und VMs besteht darin, dass Container ein Betriebssystem und Middleware-Komponenten gemeinsam nutzen können. Eine VM enthält für ihre Nutzung hingegen ein vollständiges Betriebssystem. Weil es nicht notwendig ist, dass jede VM ein eigenes Betriebssystem für jeden Service bereitstellen muss, können Unternehmen eine größere Sammlung von Microservices auf einem einzigen Server ausführen.

Container haben noch weitere Vorteile: So können sie bei Bedarf ohne negative Auswirkungen auf die Anwendungsleistung bereitgestellt werden. Entwickler können sie außerdem mit relativ geringem Aufwand ersetzen, verschieben und replizieren. Die Unabhängigkeit und Konsistenz von Containern ist ein entscheidender Teil der Skalierung bestimmter Stücke einer Microservices-Architektur – je nach Arbeitslast – und nicht der gesamten Anwendung. Container unterstützen auch Microservices bei der erneuten Bereitstellung nach einem Ausfall.

Docker wurde als Open-Source-Plattform für das Containermanagement entwickelt und ist inzwischen einer der bekanntesten Anbieter im Containerbereich. Der Erfolg von Docker führte dazu, dass sich um das Unternehmen herum ein großes Tool-Ökosystem entwickelte. Dieses brachte beliebte Containerorchestratoren wie Kubernetes hervor.

3. Service-Mesh

Mit einem Service-Mesh lässt sich kontrollieren, wie bestimmte Teile einer Anwendung Daten miteinander teilen. Im Gegensatz zu anderen Systemen der Kommunikationsverwaltung ist ein Service-Mesh eine dedizierte, direkt in die App integrierte Infrastrukturschicht.

In einer Microservices-Architektur erzeugt ein Service-Mesh eine dynamische Messaging-Schicht, um die Kommunikation zu erleichtern. Es abstrahiert die Kommunikationsschicht, was bedeutet, dass Entwickler bei der Erstellung der Anwendung keine Interprozesskommunikation programmieren müssen.

Das Service-Mesh-Tooling verwendet normalerweise ein Sidecar-Muster – der Name kommt daher, weil es an einen Beiwagen erinnert, der an ein Motorrad angebracht wird. Das Sidecar erzeugt einen Proxy-Container, der neben den Containern sitzt, die entweder eine einzelne Microservices-Instanz oder eine Sammlung von Diensten haben. Das Sidecar routet den Verkehr zu und von dem Container und lenkt die Kommunikation mit anderen Sidecar-Proxys, um Serviceverbindungen aufrechtzuerhalten.

Zwei der heute beliebtesten Service-Mesh-Optionen sind Istio und Linkerd. Istio ist ein Projekt, das Google zusammen mit IBM und Lyft ins Leben gerufen hat, Linkerd, ein Projekt der Cloud Native Computing Foundation. Sowohl Istio als auch Linkerd sind an Kubernetes gebunden, obwohl sie bemerkenswerte Unterschiede in Bereichen wie der Unterstützung von Nicht-Container-Umgebungen und Traffic-Control-Funktionen aufweisen.

4. Service-Discovery

Egal, ob sich Anwendungen ändern, Aktualisierungen vorgenommen werden oder Fehler behoben werden – die Anzahl der aktiven Microservices-Instanzen in einer Bereitstellung schwankt. Es kann schwierig sein, den Überblick über eine große Anzahl von Diensten zu behalten, die sich an verteilten Netzwerkstandorten in der gesamten Anwendungsarchitektur befinden.

Service-Discovery hilft den Service-Instanzen bei der Anpassung an eine sich ändernde Bereitstellung und bei der entsprechenden Lastverteilung zwischen den Microservices. Die Service-Discovery-Komponente besteht aus drei Teilen:

• einem Service-Provider, der Service-Instanzen über ein Netzwerk erzeugt;
• einer Service-Registry, die als Datenbank fungiert, in der der Standort verfügbarer Service-Instanzen gespeichert wird; und
• einem Service-Consumer, der den Standort einer Service-Instanz aus der Registry abruft und dann mit dieser Instanz kommuniziert.

Service-Discovery besteht aus zwei Discovery Pattern:

• Ein Client-seitiges Discovery Pattern durchsucht die Service-Registry, um einen Service-Provider zu finden, wählt mit Unterstützung eines Lastausgleichsalgorithmus eine geeignete und verfügbare Serviceinstanz aus und stellt dann eine Anfrage.
• Bei einem serverseitigen Discovery Pattern durchsucht der Router die Service-Registry und leitet – sobald die zutreffende Service-Instanz gefunden wurde – die Anforderung entsprechend weiter.

Die in der Service-Registry gespeicherten Daten sollten immer aktuell sein, so dass verwandte Dienste ihre zugehörigen Serviceinstanzen zur Laufzeit finden können. Wenn die Service-Registry ausgefallen ist, behindert dies alle Dienste. Um regelmäßige Ausfälle zu vermeiden verwenden Unternehmen in der Regel eine verteilte Datenbank wie Apache ZooKeeper.

5. API-Gateway

Eine weitere wichtige Komponente einer Microservices-Architektur ist das API-Gateway. API-Gateways sind für die Kommunikation in einer verteilten Architektur unerlässlich, da sie die wichtigste Abstraktionsschicht zwischen Microservices und den externen Clients erzeugen können.

Das API-Gateway übernimmt einen großen Teil der Kommunikations- und Verwaltungsrollen, die typischerweise innerhalb einer monolithischen Anwendung auftreten. Auf diese Weise bleiben die Microservices leichtgewichtig. Außerdem können sie Anfragen authentifizieren, zwischenspeichern und verwalten, sowie den Nachrichtenverkehr überwachen und bei Bedarf einen Lastausgleich durchführen.

Darüber hinaus kann ein API-Gateway die Kommunikation zwischen Microservices und Clients beschleunigen. Dies geschieht dadurch, dass es die Übersetzung von Messaging-Protokollen standardisiert und sowohl den Client als auch den Dienst von der Aufgabe befreit, in unbekannten Formaten geschriebene Anforderungen zu übersetzen. Die meisten API-Gateways bieten auch eingebaute Sicherheitsfunktionen. Sie können damit die Autorisierung und Authentifizierung für Microservices verwalten und eingehende und ausgehende Anfragen verfolgen, um mögliche Einbrüche zu identifizieren.

Auf dem Markt ist eine breite Palette von API-Gateway-Optionen verfügbar. Nutzer können daraus die beste Option für ihren Bedarf wählen – sowohl von proprietären Cloud-Plattform-Anbietern wie Amazon Web Services (AWS) und Microsoft Azure als auch von Open-Source-Anbietern wie Kong und Tyk.