• 03/19/2020
• 4 perc olvasás
• • d
  • D
  • D
  • a
  • v
  • d
  • +6

A Bulkhead minta a hibatűrő alkalmazástervezés egyik típusa. A bulkhead architektúrában az alkalmazás elemei poolokba vannak elkülönítve, így ha az egyik meghibásodik, a többi továbbra is működik. Nevét egy hajótest szekcionált válaszfalai (bulkheadek) után kapta. Ha a hajótest sérül, csak a sérült rész töltődik meg vízzel, ami megakadályozza, hogy a hajó elsüllyedjen.

Kontextus és probléma

A felhőalapú alkalmazás több szolgáltatást is tartalmazhat, és minden szolgáltatásnak egy vagy több fogyasztója van. Egy szolgáltatás túlzott terhelése vagy meghibásodása a szolgáltatás összes fogyasztójára hatással van.

Ezeken túlmenően egy fogyasztó egyszerre több szolgáltatáshoz is küldhet kéréseket, minden egyes kéréshez erőforrásokat használva. Ha a fogyasztó olyan szolgáltatáshoz küld kérést, amely rosszul van konfigurálva vagy nem válaszol, előfordulhat, hogy az ügyfél kérése által használt erőforrások nem szabadulnak fel időben. Ahogy a szolgáltatáshoz intézett kérések folytatódnak, ezek az erőforrások kimerülhetnek. Például az ügyfél kapcsolatkészlete kimerülhet. Ekkor a fogyasztó más szolgáltatásokhoz intézett kérései is érintettek. Végül a fogyasztó nem tud többé kéréseket küldeni más szolgáltatásoknak, nem csak az eredetileg nem reagáló szolgáltatásnak.

Az erőforrások kimerülésének ugyanez a problémája érinti a több fogyasztóval rendelkező szolgáltatásokat is. Az egy ügyféltől származó nagyszámú kérés kimerítheti a szolgáltatásban rendelkezésre álló erőforrásokat. A többi fogyasztó már nem képes fogyasztani a szolgáltatást, ami kaszkádszerű hibahatást okoz.

megoldás

A szolgáltatáspéldányokat a fogyasztói terhelés és a rendelkezésre állási követelmények alapján különböző csoportokra osztjuk. Ez a kialakítás segít a hibák elszigetelésében, és lehetővé teszi, hogy a szolgáltatás funkcionalitása egyes fogyasztók számára még a hiba során is fennmaradjon.

A fogyasztó az erőforrásokat is feloszthatja, hogy az egyik szolgáltatás hívásához használt erőforrások ne befolyásolják a másik szolgáltatás hívásához használt erőforrásokat. Például egy olyan fogyasztó, amely több szolgáltatást hív, minden egyes szolgáltatáshoz rendelhet egy kapcsolati készletet. Ha egy szolgáltatás meghibásodik, az csak az adott szolgáltatáshoz rendelt kapcsolati készletet érinti, így a fogyasztó továbbra is használhatja a többi szolgáltatást.

Ez a minta a következő előnyökkel jár:

• Elszigeteli a fogyasztókat és a szolgáltatásokat a kaszkádszerű hibáktól. Egy fogyasztót vagy szolgáltatást érintő probléma elszigetelhető a saját válaszfalán belül, megakadályozva ezzel az egész megoldás meghibásodását.
• Megőrzi bizonyos funkciók megőrzését a szolgáltatás meghibásodása esetén. Az alkalmazás egyéb szolgáltatásai és funkciói továbbra is működnek.
• Elérhetővé teszi olyan szolgáltatások telepítését, amelyek eltérő szolgáltatásminőséget kínálnak a fogyasztó alkalmazások számára. A magas prioritású fogyasztói pool úgy konfigurálható, hogy magas prioritású szolgáltatásokat használjon.

A következő ábra az egyes szolgáltatásokat hívó kapcsolati poolok köré felépített válaszfalakat mutatja. Ha az A szolgáltatás meghibásodik vagy valamilyen más problémát okoz, a kapcsolati pool elszigetelődik, így csak az A szolgáltatáshoz rendelt szálkészletet használó munkaterheléseket érinti. A B és C szolgáltatást használó munkaterheléseket ez nem érinti, és azok megszakítás nélkül folytathatják a munkát.

A következő ábrán több ügyfél egyetlen szolgáltatást hív. Minden ügyfélhez külön szolgáltatáspéldány van rendelve. Az 1. kliens túl sok kérést intézett, és túlterhelte a saját példányát. Mivel minden egyes szolgáltatáspéldány el van szigetelve a többitől, a többi ügyfél folytathatja a hívásokat.

Kérdések és megfontolások

• Az alkalmazás üzleti és technikai követelményei alapján határozzuk meg a partíciókat.
• A szolgáltatások vagy fogyasztók válaszfalakba történő particionálásakor vegye figyelembe a technológia által kínált elszigeteltségi szintet, valamint a költségek, a teljesítmény és a kezelhetőség szempontjából jelentkező többletköltséget.
• A kifinomultabb hibakezelés érdekében fontolja meg a válaszfalak kombinálását újbóli próbálkozással, megszakítással és fojtási mintákkal.
• A fogyasztók válaszfalakba történő particionálásakor fontolja meg a folyamatok, szálkészletek és szemaforok használatát. Az olyan projektek, mint a resilience4j és a Polly keretrendszert kínálnak a fogyasztói bulkheads létrehozásához.
• A szolgáltatások bulkheadekbe történő particionálásakor fontolja meg a szolgáltatások különálló virtuális gépekbe, konténerekbe vagy folyamatokba történő telepítését. A konténerek jó egyensúlyt kínálnak az erőforrások elkülönítése és a meglehetősen alacsony rezsiköltség között.
• Az aszinkron üzenetekkel kommunikáló szolgáltatásokat különböző sorozatokon keresztül lehet elkülöníteni. Minden várólistához tartozhat a várólistán lévő üzeneteket feldolgozó példányok dedikált halmaza, vagy egyetlen példánycsoport, amely egy algoritmust használ a sorból való kivonásra és a feldolgozás szétosztására.
• Meghatározhatja a válaszfalak granularitási szintjét. Ha például a bérlőket partíciók között szeretné elosztani, akkor minden egyes bérlőt külön partícióba helyezhet, vagy több bérlőt egy partícióba helyezhet.
• Monitorozza az egyes partíciók teljesítményét és SLA-ját.

Mikor használjuk ezt a mintát

Ezt a mintát használjuk:

• Egy sor háttérszolgáltatás fogyasztására használt erőforrások elkülönítése, különösen, ha az alkalmazás akkor is képes bizonyos szintű funkcionalitást biztosítani, amikor az egyik szolgáltatás nem válaszol.
• A kritikus fogyasztók elkülönítése a standard fogyasztóktól.
• Az alkalmazás védelme a kaszkádszerű hibáktól.

Ez a minta nem alkalmas, ha:

• Az erőforrások kevésbé hatékony felhasználása nem elfogadható a projektben.
• A hozzáadott komplexitás nem szükséges

Példa

A következő Kubernetes konfigurációs fájl egy izolált konténert hoz létre egyetlen szolgáltatás futtatására, saját CPU és memória erőforrásokkal és korlátokkal.