Lösungsmuster für Cross-Cutting Concerns in Microservices

Sidecar-Ansatz mit Kubernetes

Kubernetes (K8s) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen [3].

In Kubernetes ist die Lösung recht einfach, da die Kubernetes-Pods ohnehin einen Abstraktionslayer für Container bereitstellen. Das heißt, man liefert die Container immer innerhalb eines Pods  – z. B. einen Logging-Shipper aus.

Sidecars werden schon lange in Kubernetes benutzt – es bietet sich einfach dafür an. Allerdings ist es ohne weitere Hilfe schwierig, die Lebensdauer der einzelnen Container zu steuern. Daher bietet Kubernetes seit der Version 1.18 eine Identifikation eines Pods als Sidecar an. Werden Container so markiert, werden sie vor allen anderen gestartet und nach allen anderen gestoppt. In allem anderen verhalten sie sich wie normale Container [4].

Abb. 3 zeigt das Prinzip eines API-Gateways. In großen Microservice-Architekturen werden die Anzahl und das Verhalten von APIs (Application Programming Interface) schnell unübersichtlich.

Die APIs, die durch Microservices zur Verfügung gestellt werden, sind oft feingranular – und nicht wirklich das, was ein Konsument benötigt. Der Konsument muss mit vielen Services interagieren, um die Informationen zu bekommen, die er braucht. Um z. B. die Detailbeschreibung für ein Produkt dem Benutzer zur Verfügung zu stellen, muss der Client Beschreibung, Foto und Preis von unterschiedlichen Services abholen, deren Adresse jeweils bekannt sein muss [11].

Daher macht es Sinn, APIs von Microservices, die zu einer Domäne gehören, über einen Zugangsweg zusammenzufassen. Diese Zusammenfassung wird durch ein API Gateway zur Verfügung gestellt. Diese Zusammenfassung macht das Erstellen von Konsumenten und das Beobachten wesentlich einfacher, da nur noch ein Eintrittspunkt in die jeweilige Domäne bekannt sein muss. Über diese Gateways können dann Zugriffe auf die Domäne durch externe Services abgesichert und gesteuert werden. Zugriffe können beobachtet werden und gegebenenfalls schon hier z. B. wegen zu hoher Last abgewiesen werden.

API Gateways werden von unterschiedlichen Cloudanbietern und Softwareherstellern angeboten. Als Beispiele seien hier Apigee (Google) [12] und Mulesoft [13] genannt. Dabei bieten diese Plattformen wesentlich mehr als das eigentliche API Gateway, sie umfassen ganze API-Management-Aufgaben inklusive Veröffentlichung von APIs, Testen von APIs und Abonnieren von APIs.

Das Botschafter- oder auch Ambassador-Muster schafft Verlässlichkeit beim Zugriff auf Remote-Services [14]. Liegen Dienste außerhalb der eigenen Domäne, hat man in der Regel keinen Einfluss auf die Verfügbarkeit oder auch Antwortgeschwindigkeit des externen Dienstes.

Die Resilienz (Widerstandsfähigkeit) des konsumierenden Services wird durch die Entsendung eines "Botschafters" in die konsumierende Domäne erreicht. Dieses Muster ist besonders bei der Verteilung von Stammdaten empfehlenswert, da viele Services auf der einen Seite diese Daten benötigen und auf der anderen Seite der Stammdatenservice als "Single Point of Failure" zu Ausfällen des Gesamtsystems führen kann.

Der Botschafter wird als Beiwagen an die Fachanwendung gehängt. Der Beiwagen puffert die Daten und stellt sie transparent der Fachanwendung zur Verfügung. Transparent bedeutet hier, dass die Fachanwendung auf den Botschafter zugreifen kann, als wäre es der Stammdatenservice selbst. Nur der Beiwagen oder auch Botschafter kommuniziert mit der Stammdatenanwendung, die Fachanwendung kommuniziert nur mit dem Beiwagen. Dadurch können Stammdaten sehr schnell und unabhängig von der Stammdatenverwaltung selbst zur Verfügung gestellt werden.

Um Stammdatenänderungen schnell und zuverlässig den Fachanwendungen zur Verfügung zu stellen, müssen entsprechende Invalidierungsnachrichten vereinbart werden. Um hier noch unabhängiger zu werden, können diese auch über eine Event-Bus verteilt werden. Der Beiwagen enthält dann den entsprechenden Konsumenten für den Event-Bus.

Event-Busse unterscheiden sich maßgeblich von Nachrichten-Bussen, da Konsument und Produzent von Nachrichten vollkommen unabhängig sind. Während bei Nachrichten-Bussen die Nachrichten von Produzenten empfangen und an Konsumenten weitergeleitet werden, werden bei Event-Bussen die Events gespeichert und können von allen Interessierten gelesen werden (entsprechende Rechte vorausgesetzt). Obwohl ein solcher Event-Bus wiederum wie ein Single-Point-of-Failure aussieht, bietet er doch wesentliche Vorteile. Produzenten müssen sich nicht darauf verlassen, dass Konsumenten verfügbar sind. Konsumenten müssen sich nicht darauf verlassen, dass der Produzent von Events verfügbar ist. Der Bus muss die Nachrichten nicht weiterleiten, daher muss er nicht "Retry-Mechanismen" implementieren, stattdessen greift der Konsument auf die Events zu, wenn er sie braucht. Dabei stellt der Event-Bus "Lesezeichen" zur Verfügung, damit der Konsument wieder da einsetzen kann, wo er beim letzten Lesen aufgehört hat.

Diese vielen Vorteile werden mit einem zusätzlichen Element in der Infrastruktur erkauft. Dieses muss in jedem Fall hochverfügbar sein, da die Verfügbarkeitsanforderungen sowohl vom Produzenten als auch vom Konsumenten sichergestellt werden müssen.

Die bekannteste Event-Bus-Implementierung ist sicher Apache Kafka [15]. Aber auch Amazon Kinesis [16] oder Microsoft Azure Event Hubs [17] bieten ähnliche Eigenschaften.