Lasttest für hochskalierbare Microservices-APIs

Microservices verandern die Ausfalloberflache. Ein Monolith unter Last wird langsamer; ein Service Mesh unter Last facht sich auf - ein langsamer Downstream-Aufruf blockiert die Worker-Threads stromaufwarts, Pools laufen leer, Retries stapeln sich, und eine einzelne Abhangigkeit reisst den Cluster mit sich. Dieses Template belastet Inter-Service-Hops so, wie Produktionsverkehr sie tatsachlich formt, nicht als isolierte Endpoint-Treffer.

Was wirklich getestet wird

Skripte rampen von der Baseline-RPS auf 2x und 5x Steady-State, halten jede Stufe 8-12 Minuten, damit sich Connection Pools, JVM/Go-Runtime-Allokationen und HPA-Entscheidungen einpendeln. Gemischte Payload-Grossen, echte Auth-Tokens pro Virtual User und verkettete Aufrufe - Gateway, Auth, zwei oder drei Downstream-Services, dann ein Write - die denselben Call-Graph belasten, den Ihre Traces in Produktion zeigen.

Ausfallmodi, die es zu erwischen lohnt

• Erschopfung des Connection Pools auf der Gateway- oder BFF-Schicht - HTTP-Keep-Alive-Limits werden vor der CPU erreicht. Beobachten Sie aktive Verbindungen, nicht nur CPU.
• Slow-Downstream-Kaskade - ein Service legt 400ms p95 drauf, und drei stromaufwartige Services fallen mit ihm uber die Klippe, weil ihre Per-Request-Timeouts 2s betragen, ihre Pool-Grosse aber 50 ist.
• Wiederholungssturme - gut gemeinter exponentieller Backoff ohne Jitter, der einen bereits degradierten Service im Gleichschritt trifft.
• Circuit-Breaker-Flapping - Half-Open-Probes feuern im selben Moment von jedem Replica los.
• gRPC-HTTP/2-Stream-Limits - `MAX_CONCURRENT_STREAMS` steht auf den meisten Servern per Default auf 100; ein High-RPS-REST-Client mit einer Verbindung pro Pod erreicht das nicht, ein gRPC-Client schon.

Latenzziele, die etwas bedeuten

Tracken Sie p50, p95, p99 pro Hop, nicht nur Ende-zu-Ende. Eine Einstiegslatte fur Ost-West-Traffic: p99 unter 50ms fur Cache-Reads, unter 150ms fur DB-gestutzte Reads, unter 300ms fur Inter-Service-Hops, die selbst weiter aufgefachert werden. Ein Ende-zu-Ende-p99 von 1s ist fur einen Checkout in Ordnung, der acht Services beruhrt; furchtbar fur einen Status-Endpoint, der einen beruhrt. Der Error-Budget-Burn zahlt mehr als die rohe Fehlerrate - 0,5% uber eine 5-Minuten-Spitze sind nicht dasselbe wie 0,5% dauerhaft.

Wie man es fahrt

Das Template gibt es in JMeter- und k6-Varianten. k6 passt besser zu HTTP/2, gRPC und gescripteten Request-Graphen; JMeter ist die sicherere Wahl, wenn Sie bereits eine JMX-Bibliothek haben, der Sie trauen. Fahren Sie aus LoadFocus uber mehrere der 26+ Cloud-Regionen, damit Cross-Region-Latenz in Ihren Zahlen auftaucht - Single-Region-Tests untertreiben Tail-Latency bei global verteilten Services systematisch.

Verdrahten Sie den Run in CI: Jenkins, Azure Pipelines oder CircleCI konnen einen Smoke-Scale-Run bei jedem Merge auf main triggern und einen Full-Scale-Run nachtlich. Brechen Sie den Build bei p99-Regression oder Error-Budget-Burn ab, nicht bei absoluten Schwellen - Absolute driften, Deltas lugen nicht.

Ergebnisse lesen

Echtzeit-Charts fangen das Offensichtliche - flacher Durchsatz bei steigender RPS bedeutet Sattigung stromaufwarts des Lastgenerators, Sagezahn-Latenz bedeutet GC oder Autoscaling. Die Arbeit nach dem Run besteht darin, Timings mit APM-Traces und Pod-Metriken zu korrelieren: Welcher Service hat sein p99 zuerst bewegt, was hat sein Pool-Depth gemacht, ist sein Downstream tatsachlich langsamer geworden oder hat er nur den schwarzen Peter bekommen.

Das Template, die Skripte und die Run-Historie leben in LoadFocus - klonen, Variablen auf Ihr Gateway zeigen, Concurrency setzen, laufen lassen.