• 03/19/2020
• 4 minute de citit
• • d
  • D
  • . a
  • v
  • d
  • +6

Patronul Bulkhead este un tip de proiectare de aplicații care este tolerant la eșecuri. Într-o arhitectură bulkhead, elementele unei aplicații sunt izolate în grupuri, astfel încât, dacă unul dintre ele eșuează, celelalte vor continua să funcționeze. Este denumit după partițiile secționate (bulkheads) ale corpului unei nave. Dacă fuzelajul unei nave este compromis, numai secțiunea deteriorată se umple cu apă, ceea ce împiedică nava să se scufunde.

Context și problemă

O aplicație bazată pe cloud poate include mai multe servicii, fiecare serviciu având unul sau mai mulți consumatori. Încărcarea excesivă sau eșecul unui serviciu va avea un impact asupra tuturor consumatorilor serviciului respectiv.

În plus, un consumator poate trimite cereri către mai multe servicii simultan, utilizând resurse pentru fiecare cerere. Atunci când consumatorul trimite o cerere către un serviciu care este configurat greșit sau care nu răspunde, este posibil ca resursele utilizate de cererea clientului să nu fie eliberate în timp util. Pe măsură ce cererile către serviciu continuă, resursele respective pot fi epuizate. De exemplu, este posibil ca pool-ul de conexiuni al clientului să fie epuizat. În acel moment, solicitările consumatorului către alte servicii sunt afectate. În cele din urmă, consumatorul nu mai poate trimite cereri către alte servicii, nu doar către serviciul inițial care nu răspunde.

Aceeași problemă a epuizării resurselor afectează serviciile cu consumatori multipli. Un număr mare de cereri provenind de la un client poate epuiza resursele disponibile în serviciu. Alți consumatori nu mai sunt capabili să consume serviciul, provocând un efect de eșec în cascadă.

Soluție

Partajarea instanțelor de servicii în grupuri diferite, pe baza cerințelor de încărcare și disponibilitate ale consumatorilor. Acest design ajută la izolarea defecțiunilor și vă permite să mențineți funcționalitatea serviciului pentru unii consumatori, chiar și în timpul unei defecțiuni.

Un consumator poate, de asemenea, să partiționeze resursele, pentru a se asigura că resursele utilizate pentru a apela un serviciu nu afectează resursele utilizate pentru a apela un alt serviciu. De exemplu, unui consumator care apelează mai multe servicii i se poate atribui un pool de conexiuni pentru fiecare serviciu. Dacă un serviciu începe să eșueze, aceasta afectează doar pool-ul de conexiuni atribuit pentru acel serviciu, permițând consumatorului să continue să utilizeze celelalte servicii.

Beneficiile acestui model includ:

• Izolează consumatorii și serviciile de eșecurile în cascadă. O problemă care afectează un consumator sau un serviciu poate fi izolată în cadrul propriului său bulkhead, împiedicând întreaga soluție să eșueze.
• Vă permite să păstrați o anumită funcționalitate în cazul în care un serviciu eșuează. Alte servicii și caracteristici ale aplicației vor continua să funcționeze.
• Vă permite să implementați servicii care oferă o calitate diferită a serviciilor pentru aplicațiile consumatoare. Un pool de consumatori cu prioritate ridicată poate fi configurat pentru a utiliza servicii cu prioritate ridicată.

Diagrama următoare prezintă bulkheads structurate în jurul pool-urilor de conexiuni care apelează servicii individuale. Dacă serviciul A eșuează sau cauzează o altă problemă, pool-ul de conexiuni este izolat, astfel încât numai sarcinile de lucru care utilizează pool-ul de fire atribuit serviciului A sunt afectate. Sarcinile de lucru care utilizează Serviciul B și C nu sunt afectate și pot continua să lucreze fără întrerupere.

Diagrama următoare prezintă mai mulți clienți care apelează un singur serviciu. Fiecărui client i se atribuie o instanță de serviciu separată. Clientul 1 a făcut prea multe cereri și a copleșit instanța sa. Deoarece fiecare instanță de serviciu este izolată de celelalte, ceilalți clienți pot continua să facă apeluri.

Probleme și considerații

• Definiți partițiile în jurul cerințelor tehnice și de afaceri ale aplicației.
• Când partiționați serviciile sau consumatorii în bulkheads, luați în considerare nivelul de izolare oferit de tehnologie, precum și costurile suplimentare în ceea ce privește costul, performanța și capacitatea de gestionare.
• Considerați combinarea bulkheads cu modele de reluare, întrerupător de circuit și de limitare pentru a oferi o gestionare mai sofisticată a defecțiunilor.
• Când partiționați consumatorii în bulkheads, luați în considerare utilizarea proceselor, a grupurilor de fire și a semafoarelor. Proiecte precum resilience4j și Polly oferă un cadru pentru crearea de bulkheads de consumatori.
• Când partiționați serviciile în bulkheads, luați în considerare implementarea lor în mașini virtuale, containere sau procese separate. Containerele oferă un echilibru bun de izolare a resurselor cu o suprasolicitare destul de redusă.
• Serviciile care comunică folosind mesaje asincrone pot fi izolate prin seturi diferite de cozi. Fiecare coadă poate avea un set dedicat de instanțe care procesează mesajele de pe coadă, sau un singur grup de instanțe care utilizează un algoritm pentru a scoate din coadă și a repartiza procesarea.
• Determinați nivelul de granularitate pentru pereții de compartimentare. De exemplu, dacă doriți să distribuiți chiriașii pe partiții, puteți plasa fiecare chiriaș într-o partiție separată sau puteți plasa mai mulți chiriași într-o singură partiție.
• Monitorizați performanța și SLA-ul fiecărei partiții.

Când să utilizați acest model

Utilizați acest model pentru:

• Izolați resursele utilizate pentru a consuma un set de servicii backend, în special dacă aplicația poate furniza un anumit nivel de funcționalitate chiar și atunci când unul dintre servicii nu răspunde.
• Izolați consumatorii critici de consumatorii standard.
• Protejați aplicația de defecțiuni în cascadă.

Acest model poate să nu fie adecvat atunci când:

• Utilizarea mai puțin eficientă a resurselor poate să nu fie acceptabilă în cadrul proiectului.
• Complexitatea suplimentară nu este necesară

Exemplu

Următorul fișier de configurare Kubernetes creează un container izolat pentru a rula un singur serviciu, cu propriile resurse și limite de CPU și de memorie.

.