Bulkhead

Ein Bulkhead ist ein Stabilitätsmuster in der Softwareentwicklung. Der Name leitet sich vom Schott (englisch: ) eines Schiffes ab.<ref name="releaseit" />

Beim Bulkhead wird ein Softwaresystem in mehrere Teilsysteme unterteilt, sodass wenn eines der Teilsysteme von einem Klienten überlastet wird, die anderen Teilsysteme für die anderen Klienten weiterhin zur Verfügung stehen.<ref name="releaseit" />

Varianten

Ressourcen pro Client

Hier wird für jede Clientanwendung ein eigener Cluster der Anwendung bereitgestellt. Fällt einer der Cluster aus, so entfällt zwar die Funktionalität der abhängigen Clientanwendung, andere Clientanwendungen funktionieren jedoch weiterhin.<ref name="jworld" />

Ressourcen pro Anwendung

Bei dieser Variante wird ein Softwaresystem nach dem Verwendungszweck aufgeteilt und jedem dieser Teilsysteme eine bestimmte Menge an Ressourcen (Rechenzeit, Speicher, Bandbreite etc.) durch ein Container-Verwaltungssystem zur Verfügung gestellt.<ref name="jworld" />

Beispielsweise kann ein Zahlungssystem in ein Kreditkarten-Abbuchungssystem und ein Kontoüberweisungssystem aufgeteilt und in getrennten Containern gehostet werden. Fällt eines der Teilsysteme aufgrund einer Überlastung aus, so können Zahlungen weiterhin mit dem jeweils anderen Teilsystem durchgeführt werden.

Ressourcen pro Operation

Hier wird die Schnittstelle einer Anwendung feingranular nach Operationen geteilt und jeder Operation eine bestimmte Menge an Ressourcen bereitgestellt.<ref name="jworld" /> Diese Variante eignet sich besonders für Fassaden und Portale, welche mehrere Systeme im Hintergrund ansprechen.

Steht beispielsweise die Methode payByCreditCard() einer API, etwa aufgrund einer Überlastung oder des Ausfalls des dahinter liegenden Kreditkartensystems, nicht zur Verfügung, kann dennoch die Operation payByWireTransfer() aufgerufen werden.

Um eine derart feingranulare Aufteilung innerhalb einer Anwendung zu ermöglichen, werden eigene Frameworks wie Hystrix eingesetzt.<ref name="jworld" />

Ressourcen pro Endpunkt

Hier wird für jede Verbindung zu einer externen Ressource ein eigener Verbindungs-Pool oder Thread-Pool zur Verfügung gestellt.<ref name="jworld" />

Hierbei muss jedoch beachtet werden, dass beim Ausfall einer Ressource nicht immer ein Fallback erfolgen sollte. Fällt etwa ein Caching-System aus, so würde ein Fallback auf die Datenbank zu einer Überlastung derselben führen und somit einen Kaskadenfehler erzeugen.

Siehe auch

• Sicherung (Entwurfsmuster)
• Durchsatzratenbegrenzung

Einzelnachweise

<references> <ref name="releaseit"> </ref> <ref name="jworld"> Gregor Roth: Stability patterns applied in a RESTful architecture. In: Java World. 13. Oktober 2014, abgerufen am 16. April 2017 ().  </ref> </references>