• 03/19/2020
• 4 minutes to read
• • d
  • D
  • a
  • v
  • d
  • +6

Bulkhead-kuvio on eräänlainen sovellussuunnittelu, joka kestää vikoja. Bulkhead-arkkitehtuurissa sovelluksen elementit on eristetty pooliin siten, että jos yksi niistä vikaantuu, muut jatkavat toimintaansa. Se on saanut nimensä laivan rungon osastoitujen väliseinien (bulkheadien) mukaan. Jos laivan runko vaurioituu, vain vaurioitunut osa täyttyy vedellä, mikä estää laivaa uppoamasta.

Konteksti ja ongelma

Pilvipohjainen sovellus voi sisältää useita palveluita, ja jokaisella palvelulla on yksi tai useampi kuluttaja. Palvelun liiallinen kuormitus tai vikaantuminen vaikuttaa kaikkiin palvelun kuluttajiin.

Lisäksi kuluttaja voi lähettää pyyntöjä useisiin palveluihin samanaikaisesti, jolloin jokaiseen pyyntöön käytetään resursseja. Kun kuluttaja lähettää pyynnön palveluun, joka on väärin konfiguroitu tai ei vastaa, asiakkaan pyynnön käyttämiä resursseja ei välttämättä vapauteta ajoissa. Kun palveluun kohdistuvat pyynnöt jatkuvat, kyseiset resurssit saattavat loppua. Esimerkiksi asiakkaan yhteysvarasto voi olla tyhjä. Tämä vaikuttaa kuluttajan muihin palveluihin tekemiin pyyntöihin. Lopulta kuluttaja ei voi enää lähettää pyyntöjä muille palveluille, ei vain alkuperäiselle vastaamattomalle palvelulle.

Sama resurssien ehtymisen ongelma vaikuttaa palveluihin, joilla on useita kuluttajia. Suuri määrä yhdeltä asiakkaalta tulevia pyyntöjä voi uuvuttaa palvelussa käytettävissä olevat resurssit. Muut kuluttajat eivät enää pysty kuluttamaan palvelua, mikä aiheuttaa kaskadoituvan vikavaikutuksen.

Ratkaisu

Jaa palveluinstanssit eri ryhmiin kuluttajien kuormituksen ja käytettävyysvaatimusten perusteella. Tämä rakenne auttaa eristämään vikatilanteet ja mahdollistaa palvelun toiminnallisuuden säilyttämisen joillekin kuluttajille myös vikatilanteen aikana.

Kuluttaja voi myös osioida resursseja varmistaakseen, että yhden palvelun kutsumiseen käytettävät resurssit eivät vaikuta toisen palvelun kutsumiseen käytettäviin resursseihin. Esimerkiksi kuluttajalle, joka kutsuu useita palveluita, voidaan määrittää yhteyspooli kutakin palvelua varten. Jos jokin palvelu alkaa vikaantua, se vaikuttaa vain kyseiselle palvelulle määritettyyn yhteyspooliin, jolloin kuluttaja voi jatkaa muiden palveluiden käyttöä.

Tämän mallin hyötyjä ovat muun muassa:

• Eristää kuluttajat ja palvelut kaskadoituvilta vioilta. Kuluttajaan tai palveluun vaikuttava ongelma voidaan eristää omaan laipioonsa, jolloin estetään koko ratkaisun vikaantuminen.
• Mahdollistaa jonkin toiminnallisuuden säilyttämisen palvelun vikaantuessa. Sovelluksen muut palvelut ja ominaisuudet jatkavat toimintaansa.
• Mahdollistaa sellaisten palvelujen käyttöönoton, jotka tarjoavat erilaista palvelun laatua kuluttaville sovelluksille. Korkean prioriteetin kuluttajapooli voidaan määrittää käyttämään korkean prioriteetin palveluita.

Seuraavassa kaaviossa on esitetty laipiot, jotka on jäsennetty yhteyspoolien ympärille, jotka kutsuvat yksittäisiä palveluita. Jos palvelu A epäonnistuu tai aiheuttaa jonkin muun ongelman, yhteyspooli on eristetty, joten vain palvelulle A määritettyä säiepoolia käyttävät työmäärät kärsivät. Palvelua B ja C käyttäviin työtehtäviin ei ole vaikutusta, ja ne voivat jatkaa työskentelyä keskeytyksettä.

Seuraavassa kaaviossa on useita asiakkaita, jotka kutsuvat yhtä palvelua. Jokaiselle asiakkaalle on määritetty oma palveluinstanssi. Asiakas 1 on tehnyt liikaa pyyntöjä ja ylikuormittanut sen instanssin. Koska kukin palveluinstanssi on eristetty muista, muut asiakkaat voivat jatkaa kutsujen tekemistä.

Kysymyksiä ja näkökohtia

• Määrittele osiot sovelluksen liiketoiminnallisten ja teknisten vaatimusten perusteella.
• Kun partitioit palveluita tai kuluttajia bulkheadeihin, harkitse tekniikan tarjoamaa eristystasoa sekä kustannuksiin, suorituskykyyn ja hallittavuuteen liittyviä yleiskustannuksia.
• Harkitse bulkheadejen yhdistämistä uudelleenkytkentä-, katkaisija- ja kuristuskuvioihin kehittyneemmän vikakäsittelyn tarjoamiseksi.
• Kun partitioit kuluttajia bulkheadeihin, harkitse prosessien, säiepoolien ja semaforien käyttöä. Projektit, kuten resilience4j ja Polly, tarjoavat kehyksen kuluttajien bulkheadien luomiseen.
• Kun partitioit palveluita bulkheadeihin, harkitse niiden käyttöönottoa erillisiin virtuaalikoneisiin, kontteihin tai prosesseihin. Kontit tarjoavat hyvän tasapainon resurssien eristämisen ja melko pienen yleiskustannuksen välillä.
• Palvelut, jotka kommunikoivat käyttäen asynkronisia viestejä, voidaan eristää erilaisten jonosarjojen avulla. Jokaisella jonolla voi olla oma joukko instansseja, jotka käsittelevät jonossa olevia viestejä, tai yksi ryhmä instansseja, jotka käyttävät algoritmia jonon purkamiseen ja käsittelyn jakamiseen.
• Määritä bulkkien rakeisuusaste. Jos haluat esimerkiksi jakaa vuokralaiset osioihin, voit sijoittaa jokaisen vuokralaisen erilliseen osioon tai sijoittaa useita vuokralaisia yhteen osioon.
• Valvo kunkin osion suorituskykyä ja SLA:ta.

Milloin tätä mallia kannattaa käyttää

Käytä tätä mallia:

• Erottele resurssit, joita käytetään useiden taustapalveluiden kuluttamiseen, etenkin jos sovellus voi tarjota jonkinasteista toiminnallisuutta silloinkin, kun jokin palveluista ei vastaa.
• erottaa kriittiset kuluttajat tavallisista kuluttajista.
• suojata sovellusta kaskadoituvilta vioilta.

Tämä malli ei ehkä sovellu silloin, kun:

• Resurssien tehottomampi käyttö ei ehkä ole hyväksyttävää projektissa.
• Lisätty monimutkaisuus ei ole tarpeellinen

Esimerkki

Oheinen Kubernetesin konfigurointitiedosto luo eristetyn kontin yksittäisen palvelun suorittamista varten, jolla on omat suorittimen ja muistin resurssit ja rajoitukset.