Spring Cloud Gateway
von Michael Wellner
Ein API Gateway dient als zentraler Einstiegspunkt für die Microservice Landschaft. Es vermittelt die Requests eines Benutzers zu den Rest Endpoints eines dahinter liegenden Microservices. Außerdem kann es die Anfragen verschiedener Clients (z.B. Browser, Mobile) "abfangen" und entsprechend weiterleiten. Aus Sicherheitsaspekten ist der wichtigste Grund für ein Gateway die Möglichkeit zur Authentifizierung sowie Autorisierung. Das zentrale Logging der Requests ist sicher ebenfalls ein Pluspunkt für ein API Gateway.
Scope
In diesem Artikel soll es nicht allgemein um das Für und Wider eines API Gateways gehen, sondern eher um die Evaluation des "neuen" Spring Cloud Gateways im Rahmen eines dreitägigen code camps.
Die Spring Cloud Service Landschaft und das Spring Cloud Gateway
Abbildung 1
In obiger Abbildung (Abbildung 1) ist gut zu sehen, dass das Spring Cloud Gateway der zentrale Einstiegspunkt in die Microservice Landschaft ist.
Abbildung 2
Die Abbildung 2 zeigt, das Spring den Netflix Stack nach und nach in den Maintenance Mode schickt und durch andere Komponenten (überwiegend aus dem eigenen Hause) ersetzt.
Maintenance Mode bedeutet, dass die Netflix Komponenten nicht weiter entwickelt werden und auch keine Pull Requests mehr bearbeitet werden.
Spezifikation
Das Spring Cloud Gateway basiert auf Spring 5 und dem Project Reactor. Es benötigt deshalb mindestens Java 8 und Spring Boot 2.
Das Gateway läuft nicht unter den klassischen Servlet Containern Tomcat oder Jetty sondern mit Netty - einem asynchronen event-driven Framework.
Das Routing kann mittels Fluent Java Code oder über die Spring YAML config definiert werden.
Außerdem kann es sehr gut als "Embedded Gateway" oder "Sidecar" direkt an einen Service gebunden werden um diesen durch die zusätzlichen Features (RateLimiting, Security, etc.) des Gateways auszustatten.
Möglichkeiten aus Business Sicht
Die Migration eines Monolithen zu mehreren Microservices ist in aller Munde. Das Spring Cloud Gateway kann hier durch "schlaues" Routing unterstützen.
Außerdem kann es gut für Feature Toggles oder Maintenance eingesetzt werden. Dazu gibt es zeitbasiertes Routing, also z.B. [GET localhost:8787/test] -> führt vor 01.06.2019 03:00 Uhr zu [GET localhost:8041/api/v1/test] und danach zu [GET localhost:8041/api/v2/test].
Zusätzlich bietet es die Möglichkeit Resilienz schon direkt ab dem API Gateway einzubauen (Nachteil ist, dass hier noch Netflix Hystrix verwendet wird).
Technische Funktionen
Durch Project Reactor ist das Gateway "reaktiv" bzw. "non-blocking" (Requests blockieren keine Threads mehr, während sie auf eine Antwort warten -> Event Loop). Die Verwendung der Java 8 Predicates als Prüfung ist möglich.
Relative einfache Einbindung folgender Features:
- Discovery Client (mit Eureka)
- Load Balancer (mit Ribbon)
- Resilienz (mit Hystrix)
- Rate Limiting (z.B. mit Redis)
- Pfadänderungen
- zeitabhängiges Routing (before/after/between)
- Spring Security
- Einbindung eigener Filter
Fazit
Es werden auf jeden Fall Kenntnisse in in reaktiver Programmierung (Stichworte: "non-blocking", "WebFlux", "Flux", "Mono", "Streams", "Publisher", "Subscriber", "Netty") benötigt.
Falls man bereits das Netflix Zuul Gateway verwendet hat und sich mit dem Verhalten eines Gateways vertraut gemacht hat, ist dies natürlich vom Vorteil.
Als Basis dient Java 8 (wobei das meiner Meinung nach heutzutage in jedem Projekt das Minimum sein sollte).
Da Spring wohl das Netflix "Projekt" langsam ausschleicht, ist es von Vorteil, sich mal mit Alternativen zu beschäftigen. Leider wird in Spring Cloud Gateway in gewissen Teilen - wie z.B. Resilienz - doch noch auf Hystrix zurück gegriffen.
Bewertung/Relevanz aus meiner Sicht: 4/5.