Spring-Boot-Cloud-API-Gateway, bereitgestellt in Kubernetes und skaliert auf mehrere Pods ⇐ Java

[Anonymous]

Es gibt eine Architektur, in der das Spring Boot Cloud API Gateway als Einstiegspunkt zum gesamten System fungiert. Da es als Einstiegspunkt verwendet wird, verarbeitet es alle eingehenden Anfragen und muss irgendwann skaliert werden. Alle Systemkomponenten, einschließlich des API Gateways, werden in Kubernetes bereitgestellt. Und im aktuellen Setup übernimmt das Spring Boot Cloud-API-Gateway die Sitzungskennung aus dem Cookie. Dieses Sitzungscookie wird auf der API-Gateway-Seite verwendet, um das zugehörige JWT-Token abzubilden, bevor eine Anfrage an die nachgelagerten Mikrodienste gesendet wird. Dieses Setup funktioniert aufgrund der zustandsbehafteten Sitzung mit einem Cookie nicht, wenn mehr als eine Instanz von API Gateway vorhanden ist. Könnten Sie uns bitte mitteilen, wie dieses Problem gelöst werden kann? Ich kann hier einige Anweisungen sehen, bin mir aber nicht sicher, welche ich wählen soll und wie ich sie umsetzen soll:

• Stellen Sie das API-Gateway so um, dass es ein JWT-Token im Autorisierungsheader anstelle eines Cookies verwendet, sodass das API-Gateway nach erfolgreicher Authentifizierung ein JWT-Token an den Client sendet und der Client es speichert und bei jeder Anfrage sendet (der Client ist auch für die Aktualisierungslogik des Zugriffstokens verantwortlich).
• Erstellen Sie eine Sticky-Sitzung zwischen dem Client (Browser) und API-Gateway (Kubernetes-Pod), sodass der Browser immer zu dem spezifischen Pod wechselt, in dem der Server die Zuordnung zwischen dem übergebenen Cookie und dem im Pod als Teil der JVM gespeicherten JWT-Token durchführen kann.

Bitte helfen Sie bei der Auswahl der Option und schlagen Sie vor, wie Sie diese erreichen können.