Bulkheads pro Abhängigkeit halten unabhängige Endpunkte verfügbar, wenn eine Abhängigkeit stockt

Hypothese

Das (zitierte) Bulkhead-Pattern isoliert Elemente einer Anwendung in Pools, sodass die anderen weiterarbeiten, wenn ein Element ausfällt; Resilience4j (zitiert) implementiert es als Semaphore, das gleichzeitige Ausführungen begrenzt, oder als festen Thread-Pool mit begrenzter Warteschlange. Die Hypothese lautet, dass der Nutzen des Patterns beim Fall der langsamen Abhängigkeit grösser ist als beim Fall der toten Abhängigkeit: Eine Abhängigkeit, die gerade noch innerhalb des Client-Timeouts antwortet, hält einen Slot für die gesamte Timeout-Dauer belegt, und das lässt in einem gemeinsamen Pool Endpunkte verhungern, die sie nie aufrufen. Mit einem begrenzten Pool pro Abhängigkeit werden Aufrufe an die langsame Abhängigkeit schnell abgelehnt, sobald ihr Pool voll ist, und die übrigen Endpunkte sehen Latenz und Fehlerrate nahe an ihrem Normalwert.

Vorhersage

In einem Dienst mit den Endpunkten /a (ruft Abhängigkeit A auf) und /b (ruft Abhängigkeit B auf), die sich einen Pool der Grösse P teilen, wird das Einbringen einer Verzögerung in A knapp unterhalb des Client-Timeouts bei konstanter Open-Loop-Anfragerate die p99-Latenz und Fehlerrate von /b innerhalb weniger Timeout-Perioden auf das Niveau von /a anheben. Mit zwei Bulkheads der Grösse P/2 bleibt /b innerhalb seines Normalwerts, während /a schnelle Ablehnungen statt Timeouts zeigt. Der erfolgreiche Gesamtdurchsatz von /a unter normalen Bedingungen wird mit dem geteilten Pool niedriger sein – das ist der Preis der Isolation.

Vorgeschlagener Test

1. Den Dienst mit den zwei Endpunkten bauen, mit einem konfigurierbaren gemeinsamen Pool oder Semaphore-Bulkheads pro Abhängigkeit; die Timeouts in beiden Konfigurationen identisch halten.
2. Einen Fault-Injection-Proxy vor Abhängigkeit A schalten und eine Latenz von rund 90 Prozent des Client-Timeouts hinzufügen.
3. Beide Endpunkte mit einer festen Ankunftsrate (offenes Modell) über einen Zeitraum treiben, der ein Mehrfaches des Timeouts beträgt, einmal pro Konfiguration.
4. p50- und p99-Latenz, Fehlertyp (Timeout, Ablehnung) und Erfolgsrate pro Endpunkt über die Zeit erfassen.
5. Wiederholen, wobei A sofort Fehler zurückgibt statt zu stocken, um die Behauptung zu prüfen, dass der Unterschied zwischen den Konfigurationen in diesem Fall kleiner ist.

Status

Es wird kein Ergebnis behauptet. Der Effekt hängt davon ab, dass der Pool tatsächlich die knappe Ressource ist; ein vollständig asynchroner Dienst kann dasselbe Verhungern stattdessen über Verbindungslimits oder Event-Loop-Sättigung zeigen, und der Test sollte festhalten, welche Ressource erschöpft war.