Model Přepážka

Model Bulkhead je typ návrhu aplikace, který je tolerantní k selhání. V architektuře přepážek jsou prvky aplikace izolované do fondů, takže pokud jeden selže, ostatní budou i nadále fungovat. Je pojmenována podle rozdělených oddílů (přepážek) na lodi. Pokud dojde k poškození trupu lodi, naplní se vodou pouze poškozená část. Zabrání se tak potopení lodě.

Kontext a problém

Cloudová aplikace může obsahovat více služeb, přičemž každá služba může mít jednoho nebo více příjemců. Nadměrné zatížení nebo chyba služby ovlivní všechny příjemce služby.

Příjemce navíc může současně posílat požadavky různým službám a prostředky využívat pro každý požadavek. Pokud příjemce pošle požadavek službě, která je špatně nakonfigurovaná nebo neodpovídá, nemusí se prostředky používané požadavkem klienta uvolnit včas. Při přetrvávajících požadavcích na službu může dojít k vyčerpání těchto prostředků. Může třeba dojít k vyčerpání fondu připojení klienta. V tomto okamžiku jsou ovlivněny požadavky příjemce na jiné služby. Příjemce nakonec nebude moct posílat požadavky nejen původní nereagující službě, ale ani ostatním službám.

Stejný problém vyčerpání prostředků se týká služby s více příjemci. Velký počet požadavků pocházejících od jednoho klienta může vyčerpat dostupné prostředky ve službě. Ostatní příjemci už nebudou moct službu využívat, čímž dojde ke kaskádovému selhání.

Řešení

Rozdělte instance služby do různých skupin podle požadavků na zatížení příjemci a dostupnost. Tento návrh pomáhá izolovat chyby a umožňuje zachovat funkčnost služby pro některé příjemce i během selhání.

Příjemce může také rozdělit prostředky, aby zajistil, že prostředky používané k volání jedné služby nebudou mít vliv na prostředky používané k volání jiné služby. Příjemci, který volá více služeb, může být například pro každou službu přiřazen fond připojení. Pokud služba začne selhávat, bude to mít vliv pouze na fond připojení přiřazený dané službě a příjemce bude moct pokračovat v používání jiných služeb.

Mezi výhody tohoto modelu patří:

  • Izoluje uživatele a služby od kaskádových selhání. Problém ovlivňující uživatele nebo službu je možné izolovat v přepážce a zabránit tak selhání celého řešení.
  • V případě selhání služby umožňuje zachovat některé funkce. Ostatní služby a funkce aplikace budou dále fungovat.
  • Umožňuje nasadit služby, které nabízejí různou kvalitu služby pro přijímající aplikace. Fond příjemců s vysokou prioritou lze nakonfigurovat na používání služeb s vysokou prioritou.

Následující diagram znázorňuje přepážky strukturované kolem fondů připojení volajících jednotlivé služby. Pokud služba A selže nebo způsobí jiný problém, fond připojení se izoluje, aby byly zasaženy pouze úlohy používající fond vláken přiřazený službě A. Úlohy, které používají služby B a C, nejsou ovlivněny a mohou bez přerušení dále fungovat.

První diagram vzoru Bulkhead

Následující diagram znázorňuje více klientů volajících jednu službu. Každý klient je přiřazen samostatné instanci služby. Klient 1 poslal příliš mnoho požadavků a svou instanci zahltil. Vzhledem k tomu, že každá instance služby je izolovaná od ostatních, mohou další klienti pokračovat ve volání.

Diagram znázorňující více klientů volajících jednu službu

Problémy a důležité informace

  • Definujte oddíly kolem provozních a technických požadavků aplikace.
  • Při rozdělování služeb a příjemců do přepážek zvažte úroveň izolace, kterou nabízí technologie, a také režii z hlediska nákladů, výkonu a možností správy.
  • Zvažte zkombinování přepážek s modely opakování, jističe a omezení využití sítě za účelem sofistikovanějšího zpracování chyb.
  • Při rozdělování příjemců do přepážek zvažte použití procesů, fondů vláken a semaforů. Projekty jako resilience4j a Polly nabízejí rozhraní pro vytváření přepážek pro příjemce.
  • Při rozdělování služeb do přepážek zvažte jejich nasazení do samostatných virtuálních počítačů, kontejnerů nebo procesů. Kontejnery nabízejí dobrý poměr izolace prostředků a celkem nízkou režii.
  • Služby, které komunikují pomocí asynchronních zpráv, lze izolovat prostřednictvím různých sad front. Každá fronta může mít vyhrazenou sadu instancí zpracovávajících zprávy ve frontě nebo jednu skupinu instancí používající algoritmus pro odstranění z fronty nebo zpracování odeslání.
  • Určete úroveň podrobností pro přepážky. Pokud například chcete distribuovat tenanty mezi oddíly, můžete každého tenanta umístit do samostatného oddílu nebo umístit několik tenantů do jednoho oddílu.
  • Monitorujte výkon a SLA každého oddílu.

Kdy se má tento model použít

Tento model použijte k:

  • Izolování prostředků používaných pro sadu back-endových služeb, zejména v případě, kdy aplikace zvládne poskytovat určitou úroveň funkčnosti i přesto, že některá ze služeb nereaguje.
  • Izolování kritických příjemců od standardních příjemců
  • Ochraně aplikace před kaskádovými selháními

Tento model nebude pravděpodobně vhodný v následujících případech:

  • Méně efektivní použití prostředků nemusí být v projektu přijatelné.
  • Přidaná složitost není nutná.

Příklad

Následující konfigurační soubor Kubernetes vytvoří izolovaný kontejner pro spuštění jedné služby s vlastními prostředky procesoru a paměti a omezeními.

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"