5 Best Practices für REST-basierte Microservices

In diesem Beitrag möchte ich Ihnen fünf Best Practices vorstellen, mit denen Sie Ihre Microservice-Architektur sowohl Anwender- als auch Entwickler-freundlich gestalten können. Als Ergebnis wird Ihre Microservice-Architektur einerseits widerstandsfähiger und anderseits lassen sich Fehler leichter verwalten und nachvollziehen. Versprochen.

User-Agent

Es ist sehr wichtig, einen aussagekräftigen Namen im Anfrage-Header anzugeben, denn dadurch können Anwender bspw. erkennen, von welchem Microservice eine Anfrage stammt, die einen großen Speicherzugriff mit einem langsamen Antwortverhalten des System auslöst. Es empfiehlt sich, den logischen Namen der Service-ID in der User-Agent-Eigenschaft im Request-Header anzugeben. Beispiel: User-Agent: EmployeeSearchService.

Versionskontrolle

In der REST-basierten Microservice-Architektur greift ein Microservice über die API auf die Ressourcen eines anderen Microservice zu. Die API fungiert als Fassade für andere Microservices. Hier sollten Sie darauf achten, die API von Anfang an so zu implementieren, dass sie möglichst selten verändert wird. Andernfalls führt die Verwendung durch andere Microservices dazu, dass alle Änderungen in der API-Methodensignatur Fehler an anderen Stellen im Code auslösen können.

Die Ironie ist, dass Veränderungen unvermeidbar sind, da wir die Zukunft nicht kennen. Eine heute gültige Geschäftsstrategie könnte bereits in wenigen Tagen überholt sein, so dass die API überarbeitet werden muss. Als Architekt besteht die größte Herausforderung darin, mit diesen Veränderungen umzugehen. Die Lösung liegt in der Verwendung einer Versionskontrolle. Immer wenn Sie eine neue Version erzeugen, sollten Sie potentielle Anwender oder Kunden darüber informieren, so dass diese die Chance erhalten, innerhalb eines festgelegten Zeitrahmens auf die neue Version migrieren zu können. In diesem Zeitraum sollten Sie als API-Anbieter beide Versionen pflegen und den Verbrauchern Hinweise liefern, wie die Migration der API-Aufrufe am besten gelingt. Nach Ablauf des festgelegten Zeitraums können Sie Ihre alte Version außer Betrieb nehmen.

Universally Unique Identifier

Da eine Geschäftsfunktionalität in einer Microservice-Architektur über mehrere Microservices verteilt ist, wird eine Anfrage von einem Client intern in viele separate Anfragen aufgeteilt. In der Praxis kann es immer wieder vorkommen, dass einzelne Services nur langsam oder auch gar nicht funktionieren. Für Entwickler ist es daher wichtig, die gesamte Microservice-Gesamtstruktur nachvollziehen zu können. Um herauszufinden, welcher Dienst nur langsam funktioniert, müssen Sie die Anfragen gruppieren. Es empfiehlt sich, eine zufällige Universally Unique Identifier (UUID) für eine Client-Anfrage zu generieren, und diese an jede interne Anfrage weiterzugeben. So können Sie jederzeit per Protokoll die UUID verfolgen und den Call entsprechend aufspüren.

ELK Implementation

Microservices sind für das Autoscaling gedacht, so dass es in einem komplexen Business-Bereich sehr schwierig ist, Log-Dateien für Microservices zu verwalten. Bspw. werden in einem System mit 50 Microservices und jeweils 10 Instanzen 500 Log-Dateien generiert. Als Entwickler ist es nicht möglich, sich bei jeder Instanz anzumelden und Protokolle abzufragen, um ein Problem zu untersuchen. Daher benötigen Sie einen zentralen Mechanismus, bei dem alle Protokolle abgelegt werden und Sie eine intelligente Suche über dieses Protokoll durchführen können. ELK stellt diese Funktionalität bereit, wobei E für ElasticSearch, L für Logstash und K für Kibana steht. ElasticSearch speichert die Protokolle und bietet eine „unscharfe“ Suchfunktion, Logstash wird verwendet, um Protokolle aus verschiedenen Quellen zu sammeln und sie zu transformieren, und Kibana ist eine grafische Benutzeroberfläche, auf der ein Entwickler die Protokolle nach Bedarf durchsuchen kann. Alternativ können Sie Splunk oder ein anderes Open Source-Framework zum Zentralisieren und Analysieren der Protokolle verwenden.

Ausfallsicherheit

In einer Microservice-Architektur sind viele Microservices involviert, um eine Business-Funktionalität zu vervollständigen. Dabei kommt es vor, dass einer der Dienste nicht antwortet und somit der gesamte Informationsfluss unterbrochen wird. Zur Bewältigung eines solchen Szenarios ist die Ausfallsicherheit von größter Bedeutung. Daher sollte für jeden Dienst, der eine bestimmte Zeit nicht antwortet, ein Fallback-Pfad vorhanden sein, sodass der Benutzer nicht auf die Antwort warten muss, sondern sofort per standardisierter Meldung benachrichtigt wird.

Die 5 Best Practices bei REST-basierten Microservices.

Fazit

Berücksichtigen Sie beim Erstellen von REST-basierten Microservices zwei Perspektiven:

• die User Experience
• und die Entwicklerperspektive.

Auf der einen Seite möchte ein Anwender ungern warten. Im Falle einer Fehlfunktion benötigt er eine klare, nicht technische Information darüber, welches Problem vorliegt, so dass er in der Folge mit dem technischen Support zielgerichtet kommunizieren kann. Auf der anderen Seite benötigt der Entwickler Informationen zu dem Microservice, der das Problem verursacht hat. Dazu verwendet er idealerweise die protokollierten Informationen. Wenn Sie also REST-basierte Microservices entwickeln wollen, beachten Sie am besten immer beide Perspektive, denn so lassen sich Probleme leichter nachvollziehen, analysieren und auch lösen.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Der Beitrag von Shamik Mitra ist im Original unter https://dzone.com/articles/5-best-practices-for-rest-based-microservices erschienen. Mit Zustimmung von Shamik Mitra übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.