• 03/19/2020
• 4 minuter att läsa
• • d
  • D
  • a
  • v
  • d
  • +6

Bulkheadmönstret är en typ av applikationsdesign som är tolerant mot fel. I en skottarkitektur är delar av ett program isolerade i pooler så att om en av dem går sönder fortsätter de andra att fungera. Det är uppkallat efter de sektionerade partitioner (skott) som finns i ett fartygsskrov. Om ett fartygs skrov skadas fylls endast den skadade sektionen med vatten, vilket förhindrar att fartyget sjunker.

Kontext och problem

En molnbaserad applikation kan innehålla flera tjänster, där varje tjänst har en eller flera konsumenter. Överbelastning eller fel i en tjänst påverkar alla konsumenter av tjänsten.

En konsument kan dessutom skicka förfrågningar till flera tjänster samtidigt och använda resurser för varje förfrågan. När konsumenten skickar en begäran till en tjänst som är felkonfigurerad eller inte svarar, kan det hända att de resurser som används av kundens begäran inte frigörs i tid. När förfrågningar till tjänsten fortsätter kan resurserna ta slut. Klientens anslutningspool kan till exempel vara uttömd. Då påverkas konsumentens förfrågningar till andra tjänster. Så småningom kan konsumenten inte längre skicka förfrågningar till andra tjänster, inte bara till den ursprungliga tjänsten som inte svarar.

Samma problem med resursutnyttjande påverkar tjänster med flera konsumenter. Ett stort antal förfrågningar som kommer från en kund kan uttömma tillgängliga resurser i tjänsten. Andra konsumenter kan inte längre konsumera tjänsten, vilket orsakar en kaskadfelseffekt.

Lösning

Partitionera tjänsteinstanser i olika grupper, baserat på konsumentbelastning och tillgänglighetskrav. Den här konstruktionen hjälper till att isolera fel och gör det möjligt att upprätthålla tjänstens funktionalitet för vissa konsumenter även under ett fel.

En konsument kan också dela upp resurser för att se till att de resurser som används för att anropa en tjänst inte påverkar de resurser som används för att anropa en annan tjänst. En konsument som anropar flera tjänster kan till exempel tilldelas en anslutningspool för varje tjänst. Om en tjänst börjar gå sönder påverkar det endast den anslutningspool som tilldelats för den tjänsten, vilket gör att konsumenten kan fortsätta använda de andra tjänsterna.

Fördelarna med det här mönstret är bland annat:

• Insolerar konsumenter och tjänster från kaskadfel. Ett problem som påverkar en konsument eller tjänst kan isoleras inom sitt eget skott, vilket förhindrar att hela lösningen misslyckas.
• Det gör det möjligt att bevara viss funktionalitet i händelse av ett tjänstefel. Andra tjänster och funktioner i applikationen fortsätter att fungera.
• Gör det möjligt att distribuera tjänster som erbjuder en annan tjänstekvalitet för konsumerande applikationer. En konsumentpool med hög prioritet kan konfigureras för att använda tjänster med hög prioritet.

Följande diagram visar skott som är strukturerade kring anslutningspooler som anropar enskilda tjänster. Om tjänst A misslyckas eller orsakar något annat problem är anslutningspoolen isolerad, så att endast arbetsbelastningar som använder den trådpool som tilldelats tjänst A påverkas. Arbetsbelastningar som använder tjänst B och C påverkas inte och kan fortsätta arbeta utan avbrott.

Nästa diagram visar flera klienter som anropar en enda tjänst. Varje klient tilldelas en separat tjänstinstans. Klient 1 har gjort för många förfrågningar och överbelastat sin instans. Eftersom varje tjänsteinstans är isolerad från de andra kan de andra klienterna fortsätta att göra anrop.

Saker och överväganden

• Definiera partitioner kring applikationens affärsmässiga och tekniska krav.
• När du partitionerar tjänster eller konsumenter i skott, ta hänsyn till den isoleringsnivå som tekniken erbjuder samt till överskottet i fråga om kostnad, prestanda och hanterbarhet.
• Överväg att kombinera skott med retry-, brytar- och strypningsmönster för att ge en mer sofistikerad felhantering.
• När du partitionerar konsumenter i skott, överväg att använda processer, trådpooler och semaforer. Projekt som resilience4j och Polly erbjuder ett ramverk för att skapa konsumentskotten.
• När du delar upp tjänster i skotten kan du överväga att distribuera dem i separata virtuella maskiner, behållare eller processer. Containers erbjuder en bra balans av resursisolering med ganska låg overhead.
• Tjänster som kommunicerar med hjälp av asynkrona meddelanden kan isoleras genom olika uppsättningar av köer. Varje kö kan ha en särskild uppsättning instanser som behandlar meddelanden i kön, eller en enda grupp instanser som använder en algoritm för att ta bort köer och fördela bearbetningen.
• Detektera granularitetsnivån för skotten. Om du till exempel vill fördela hyresgäster över partitioner kan du placera varje hyresgäst i en separat partition eller placera flera hyresgäster i en partition.
• Övervaka varje partitions prestanda och SLA.

När du ska använda det här mönstret

Använd det här mönstret för att:

• Isolera resurser som används för att konsumera en uppsättning backend-tjänster, särskilt om applikationen kan tillhandahålla en viss nivå av funktionalitet även när en av tjänsterna inte svarar.
• Isolera kritiska konsumenter från standardkonsumenter.
• Skydda applikationen från kaskadfel.

Detta mönster är kanske inte lämpligt när:

• Mindre effektiv användning av resurser kanske inte är acceptabelt i projektet.
• Den extra komplexiteten är inte nödvändig

Exempel

Följande Kubernetes-konfigurationsfil skapar en isolerad behållare för att köra en enda tjänst, med egna CPU- och minnesresurser och begränsningar.