Bulkhead
Ein Bulkhead ist ein Stabilitätsmuster in der Softwareentwicklung. Der Name leitet sich vom Schott (englisch: bulkhead) eines Schiffes ab.[1]
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 steht.[1]
Varianten
[Bearbeiten | Quelltext bearbeiten]Ressourcen pro Client
[Bearbeiten | Quelltext bearbeiten]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.[2]
Ressourcen pro Anwendung
[Bearbeiten | Quelltext bearbeiten]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.[2]
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
[Bearbeiten | Quelltext bearbeiten]Hier wird die Schnittstelle einer Anwendung feingranular nach Operationen geteilt und jeder Operation eine bestimmte Menge an Ressourcen bereitgestellt.[2] 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.[2]
Ressourcen pro Endpunkt
[Bearbeiten | Quelltext bearbeiten]Hier wird für jede Verbindung zu einer externen Ressource ein eigener Verbindungs-Pool oder Thread-Pool zur Verfügung gestellt.[2]
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
[Bearbeiten | Quelltext bearbeiten]Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ a b Michael T. Nygard: Release It! Design and Deploy Production-Ready Software. O’Reilly, 2007, ISBN 978-0-9787392-1-8 (englisch, 326 S.).
- ↑ a b c d e Gregor Roth: Stability patterns applied in a RESTful architecture. In: Java World. 13. Oktober 2014, abgerufen am 16. April 2017 (englisch).