Zentrale Bestandteile einer Microservice-Infrastruktur

Für eine Microservice-Infrastruktur sind drei Komponenten von wesentlicher Bedeutung: Service-Registry, Konfigurationsmanagement und API-Gateway. Die beiden erstgenannten werden in diesem Blog-Beitrag näher erläutert.

Service-Registry

Da Microservice-Architekturen aus mehreren Applikations-Servern im Cluster bestehen, muss auch die Service-Registry Cluster-fähig sein. In der Regel schreibt man eine Service-Registry nicht selbst, sondern verwendet eine der etablierten OpenSource-Lösungen:

  • Eureka (aus dem Netflix-Stack)
  • Consul (von Hashicorp)
  • etcd (von Core OS)
  • ZooKeeper (von Apache)

Service-Discovery

Dabei muss man entscheiden, wie die Service-Registry von einem neuen Service erfährt: Entweder meldet sich der Microservice aktiv an der Registry an (Selbstregistrierung, z. B. über einen Eureka-Client) oder eine Zwischeninstanz übernimmt die Anmeldung (z. B. Registrator für Docker).

Ob man einen Whitebox-Ansatz (Selbstregistrierung) oder einen Blackbox-Ansatz (Registrator) wählt, tragt ein Stück weit zur Gesamtsystemqualität bei. Bei Consort ziehen wir den Whitebox-Ansatz vor, da sich die Entwickler bereits von Anfang an mit dem Gesamtsystem auseinandersetzen müssen: Wenn ich die Service-Discovery-Instanz als Microservice nicht erreichen kann, muss ich eine entsprechende Logmeldung erzeugen und es in wenigen Sekunden erneut versuchen. Bei einem Blackbox-Ansatz ist diese Verantwortung vom Entwickler ferngehalten. Operations versucht von außen – z.B. mit Registrator von Weave – einen Service zu finden und zu registrieren. Dieses Vorgehen führt in der Praxis dazu, dass Konfigurationsproblematiken später entdeckt werden und mehr Kommunikationsaufwand in der IT verursachen.

Verwendung der Service-Discovery Informationen

Der Hauptnutzer der Service-Discovery Informationen ist das API-Gateway mit all seinen laufenden Instanzen: Bei einem Zugriff von außen bestimmt es anhand der URL, welcher Service die Anfrage beantworten soll. Da dieses Thema viele Facetten aufweist, ist das einen separaten Blog-Eintrag wert.

Konfigurations-Management

Ein wichtiger Bestandteil eines Microservice ist seine Konfiguration: Üblicherweise wird angestrebt ein einziges Artefakt (Container) zu schaffen, das auf vielen verschiedenen Umgebungen identisch deployed werden kann (z. B. Dev, Stage, Produktion). Dazu müssen bestimmte Informationen aus dem Code ausgelagert werden:

  • Credentials/Secrets
    Informationen, mit denen der Service Kontakt zu anderen Services aufnehmen oder deren Antworten verifizieren kann (z. B. DB-Anmeldedaten, OAuth-Secrets)
  • Parameter
    Allgemeine Informationen, wie sich der Service verhält (z. B. Anzahl von Wiederholungsversuchen im Fehlerfall, E-Mail Templates)

Von extremer Wichtigkeit in einer Microservice-Umgebung ist, dass die Konfigurationen im Bezug auf Nachvollziehbarkeit und Informationssicherheit zentral verwaltbar sind. Deshalb dürfen Credentials/Secrets nur verschlüsselt gespeichert werden (z. B. in Vault von Hashicorp), während Parameter üblicherweise in Datenbanken oder Git-Repositories abgelegt werden.

Das bisher Gesagte lässt sich in der Übersicht der Schritte, die ein Microservice bei seinem Start durchlaufen muss, folgendermaßen zusammenfassen:

Initialisierung eines Microservice

Egal in welcher Programmiersprache ein Microservice geschrieben wurde und in welcher Cloud oder Microservice-Laufzeitumgebung er abläuft, lassen sich immer folgende Schritte finden:

Unterschiede ergeben sich durch Frameworks (wie z. B. Spring Boot), die bestimmte Schritte vor dem Entwickler verbergen oder Container-Frameworks, die die Aufrufrichtung von Schritt drei umkehren.

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.