Heiko Maaß Software-Entwicklung und Elektronische Musik

Schrittweise Migration von Spring MVC auf Spring Webflux

Motivation für Webflux

Spring Webflux bietet mit seiner reaktiven Arbeitsweise ein Framework für Webservices, die viele parallele, I/O-lastige Tätigkeiten ausführen müssen. Im aktuellen Projekt haben wir so einen Service: Er fragt viele andere WebServices parallel an und kombiniert die Antworten zu einer übergreifenden Antwort. Als wir vor ein paar Jahren mit dem Service begonnen hatten, hatten wir für die Request-Parallelisierung sog. CompletableFutures eingesetzt, die mit dem JDK-8 eingeführt worden sind. Sie vereinfachen die Umsetzung von parallelen Aufgaben, haben aber einen entscheidenden Nachteil: Pro ausgehenden Request wird immer ein eigener Thread benötigt. Je mehr Subservices angebunden und parallel aufgerufen werden, desto mehr parallel laufende Threads werden benötigt. Das ist nicht ressourceneffizient, da jeder Thread zusätzlich RAM für seinen eigenen Stack benötigt.

Spring Webflux kommt mit einem asynchronen HttpClient, dem sog. WebClient. Dieser arbeitet intern mit einem sehr kleinem Pool von Threads und informiert den Aufrufer asychron, sobald eine Http-Antwort verarbeitet wurde. Der nachfolgende Code muss ebenfalls “reaktiv” werden, d.h. er arbeitet nicht mehr mit dem eigentlichen Rückgabewert, sondern mit einem sog. Publisher, der irgendwann den Wert an seinen Subscriber propagiert. Spring Webflux bietet dazu die Publisher-Implementierungen Mono (0-1 Wert) und Flux (0-n Werte) an.

Herausforderungen bei der Migration

Die bisherigen synchronen Aufrufe müssen durch asychrone Aufrufe ersetzt werden, dazu gehört auch das komplette Exception-Handling. Das FAQ des Project Reactor liefert eine gute Hilfe für die Migration Durch den Wegfall der expliziten, gebundenen Threads funktionieren sämtliche Konstrukte nicht mehr, die auf ThreadLocals angewiesen sind. Dazu gehören u.a. die SpringMVC-Features wie “RequestScoped Beans”, oder auch der ThreadContext von Log4J2. Auch bisherige Servlet-Filter und ClientHttpRequestInterceptor greifen nicht mehr. Zudem müssen sämtliche Spring-WebMVC-Integrationstests und Cloud Contract Tests auf die Webflux-API angepasst werden. Und damit nicht genug: Auch die Spring Security-Configuration muss ebenfalls angefasst werden.

In der Summe also ein sehr großer Rewrite. Da der Service bereits in Produktion ist und parallel noch zwei weitere Teams an dem Service arbeiten, konnte die Migration von Spring MVC zu Spring Webflux nur in (stets mergebaren) Teilschritten erfolgen.

Einzige Option: Schrittweises Vorgehen

Hier unsere durchgeführten Schritte. Jeder Schritt wurde in einem Sprint umgesetzt, mit abschliessendem Merge auf den Master-Branch. Die ersten drei Schritte sind schon umgesetzt, der vierte eingeplant.

1. Umstellung aller verwendeten RestClient auf blockierende WebClients

Alle RestTemplates wurden durch WebClients ersetzt, die blockierend auf die Antwort warten. Dazu mussten alle ClientHttpRequestInterceptor in ExchangeFilterFunctions umgeschrieben werden. Zudem musste ein sog. ClientHttpConnector konfiguriert werden, der die Brücke zu der eigentlichen Http-Client-Implementierung bildet (z.B. Reactor-Netty oder Http-Commons HttpClient 5). Hier gab es einigen Aufwand, unsere angepasste Retry-Mechanik des vorherigen Http-Clients nachzubauen.

2. Verprobung eines kleinen reaktiven Controllers

Alle Klassen unterhalb eines kleinen Controllers werden reaktiven Code umgestellt. Der in der Aufrufhierarchie verwendete WebClient ist nun nicht mehr blockierend.

Damit die Schichten oberhalb der Controller-Klassen nicht angepasst werden müssen (Servlet-Filter, Spring Security, Spring MVC-Tests, Cloud Contract Tests), wurde im Controller selbst der reaktive Aufruf initiiert und mit einem expliziten block-Aufruf wieder eingefangen, so dass er weiterhin in das SpringMVC-Modell “passt”. Zudem mussten alle ThreadLocals bei einem Reactor- und WebClient-Threadwechsel kopiert werden. Erstes löst man mit der Registrierung eines sog. ScheduleHook mittels der statischen Schedulers#onScheduleHook Methode.

Schedulers.onScheduleHook("thread-local-compatibilty", threadLocalsCopyingHook);

Für den WebClient-Threadwechsel wurde der gleiche Kopiermechanismus in einer eigenen ExchangeFilterFunction realisiert.

3. Umstellung aller Controller auf (internen) reaktiven Code

Alle WebClients werden auf reaktiven Code umgestellt und RequestScoped-Beans entfernt. Wie beim ersten Verprobungs-Controller subscriben und blockieren alle Controller den reaktiven Aufruf selber, um die Kompatibilität mit aufrufenden Klassen aufrecht zu erhalten. Zudem wurden alle eigen gebauten CompletableFuture-Parallelisierungen entfernt. Für uns vorteilhaft war die bereits bestehende funktionale Architektur des Services (Kein Zustand, Objekte waren alle Immutable). Fachlicher Code musste kaum angefasst werden, mit Aussnahme des expliziten Durchreichens der Informationen aus eines abgebauten RequestScoped-Bean.

4. Letzter Schritt: Rückbau SpringMVC

Als letzten Schritt, der noch offen ist, sollen die reaktiven Typen (Mono oder Flux) in die Signatur der Controller-Methoden aufgenommen und der block-Aufruf entfernt werden. Zudem wird die Annotation @SpringBootTest durch @WebFluxTest ersetzt, sowie @EnableWebSecurity durch @EnableWebFluxSecurity.

Zusammenfassung

Eine Migration eines bestehenden Services von klassischem SpringMVC auf Spring Webflux ist mit einigem Aufwand verbunden, da alle Schichten betroffen sind und bestimmte Mechanismen (z.B. RequestScoped-Beans) nicht mehr funktionieren. Die Migration konnte in unserem Fall jedoch in Teilschritten und schichtweise erfolgen. Von Vorteil war die bereits die funktionale Architektur des Services (Immutable-Objects, keinen Zustand), so dass nur wenig fachlicher Code umgeschrieben werden musste. Wir versprechen uns davon einen deutlich ressourceneffizienteren WebService, den wir auch über auschliesslich über die CPU-Last skalieren können.