• d
• D
• . a
• v
• d
• +6

Wzorzec Bulkhead to typ projektu aplikacji, który jest tolerancyjny na awarie. W architekturze grodziowej elementy aplikacji są izolowane do puli, tak że jeśli jeden z nich ulegnie awarii, pozostałe będą nadal działać. Nazwa pochodzi od podzielonych na sekcje przegród (grodzi) w kadłubie statku. Jeśli kadłub statku jest uszkodzony, tylko uszkodzona sekcja wypełnia się wodą, co zapobiega zatonięciu statku.

Kontekst i problem

Aplikacja oparta na chmurze może zawierać wiele usług, z każdą usługą posiadającą jednego lub więcej konsumentów. Nadmierne obciążenie lub awaria w usłudze będzie miała wpływ na wszystkich konsumentów usługi.

Co więcej, konsument może wysyłać żądania do wielu usług jednocześnie, wykorzystując zasoby dla każdego żądania. Gdy konsument wysyła żądanie do usługi, która jest źle skonfigurowana lub nie odpowiada, zasoby używane przez żądanie klienta mogą nie zostać zwolnione w odpowiednim czasie. Ponieważ żądania do usługi są kontynuowane, zasoby te mogą zostać wyczerpane. Na przykład, pula połączeń klienta może zostać wyczerpana. W tym momencie wpływa to na żądania konsumenta do innych usług. Ostatecznie konsument nie może już wysyłać żądań do innych usług, a nie tylko do oryginalnej, niereagującej usługi.

Ten sam problem wyczerpania zasobów dotyka usług z wieloma konsumentami. Duża liczba żądań pochodzących od jednego klienta może wyczerpać dostępne zasoby w usłudze. Inni konsumenci nie są już w stanie konsumować usługi, powodując efekt kaskadowej awarii.

Rozwiązanie

Podziel instancje usługi na różne grupy, w oparciu o obciążenie konsumenta i wymagania dostępności. Ten projekt pomaga odizolować awarie i pozwala utrzymać funkcjonalność usługi dla niektórych konsumentów, nawet podczas awarii.

Konsument może również dzielić zasoby, aby zapewnić, że zasoby używane do wywoływania jednej usługi nie mają wpływu na zasoby używane do wywoływania innej usługi. Na przykład konsument, który wywołuje wiele usług, może mieć przypisaną pulę połączeń dla każdej usługi. Jeśli usługa zaczyna zawodzić, wpływa to tylko na pulę połączeń przypisaną do tej usługi, pozwalając konsumentowi na dalsze korzystanie z innych usług.

Korzyści z tego wzorca obejmują:

• Osolaryzuje konsumentów i usługi od kaskadowych awarii. Problem mający wpływ na konsumenta lub usługę może zostać odizolowany w obrębie jego własnej przegrody, zapobiegając awarii całego rozwiązania.
• Pozwala na zachowanie pewnej funkcjonalności w przypadku awarii usługi. Inne usługi i funkcje aplikacji będą nadal działać.
• Pozwala wdrożyć usługi, które oferują inną jakość usług dla aplikacji konsumujących. Pula konsumentów o wysokim priorytecie może być skonfigurowana do korzystania z usług o wysokim priorytecie.

Następujący diagram przedstawia grodzie zorganizowane wokół puli połączeń, które wywołują poszczególne usługi. Jeśli usługa A ulegnie awarii lub wystąpi jakiś inny problem, pula połączeń jest izolowana, więc dotyczy to tylko obciążeń roboczych korzystających z puli wątków przypisanej do usługi A. Obciążenia robocze korzystające z usług B i C nie są dotknięte i mogą kontynuować pracę bez zakłóceń.

Następny diagram przedstawia wielu klientów wywołujących pojedynczą usługę. Każdemu klientowi przypisana jest osobna instancja usługi. Klient 1 wykonał zbyt wiele żądań i przeciążył swoją instancję. Ponieważ każda instancja usługi jest odizolowana od pozostałych, pozostali klienci mogą kontynuować wykonywanie połączeń.

Problemy i rozważania

• Zdefiniuj partycje wokół wymagań biznesowych i technicznych aplikacji.
• Podczas partycjonowania usług lub konsumentów w grodzie należy rozważyć poziom izolacji oferowany przez technologię, a także koszty ogólne w zakresie kosztów, wydajności i możliwości zarządzania.
• Rozważ połączenie grodzi z wzorcami retry, circuit breaker i throttling w celu zapewnienia bardziej wyrafinowanej obsługi błędów.
• Podczas partycjonowania konsumentów w grodzie należy rozważyć użycie procesów, puli wątków i semaforów. Projekty takie jak resilience4j i Polly oferują ramy do tworzenia grodzi konsumenckich.
• Partycjonując usługi w grodzie, należy rozważyć rozmieszczenie ich w oddzielnych maszynach wirtualnych, kontenerach lub procesach. Kontenery oferują dobrą równowagę izolacji zasobów z dość niskim narzutem.
• Usługi, które komunikują się za pomocą asynchronicznych wiadomości mogą być izolowane poprzez różne zestawy kolejek. Każda kolejka może mieć dedykowany zestaw instancji przetwarzających wiadomości w kolejce, lub pojedynczą grupę instancji używających algorytmu do odliczania i wysyłania przetwarzania.
• Determinuj poziom granulacji dla przegród. Na przykład, jeśli chcesz rozdzielić lokatorów na partycje, możesz umieścić każdego lokatora w osobnej partycji lub umieścić kilku lokatorów w jednej partycji.
• Monitoruj wydajność każdej partycji i SLA.

Kiedy używać tego wzorca

Używaj tego wzorca do:

• Izolowania zasobów używanych do konsumowania zestawu usług backendu, zwłaszcza jeśli aplikacja może zapewnić pewien poziom funkcjonalności nawet wtedy, gdy jedna z usług nie odpowiada.
• Isolate critical consumers from standard consumers.
• Protect the application from cascading failures.

This pattern may not be suitable when:

• Less efficient use of resources may not be acceptable in the project.
• Dodatkowa złożoność nie jest konieczna

Przykład

Następujący plik konfiguracyjny Kubernetes tworzy izolowany kontener do uruchamiania pojedynczej usługi, z własnymi zasobami procesora i pamięci oraz limitami.

.