Canary-Deployments mit Java: sicherer Deployment ohne Angst

Canary-Deployments mit Java: Neue Versionen risikofrei für die Produktion ausrollen

Stellen Sie sich vor: Sie sind der Kapitän eines U-Boots. Sie müssen ein neues Sonar testen, aber Sie können es nicht einfach auf voller Leistung einschalten – was, wenn es die gesamte Crew blendet oder, schlimmer noch, einen Fehlalarm auslöst? Was tun Sie? Sie setzen einen Kanarienvogel ein (das Vögelchen, das früher Bergleute vor Gaslecks warnte). Wenn der Vogel lebt, ist das System in Ordnung.

In der Welt der Java-Entwicklung nennt man dieses Prinzip Canary-Deployments. Es ist eine Strategie, bei der eine neue Version einer Anwendung zunächst an einen kleinen Prozentsatz der Benutzer ausgeliefert wird (normalerweise 1–5 %). Läuft alles gut, wird der Traffic schrittweise erhöht. Wenn nicht, wird ohne Katastrophe zurückgerollt.

In diesem Artikel zeigen wir Ihnen anhand praktischer Beispiele, wie Sie Canary-Deployments in Java umsetzen: von einfachen Konfigurationen bis hin zu fortgeschrittenen Techniken mit Kubernetes und Spring Cloud. Los geht's!

Warum Canary und nicht Blue-Green oder Rolling Update?

Vergleichen wir kurz drei gängige Deployment-Strategien:

\n
• Blue-Green: Sie haben zwei identische Umgebungen (blau und grün). Sie schalten den gesamten Traffic auf einmal um. Schnell, aber wenn ein Bug auftaucht, sind alle betroffen.
\n
• Rolling Update: Sie aktualisieren Pods/Server nacheinander. Langsamer, aber ebenfalls massenhaft.
\n
• Canary: Sie leiten die neue Version nur an 2 % der Benutzer weiter. Wenn diese sich nicht beschweren, erhöhen Sie auf 10 %, dann auf 50 %, dann auf 100 %.
\n

Canary ist die einzige Strategie, die es Ihnen ermöglicht, eine neue Version A/B zu testen – mit echten Benutzern, ohne Risiko für alle. Dies ist besonders kritisch für Java-Microservices, bei denen ein einziger Fehler einen Kaskadeneffekt auslösen kann.

Wie funktioniert das in Java? Technische Architektur

Stellen wir uns ein typisches Java-System vor: eine Spring-Boot-Anwendung, die eine REST-API bereitstellt. Um Canary zu implementieren, benötigen wir:

\n
1. Traffic-Routing: Ein Teil der Anfragen wird an die neue Version (v2) geleitet, der Rest an die alte (v1).
\n
2. Metriken und Monitoring: Erfassen von Fehlern, Latenzen und Anfrageanzahl.
\n
3. Automatischer Rollback: Wenn die Fehlerquote einen Schwellenwert überschreitet, wird der Canary zurückgesetzt.
\n
4. Schrittweise Erhöhung: Wenn alles in Ordnung ist, wird das Gewicht des Canary erhöht.
\n

Der einfachste Weg, dies zu tun, ist die Verwendung von Kubernetes mit Service Mesh (z. B. Istio) oder Spring Cloud Gateway mit Routing-Gewichten. Nachfolgend finden Sie Beispiele für beide Ansätze.

Beispiel 1: Canary mit Spring Cloud Gateway (ohne Kubernetes)

Wenn Sie kein Kubernetes, aber Spring Cloud haben, können Sie Spring Cloud Gateway mit einer Gewichtskonfiguration verwenden. So sieht das aus:

// application.yml\nspring:\n  cloud:\n    gateway:\n      routes:\n        - id: my-app-canary\n          uri: http://my-app-v2:8080\n          predicates:\n            - Weight=my-app, 10   # 10 % Traffic\n          filters:\n            - SetPath=/api/v2/**\n        - id: my-app-stable\n          uri: http://my-app-v1:8080\n          predicates:\n            - Weight=my-app, 90   # 90 % Traffic\n          filters:\n            - SetPath=/api/v1/**\n

Hier verwenden wir das Prädikat Weight – eine integrierte Funktion von Spring Cloud Gateway. Es verteilt Anfragen zufällig im Verhältnis 10/90. Wenn v2 stabil läuft, ändern wir das Gewicht auf 50/50, dann auf 100/0.

Vorteile: Einfach, keine externen Tools erforderlich.
\nNachteile: Keine Automatisierung – Gewichte werden manuell oder über eine API geändert.

Beispiel 2: Canary mit Kubernetes und Istio (fortgeschritten)

Dies ist der Goldstandard für Java-Microservices. Wir verwenden Istio VirtualService