Tapahtumien hallinta mikropalveluissa

Monoliittisessa sovelluksessa yksi tietokanta käsittelee kaikki tapahtumat ja varmistaa tietojen eheyden ACID-ominaisuuksilla (Atomicity, Consistency, Isolation, Durability).

Mikropalveluissa liiketoimintalogiikka on jaettu moniin itsenäisiin palveluihin, joilla kullakin on usein oma tietokantansa. Tämä aiheuttaa merkittäviä haasteita useiden palvelujen yli ulottuvien tapahtumien hallinnassa. Miten varmistatte, että useita palveluja koskeva toiminto joko suoritetaan kokonaan tai perutaan kokonaan?

Monoliittisessa sovelluksessa yksi tietokanta varmistaa tapahtumien eheyden:

• Kaikki liiketoimintatapahtuman toiminnot tapahtuvat yhdessä tietokannassa.
• Tietokanta takaa ACID-ominaisuudet.

Mikropalveluissa kukin palvelu yleensä omistaa omat tietonsa:

• Yksi liiketoimintatapahtuma saattaa koskea useita palveluja ja tietokantoja.
• Perinteiset ACID-tapahtumat eivät voi suoraan ylittää näitä rajoja.

ACID-ominaisuudet toimivat erinomaisesti yksittäisissä keskitetyissä tietokannoissa. Ne eivät kuitenkaan luonnostaan sovellu hajautettuihin järjestelmiin, kuten mikropalveluihin:

• Atomisuus: Kaikki tai ei mitään -periaatetta on vaikea taata itsenäisten palvelujen välillä.
• Yhdenmukaisuus: Välitöntä yhdenmukaisuutta on vaikea ylläpitää useiden tietokantojen välillä.
• Eristys: Samanaikaisten muutosten eristäminen palvelujen välillä on haastavaa.

Maailmanlaajuisen ACID-käsittelyn pakottaminen johtaa usein tiukasti kytkettyihin palveluihin ja heikompaan skaalautuvuuteen.

Saatatte pohtia, voisitteko käyttää yksinkertaisesti "maailmanlaajuista tapahtumaa" kaikissa mikropalveluissa. Lyhyt vastaus on: yleensä se ei ole käytännöllistä eikä suositeltavaa.

• Maailmanlaajuiset tapahtumat edellyttävät koordinaattoria, joka lukitsee resursseja useissa tietokannoissa.
• Tämä aiheuttaa merkittävää kuormitusta, heikentää suorituskykyä ja luo yksittäisen vikapisteen.
• Se kytkee palvelut tiukasti toisiinsa ja kumoaa mikropalvelujen keskeisen hyödyn: itsenäisyyden.

Tämä lähestymistapa johtaa usein hajautettuihin lukkiutumisiin ja heikkoon saatavuuteen.

Hajautetussa järjestelmässä mikä tahansa palvelu voi vikaantua milloin tahansa muista riippumatta. Tätä kutsutaan osittaiseksi vikaantumiseksi. Kuvitellaan verkkotilaus:

• Order Service luo tilauksen.
• Payment Service käsittelee maksun.
• Inventory Service vähentää varastosaldoa.

Jos Inventory Service vikaantuu maksun jälkeen mutta ennen varastosaldon vähentämistä, järjestelmä on epäyhdenmukaisessa tilassa: maksu on veloitettu, mutta varastosaldoa ei ole vähennetty.

Miten pidämme tiedot yhdenmukaisina useiden palvelujen välillä ilman maailmanlaajuisia ACID-tapahtumia? Tämä on mikropalvelujen keskeinen ongelma.

Perinteisestä "välittömästä yhdenmukaisuudesta", jossa kaikki tiedot ovat yhdenmukaisia heti tapahtuman jälkeen, tingitään usein saatavuuden ja skaalautuvuuden vuoksi. Sen sijaan tavoittelemme usein eventuaalista yhdenmukaisuutta.

Tämä tarkoittaa, että tiedot voivat olla tilapäisesti epäyhdenmukaisia, mutta järjestelmä takaa niiden muuttuvan lopulta yhdenmukaisiksi.

Two-Phase Commit (2PC) -protokolla on perinteinen tapa toteuttaa atomiset tapahtumat hajautettujen tietokantojen välillä. Se koostuu kahdesta vaiheesta:

1. Valmisteluvaihe: Koordinaattori pyytää kaikkia osallistujia valmistautumaan sitoutumiseen.
2. Sitoutumisvaihe: Jos kaikki osallistujat ovat valmiita, koordinaattori käskee niitä sitoutumaan; muussa tapauksessa se käskee niitä perumaan muutokset.

Vaikka 2PC varmistaa atomisuuden, sillä on mikropalveluissa merkittäviä haittoja: se estää muita toimintoja, on hidas ja altis koordinaattorin vikaantumiselle.

Perinteisen ACID-käsittelyn ja 2PC:n rajoitusten vuoksi hajautetuissa ympäristöissä mikropalveluarkkitehtuurit tarvitsevat erilaisia lähestymistapoja liiketoimintatapahtumien hallintaan.

Näihin vaihtoehtoisiin malleihin kuuluu usein:

• Suurten tapahtumien jakaminen pienemmiksi, itsenäisiksi paikallisiksi tapahtumiksi.
• Asynkronisen viestinnän, kuten viestijonojen, käyttäminen.
• Korvaavien tapahtumien toteuttaminen toimien kumoamiseksi, jos myöhempi vaihe epäonnistuu.

Näissä malleissa asetetaan tiukan välittömän yhdenmukaisuuden sijaan etusijalle saatavuus ja osiointiensieto.

Ajatellaan verkkotilausta, joka koskee useita palveluja:

1. Order Service vastaanottaa tilauksen.
2. Customer Service tarkistaa asiakkaan luottotiedot.
3. Payment Service veloittaa asiakkaalta maksun.
4. Inventory Service varaa tuotteet.
5. Shipping Service lähettää tilauksen.

Jos Inventory Service ei onnistu varaamaan tuotteita maksun jälkeen, asiakkaalle on palautettava maksu. Tässä tarvitaan vaihtoehtoisia malleja, joilla nämä vaiheet koordinoidaan ja virhetilanteita käsitellään.

Tässä oppitunnissa tarkastelimme useiden mikropalvelujen välisten liiketoimintatapahtumien hallinnan luontaisia vaikeuksia. Opimme, että:

• Perinteiset ACID-ominaisuudet eivät suoraan sovellu palvelurajojen yli.
• Maailmanlaajuisia tapahtumia, kuten 2PC:tä, vältetään usein niiden monimutkaisuuden, suorituskykypullojen ja heikomman saatavuuden vuoksi.
• Osittaiset vikaantumiset ovat jatkuva uhka, joka johtaa epäyhdenmukaisiin tiloihin.

Nämä haasteet korostavat vaihtoehtoisten mallien, kuten Sagan, ratkaisevaa tarvetta. Opitte niistä tulevilla oppitunneilla, jotta tietojen yhdenmukaisuus voidaan varmistaa hajautetussa maailmassa.