Vzor přepážky

Vzor Bulkhead je typ návrhu aplikace, který je odolný proti selhání. V architektuře bulkhead, označované také jako architektura založená na buňkách, jsou prvky aplikace izolované do fondů, takže pokud jeden selže, ostatní prvky budou dál fungovat. Vzor Bulkhead se jmenuje 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 a každá služba má jednoho nebo více příjemců. Nadměrné zatížení nebo selhání ve službě ovlivňuje všechny uživatele služby.

Příjemce může také posílat žádosti více službám současně a používat prostředky pro každou žádost. Když příjemce odešle požadavek na chybně nakonfigurovanou nebo nereagující službu, můžou prostředky, které žádost klienta používá, po delší dobu zůstat nedostupné. Vzhledem k tomu, že požadavky na službu budou pokračovat, můžou se tyto prostředky vyčerpat. Například fond připojení klienta může být vyčerpán. V tomto okamžiku jsou ovlivněny požadavky spotřebitele na jiné služby. Příjemce nakonec nemůže odesílat požadavky na žádné jiné služby, nejen do původní nereagující služby.

Vyčerpání prostředků má vliv na služby, které mají více příjemců. Mnoho požadavků z jednoho klienta může vyčerpat dostupné prostředky ve službě. Vyčerpání prostředků může znamenat, že ostatní příjemci nemůžou službu využívat, což způsobuje kaskádový efekt selhání.

Řešení

Rozdělte instance služby do různých skupin na základě požadavků na zatížení a dostupnost příjemce. Tento návrh pomáhá izolovat selhání. U některých uživatelů můžete udržovat funkčnost služby, i když dojde k selhání.

Příjemce může také rozdělit prostředky, aby zajistil, že prostředky používané k volání jedné služby nemají 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 přiřazen fond připojení pro každou službu. Pokud služba začne selhávat, ovlivní pouze fond připojení přiřazený pro tuto službu. Spotřebitel může dál používat jiné služby.

Tento model má následující výhody:

  • Izoluje uživatele a služby od kaskádových selhání. Problém, který ovlivňuje spotřebitele nebo službu, je možné izolovat v rámci vlastní přepážky, aby se zabránilo selhání celého řešení.

  • Zachová některé funkce, pokud dojde k selhání služby. Další služby a funkce aplikace nadále fungují.

  • Poskytuje různé úrovně služeb pro využívání aplikací. Fond příjemců s vysokou prioritou můžete nakonfigurovat tak, aby používal služby s vysokou prioritou.

Následující diagram znázorňuje přepážky strukturované kolem poolů připojení, které volají jednotlivé služby. Pokud služba A selže nebo způsobí problém, fond připojení je izolovaný, takže se to týká jenom úloh, které používají fond vláken přiřazený službě A. Úlohy, které používají službu B a C, nejsou ovlivněné a můžou bez přerušení pokračovat v práci.

Diagram znázorňující přepážky strukturované kolem fondů připojení, které volají jednotlivé služby

Následující diagram znázorňuje více klientů, kteří volají jednu službu. Každému klientovi je přiřazena samostatná instance služby. Klient 1 provádí příliš mnoho požadavků a zatěžuje svou instanci. Vzhledem k tomu, že každá instance služby je izolovaná od ostatních, můžou ostatní klienti dál volat.

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

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

  • Definujte oddíly kolem provozních a technických požadavků aplikace.

  • Pokud k návrhu mikroslužeb používáte taktický návrh řízený doménou, hranice oddílů by měly odpovídat ohraničeným kontextům.

  • Když rozdělíte služby nebo uživatele do přepážek, zvažte úroveň izolace, kterou technologie nabízí, a režijní náklady z hlediska nákladů, výkonu a možností správy.

  • Pokud chcete zajistit sofistikovanější zpracování chyb, zvažte zkombinování přepážek s vzory opakování, vzory jističů a omezovacími vzory.

  • Při rozdělování zákazníků do přepážek zvažte použití procesů, fondů vláken a semaforů. Projekty, jako resilience4j a Polly, nabízejí rámec pro vytváření oddělení spotřebitelů.

  • Při rozdělování služeb do oddílů zvažte jejich nasazení do samostatných virtuálních strojů, 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, je možné izolovat prostřednictvím různých sad front. Každá fronta může mít vyhrazenou sadu instancí, které zpracovávají zprávy ve frontě nebo jednu skupinu instancí, které používají algoritmus k vyřazení z fronty a zpracování odeslání.

  • Určete úroveň granularity 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 vložit několik tenantů do jednoho oddílu.

  • Monitorujte výkon jednotlivých oddělení a dohodu o úrovni služeb (SLA).

  • Používejte integrované ovládací prvky platformy, jako jsou omezení rychlosti služby Azure API Management, izolace jednotek žádostí služby Azure Cosmos DB (RU) a limity prostředků ve službě Azure Kubernetes Service (AKS) nebo Azure Container Apps. Tyto mechanismy omezování a izolace v kódu aplikace nevytvořte znovu.

  • Úlohy umělé inteligence a inferenční úlohy často vyžadují striktní oddělovací přepážky kvůli kvótám na úrovni nasazení a limitům souběžnosti, například izolaci nasazení Azure OpenAI dle úlohy nebo tenanta.

Kdy použít tento vzor

Tento model použijte v těchto případech:

  • Chcete izolovat prostředky pro konkrétní závislosti, aby přerušení v jedné službě nemělo vliv na celou aplikaci.
  • Chcete izolovat kritické spotřebitele od standardních příjemců.
  • Potřebujete chránit aplikaci před kaskádovanými chybami.

Tento vzor nemusí být vhodný v těchto případech:

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

Návrh úloh

Vyhodnoťte, jak použít model Bulkhead v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu. Strategie izolace selhání zavedená prostřednictvím úmyslné a úplné segmentace mezi komponentami se pokouší obsahovat chyby v přepážce, která se týká problému, což brání dopadu na jiné přepážky.

- RE:02 Kritické toky
- RE:07 Sebezáchování
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. Segmentace mezi komponentami pomáhá omezit bezpečnostní incidenty na kompromitovanou přepážku.

- SE:04 Segmentace
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. Každá přepážka může být samostatně škálovatelná, aby efektivně naplňovala požadavky úkolu zapouzdřeného v přepážce.

- PE:02 Plánování kapacity
- PE:05 Škálování a dělení

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

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

  • Last updated on