Model Přepážka

Vzor Bulkhead je typ návrhu aplikace, který je odolný proti selhání. V architektuře přepážky, označované také jako architektura založená na buňkách, jsou prvky aplikace izolované do fondů, aby v případě selhání jedné aplikace fungovaly i ostatní. Jmenuje se podle oddílů (přepážek) trupu 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.

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í.

Problémy a důležité informace

• Definujte oddíly kolem provozních a technických požadavků aplikace.
• Pokud k návrhu mikroslužeb používáte taktické DDD, hranice oddílů by měly odpovídat ohraničeným kontextům.
• 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 je odolnost 4j a Polly , nabízejí architekturu pro vytváření přepážek uživatelů.
• 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 umístit každého tenanta do samostatného oddílu nebo vložit několik tenantů do jednoho oddílu.
• Monitorujte výkon a smlouvu SLA jednotlivých oddílů.

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á.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu Bulkhead v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

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"

Další kroky

• Návrh spolehlivých aplikací Azure

Související prostředky

• Model Jistič
• Model Opakování
• Model Omezení využití sítě