Microservices – Konzepte und Best Practices

  • 14. Juli 2024
  • 3 min Lesezeit
  • Backend

Microservices sind heutzutage die beliebteste Architektur für die Entwicklung moderner und skalierbarer Cloud-Anwendungen. Durch die Aufteilung der Anwendung in kleinere, unabhängige Dienste sind Deployment und Wartung von einzelnen Anwendungsteilen problemlos möglich. Dadurch lassen sich schneller neue Funktionen bereitstellen oder Bugs beheben. In diesem Blogbeitrag soll aufgezeigt werden, wie sich die Kernkonzepte von Microservices konkret gestalten. Dazu zählen die folgenden Punkte: Konfiguration durch externe Parameter, Secrets, Health Checks, Logging, Metriken und Service Discovery.

Konfiguration

Die Konfiguration eines Service sollte immer vom eigentlichen Code getrennt sein. Dadurch verbessert sich vor allem die Flexibilität und die Sicherheit, da die Konfiguration / Parameter auch unabhängig vom Service verwaltet und aktualisiert werden können. Eine Änderung von Konfigurationsparametern erfordert also keinen neuen Build und Deployment des Services. Außerdem lässt sich dasselbe Artefakt in verschiedenen Umgebungen (Entwicklung, Test, Abnahme, Produktion) ausführen. Es ist kein eigener Build je Umgebung erforderlich.

Ein sehr typischer Ansatz ist die Verwendung von Umgebungsvariablen, die von der Laufzeitumgebung (bspw. Kubernetes oder AWS Container Services) in den Container injiziert werden.

Bei Verwendung eines Frameworks wie PyMS besitzt jeder Service eine eigene config.yaml Datei, in der die Konfiguration beschrieben wird. Diese muss dann zur Laufzeit ebenfalls vom System bereitgestellt werden.

Secrets

Secrets sind eine spezielle Form der Konfiguration, da sie schützenswerte Informationen enthalten, die aber dennoch ein Teil der Konfiguration sind. Auch sie sind je nach Umgebung / Ausführungskontext unterschiedlich.

Typische Ansätze bei Python Microservices gestalten sich folgendermaßen:

  • Nutzung von Kubernetes Secrets, die über Umgebungsvariablen injiziert werden.
  • Nutzung von AWS Secrets Manager und der Funktion GetSecretValue.
  • Entschlüsselung einer Secrets-Datei / Secret Store zur Laufzeit im Service.

Unabhängig davon, welchen Ansatz man wählt, sollte man zwingend vermeiden, Passwörter und andere Secrets im Klartext in Dockerfiles oder anderen Dateien fest zu hinterlegen. Dies kann relativ leicht dazu führen, dass das Secret im fertigen Image landet. Dies gilt es unter allen Umständen zu vermeiden.

Health Checks

Health Checks sind wesentlich für die Aufrechterhaltung der Verfügbarkeit von Microservices. Diese Checks überwachen den Status von Diensten (und optional wichtiger Abhängigkeiten), wodurch das System Fehler schnell erkennen kann. Je nach Umgebung können auch Gegenmaßnahmen eingeleitet werden, indem der Service bspw. nach mehrmaligem Fehlschlagen des Health Checks neugestartet wird.

Die Implementierung von Health Checks kann so einfach sein wie das Bereitstellen eines Health-Endpunkts in der API des Services (z. B. /health), der den Status des Dienstes zurückgibt. Alternativ kann ein Health Check auch die Datenbankkonnektivität, die Verfügbarkeit von Abhängigkeiten und die Ressourcennutzung prüfen und bei Bedarf einen Fehler zurückmelden.

Logging

Logging bezeichnet die Speicherung der Konsolenausgaben des Services für spätere Nachvollziehbarkeit bei unerwartetem Verhalten oder Ausfällen. Logging ist entscheidend für eine gute Überwachung und Fehlerbehebung von Microservices. Im Kontext von Microservices ist es jedoch eine sehr komplexe Aufgabe, da sich zu einem Vorgang gehörende Logs über mehrere Services erstrecken können. Eine Nachvollziehbarkeit des Problems ist dann nur möglich, wenn alle Logs zusammen betrachtet werden. Hierfür werden bspw. Correlation IDs eingesetzt.

Typische Ansätze bestehen aus der Verwendung von zentralisierten Logging-Lösungen wie dem ELK-Stack (Elasticsearch, Logstash, Kibana). Hiermit lassen sich bspw. Logs von mehreren Services aggregieren, was die Suche, Analyse und Visualisierung erleichtert.

Natürlich bringt auch jeder Cloud Provider entsprechende Lösungen mit (AWS CloudWatch, Azure Monitor, Cloud Logging). Meist sind diese Services eng mit weiteren Observability Tools wie Tracing, Monitoring und Profiling kombiniert.

Metriken

Metriken liefern Einblicke in die Leistung und das Laufzeitverhalten von Microservices. Typische Metriken sind Antwortzeiten, Fehlerraten und Ressourcenauslastung. Auch hierbei handelt es sich um einen Teilbereich von Observability. Durch die gesammelten Informationen lassen sich Speicherprobleme (Memory Leaks) oder Ressourcen-Engpässe identifizieren und optimieren.

Zur Sammlung von Metriken wird gerne Prometheus eingesetzt. Dies sammelt festgelegte Metriken, und erlaubt es sie auszuwerten und bei Bedarf Alertings zu generieren. Die Visualisierung erfolgt häufig mit Grafana.

Service Discovery

Um zu vermeiden, bestimmte Informationen zur Erreichbarkeit von Services fest im Code oder der Konfiguration hinterlegen zu müssen, wird häufig auf Service Discovery zurückgegriffen. Dies ermöglicht den Services, sich untereinander im verteilten System zu finden und miteinander zu kommunizieren. Hierfür muss jeder Service nur die Adresse der Registry kennen, und kann diese nach den gewünschten Zielen anfragen.

Zur Service Discovery werden häufig Tools wie Consul oder Eureka eingesetzt, aber auch Plattformen wie Kubernetes oder die gängigen Cloud Anbieter (AWS, Azure, Google) bringen entsprechende Möglichkeiten mit.

Zusammenfassung

In diesem Post haben wir einen kleinen Teil der Konzepte rund um Microservices betrachtet. Beachtet man diese, hat man bereits gute Karten, um die Flexibilität, Sicherheit und Zuverlässigkeit seiner Microservice-Architektur sicherzustellen.

Sie möchten eine Software auf Basis von Microservices implementieren lassen oder benötigen Unterstützung? Gerne können sie Himmelmann Technology Consulting zur Beratung oder Entwicklung beauftragen. Nehmen Sie hier Kontakt mit uns auf: Zum Kontaktformular

Quellen / Links:

Antworten