• 19/03/2020
• 4 minutter at læse
• • d
  • D
  • a
  • v
  • d
  • +6

Bulkhead-mønsteret er en type applikationsdesign, der er tolerant over for fejl. I en bulkhead-arkitektur er elementerne i en applikation isoleret i puljer, så hvis et af dem fejler, vil de andre fortsat fungere. Den er opkaldt efter de opdelte skillevægge (skotter) i et skibsskrog. Hvis skroget på et skib er beskadiget, er det kun den beskadigede sektion, der fyldes med vand, hvilket forhindrer skibet i at synke.

Kontekst og problem

En cloud-baseret applikation kan omfatte flere tjenester, hvor hver tjeneste har en eller flere forbrugere. Overdreven belastning eller fejl i en tjeneste vil påvirke alle forbrugere af tjenesten.

En forbruger kan desuden sende anmodninger til flere tjenester samtidig og bruge ressourcer til hver enkelt anmodning. Når forbrugeren sender en anmodning til en tjeneste, der er fejlkonfigureret eller ikke reagerer, kan det være, at de ressourcer, der anvendes af klientens anmodning, ikke frigøres i tide. Efterhånden som anmodningerne til tjenesten fortsætter, kan disse ressourcer blive opbrugt. F.eks. kan klientens forbindelsespulje blive opbrugt. På det tidspunkt påvirkes forbrugerens anmodninger til andre tjenester. Til sidst kan forbrugeren ikke længere sende anmodninger til andre tjenester, ikke kun til den oprindelige tjeneste, der ikke reagerer.

Det samme problem med ressourceudtømning påvirker tjenester med flere forbrugere. Et stort antal anmodninger, der stammer fra én kunde, kan opbruge de tilgængelige ressourcer i tjenesten. Andre forbrugere er ikke længere i stand til at forbruge tjenesten, hvilket medfører en kaskade af fejl.

Løsning

Partitioner tjenesteinstanser i forskellige grupper, baseret på forbrugerbelastning og tilgængelighedskrav. Dette design hjælper med at isolere fejl og giver dig mulighed for at opretholde tjenestefunktionaliteten for nogle forbrugere, selv under en fejl.

En forbruger kan også partitionere ressourcer for at sikre, at de ressourcer, der bruges til at kalde en tjeneste, ikke påvirker de ressourcer, der bruges til at kalde en anden tjeneste. En forbruger, der kalder flere tjenester, kan f.eks. få tildelt en forbindelsespulje for hver tjeneste. Hvis en tjeneste begynder at fejle, påvirker det kun den forbindelsespulje, der er tildelt til den pågældende tjeneste, så forbrugeren kan fortsætte med at bruge de andre tjenester.

Fordelene ved dette mønster omfatter:

• Isolerer forbrugere og tjenester fra kaskadefejl. Et problem, der påvirker en forbruger eller tjeneste, kan isoleres inden for sit eget skott, hvilket forhindrer hele løsningen i at fejle.
• Giver dig mulighed for at bevare en vis funktionalitet i tilfælde af en tjenestefejl. Andre tjenester og funktioner i programmet vil fortsat fungere.
• Giver dig mulighed for at implementere tjenester, der tilbyder en anden servicekvalitet for forbrugende programmer. En forbrugerpulje med høj prioritet kan konfigureres til at bruge tjenester med høj prioritet.

Det følgende diagram viser skotter, der er struktureret omkring forbindelsespuljer, der kalder individuelle tjenester. Hvis tjeneste A fejler eller forårsager et andet problem, er forbindelsespuljen isoleret, så kun arbejdsbelastninger, der bruger den trådpulje, der er tildelt tjeneste A, påvirkes. Arbejdsbelastninger, der bruger tjeneste B og C, påvirkes ikke og kan fortsætte arbejdet uden afbrydelse.

Det næste diagram viser flere klienter, der kalder en enkelt tjeneste. Hver klient er tildelt en separat tjenesteinstans. Klient 1 har foretaget for mange anmodninger og overbebyrdet sin instans. Fordi hver serviceinstans er isoleret fra de andre, kan de andre klienter fortsætte med at foretage opkald.

Spørgsmål og overvejelser

• Definér partitioner omkring de forretningsmæssige og tekniske krav til applikationen.
• Når du opdeler tjenester eller forbrugere i skotter, skal du overveje det isoleringsniveau, som teknologien tilbyder, samt overheadet med hensyn til omkostninger, ydeevne og håndterbarhed.
• Overvej at kombinere skotter med retry-, circuit breaker- og throttling-mønstre for at give en mere sofistikeret fejlhåndtering.
• Overvej at bruge processer, trådpuljer og semaforer, når du opdeler forbrugere i skotter. Projekter som resilience4j og Polly tilbyder en ramme til oprettelse af forbrugerskotter.
• Ved partitionering af tjenester i skotter bør du overveje at installere dem i separate virtuelle maskiner, containere eller processer. Containere tilbyder en god balance mellem ressourceisolering med ret lavt overhead.
• Tjenester, der kommunikerer ved hjælp af asynkrone meddelelser, kan isoleres gennem forskellige sæt køer. Hver kø kan have et dedikeret sæt af instanser, der behandler meddelelser i køen, eller en enkelt gruppe af instanser, der bruger en algoritme til at fjerne køen og fordele behandlingen.
• Det er muligt at bestemme granularitetsniveauet for skottene. Hvis du f.eks. ønsker at fordele lejere på tværs af partitioner, kan du placere hver enkelt lejer i en separat partition eller placere flere lejere i én partition.
• Overvågning af hver partitions ydeevne og SLA.

Hvornår skal du bruge dette mønster

Brug dette mønster til:

• Isolere ressourcer, der bruges til at forbruge et sæt backend-tjenester, især hvis programmet kan levere et vist funktionsniveau, selv når en af tjenesterne ikke reagerer.
• Isolere kritiske forbrugere fra standardforbrugere.
• Beskytte applikationen mod kaskadefejl.

Dette mønster er muligvis ikke egnet, når:

• Mindre effektiv udnyttelse af ressourcerne måske ikke er acceptabel i projektet.
• Den ekstra kompleksitet er ikke nødvendig

Eksempel

Den følgende Kubernetes-konfigurationsfil opretter en isoleret container til at køre en enkelt tjeneste, med dens egne CPU- og hukommelsesressourcer og begrænsninger.