In Microservice-Umgebungen ist es hilfreich, wenn bestimmte Funktionalitäten wie zum Beispiel Authentifizierung, Logging oder das Erfassen von Metriken über alle Dienste hinweg funktionieren; und das – bei mehreren Entwicklungsteams – auch noch auf die gleiche Art und Weise.
Erstellen des Gateway-Service im Initializr.
(Bild: Koller / Spring.io)
Die Lösung für dieses Problem ist es, diese Cross Cutting Concerns einer zentralen Instanz, einem API Gateway-Service zu überlassen. Eingehende Aufrufe laufen dann nicht mehr direkt vom Client zum Service, sondern nehmen den Umweg über das Gateway und werden von dort zum eigentlichen Empfänger geroutet. Auf dem zentralen Gateway lassen sich dann mithilfe von Filtern Aktionen wie Logging, Security-Überprüfungen und andere Funktionalitäten implementieren.
Für Spring Cloud gibt es mehrere dieser Gateways. Hier stellen wir das native Spring Cloud Gateway vor. Gegenüber dem bekannten und etwas älteren Zuul aus dem Netflix-Stack setzt Spring Cloud Gateway auf neuere Technologien wie Spring 5, Spring Boot 2 und Reactor und unterstützt Websockets.
Ein Test-Service
Um einen Service zum Testen zu haben, wird hier ein einfacher Service mit einem RestController (Dependency Spring Web im Initializr) implementiert. Er gibt beim Aufruf von http://localhost:8081/consumer/message (Achtung: server.port in application.properties anpassen!) eine Nachricht zurück:
```Java @RestController @SpringBootApplication @RequestMapping("/consumer") public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } @GetMapping("/message") public String hello() { return "Hallo vom Consumer"; } } ```
Einrichten des Gateway-Service
Erstellen des Gateway-Service.
(Bild: Dr. Koller / Spring.io)
Das Gateway wird ebenfalls in Form eines Spring Boot-Service eingerichtet. Das Anlegen des Projekts erfolgt am einfachsten mit dem Initializr. Dabei ist lediglich die Abhängigkeit Gateway zwingend erforderlich.
Wer den Service stattdessen von Hand in POM.xml konfigurieren möchte, sollte beachten, dass der Initializr neben der Abhängigkeit spring-cloud-starter-gateway auch noch Spring Cloud in Form einer Property und einem Eintrag unter Dependency-Management einrichtet.
Definieren von Routen
Die Konfiguration der Routen erfolgt wahlweise programmatisch in einer Java-Konfiguration oder in der Properties-Datei application.properties bzw. application.yml wie im folgenden Beispiel. Eine Route besteht aus einer frei wählbaren Id, einem URI zu dem weitergeleitet wird und einem Prädikat, das die Bedingung beschreibt, die zur Weiterleitung einer Anfrage führt. Im Beispiel unten prüft das Prädikat auf den Pfad /consumer/**. Ist das zutreffend, wird zum angegebenen URI http://localhost:8081/ weitergeleitet:
Ein Aufruf der Gateway-URL http://localhost:8080/consumer/message (der Default-Port 8080 wurde hier belassen) im Browser oder in Curl landet also bei http://localhost:8081/consumer/message und führt zur Anzeige der Nachricht vom Consumer-Service. Es gibt eine Menge weiterer Möglichkeiten, das Prädikat zu formulieren, etwa mithilfe von Zeitstempeln, der verwendeten HTTP-Methode und Query- oder Header-Parametern. Details dazu finden sich in der Dokumentation.
Erstellen von Filtern
Wie eingangs erwähnt, lassen sich auf dem Gateway Filter zur Bearbeitung von Standard- oder eigener Aufgaben einrichten. Für Standardaufgaben gibt es eine Reihe fertiger FilterFactories. Mit ihnen kann man zum Beispiel Request- oder Response-Header zufügen (AddRequestHeader, AddResponseHeader), Request-Parameter zufügen (AddRequestParameter) oder Umleiten (RedirectTo). Das folgende Beispiel zeigt die Verwendung des AddResponseHeader-Filters:
Eigene Filter erstellt man, indem man von einer der zahlreichen FilterFactories erbt oder die Interfaces GatewayFilter bzw. GlobalFilter implementiert. Globale Filter werden im Gegensatz zu Gateway-Filtern für alle Routen aufgerufen. Das folgende Beispiel zeigt das am Beispiel eines Pre-Filters, der vor dem Weiterleiten des Requests an den Service aufgerufen wird:
```Java @Component public class LoggingFilter implements GlobalFilter { final Logger logger = LoggerFactory.getLogger(LoggingFilter.class); @Override public Mono<Void> filter( ServerWebExchange exchange, GatewayFilterChain chain) { logger.info("Log vom Filter"); return chain.filter(exchange); } } ```
Selbstverständlich lassen sich auch Post-Filter implementieren, die dann nach dem Aufruf des Service vor der Rückgabe der Antwort an den Client abgearbeitet werden.
Hilfe beim Debugging
Funktionieren Routing oder Filter nicht wie gewünscht, empfiehlt sich das Anpassen des Log-Levels für das Gateway auf DEBUG oder TRACE in application.yml:
Im Log finden sich dann hilfreiche Informationen wie zum Beispiel die eingebundenen Routen:
``` Routes supplied from Gateway Properties: [RouteDefinition{id='consumer_path', predicates=[PredicateDefinition{name='Path', args={_genkey_0=/consumer/**}}], filters=[FilterDefinition{name='AddResponseHeader', args={_genkey_0=X-Organization-Id, _genkey_1=4711}}], uri=http://localhost:8081/, order=0, metadata={}}] (...) Netty started on port 8080 RouteDefinition consumer_path applying {_genkey_0=/consumer/**} to Path RouteDefinition consumer_path applying filter {_genkey_0=X-Organization-Id, _genkey_1=4711} to AddResponseHeader RouteDefinition matched: consumer_path New routes count: 1 Started GatewayApplication in 3.76 seconds (JVM running for 4.482) ```
Eine weitere Möglichkeit, Problemen auf die Spur zu kommen, ist das Actuator-Framework, das zur Laufzeit Einblicke in das Innenleben der Spring-Anwendung gewährt. Wie in einem früheren Beitrag zum Spring Boot Actuator beschrieben, ist dazu die folgende Dependency einzubinden:
``` XML <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> ```
Außerdem müssen die entsprechenden Endpoints freigegeben werden (hier der Einfachheit halber alle):
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.