Mikroservisai - kada reaguoti vs. Orkestruoti

Daugelis iš mūsų yra susipažinę su pagrindinėmis mikro paslaugų koncepcijomis ir jų pranašumais; tačiau dažnai nėra sutarimo, kaip juos tinkamai įgyvendinti. Kurdami programą, kuriai naudojamos mikro paslaugos, turėsite priimti sprendimus, kaip sąveikauja mikro paslaugos. Per šias diskusijas kyla bendras klausimas: „Ar turėčiau naudoti orkestraciją ar reaktyvų požiūrį į savo programą? Ar įmanoma naudoti abu? “

Kaip ir bet kokio technologinio sprendimo atveju, kiekvieno požiūrio privalumai ir trūkumai turi būti įvertinti atsižvelgiant į jūsų konkretų projektą. Šiame straipsnyje išsamiai aptarsime kiekvieną iš šių modelių ir keletą pavyzdžių, kada geriausia juos naudoti.

Orkestravimo nauda ir kompromisai

Orchestration yra tradicinis įvairių paslaugų sąveikos tvarkymo būdas, nukreiptas į į paslaugas orientuotą architektūrą (SOA). Organizuojant orkestrą, paprastai yra vienas valdiklis, kuris veikia kaip visos paslaugų sąveikos „orkestratorius“. Paprastai tai atitinka užklausos / atsakymo tipo modelį.

Pvz., Jei reikėjo iškviesti tris paslaugas tam tikra tvarka, orkestrantas skambina kiekvienai iš jų, laukdamas atsakymo prieš skambindamas kitai.

Privalumai

  • Tai geras būdas valdyti programos srautą, kai yra sinchroninis apdorojimas. Pvz., Jei A paslaugą reikia sėkmingai baigti prieš pradedant teikti paslaugą B.

Kompromisai

  • Paslaugos sujungiamos kartu sukuriant priklausomybes. Jei A paslauga neveikia, B ir C tarnyboms niekada nebus skambinta.
  • Jei yra centrinis bendras orkestrų egzempliorius visoms užklausoms, tada orkestras yra vienas nesėkmės taškas. Jei jis sumažėja, visas apdorojimas sustoja.
  • Pasinaudoja sinchroniniu apdorojimu, kuris blokuoja užklausas. Šiame pavyzdyje bendras apdorojimo tarp duomenų apdorojimo laikas yra laiko, per kurį reikia iškviesti A paslaugą, paslaugą B ir C paslaugą, suma.

Reaktyvūs pranašumai ir kompromisai

Kurdami mikroservisų architektūrą norime išvengti priklausomybių kūrimo kiekvienoje mikroservise; tai reiškia, kad kiekviena tarnyba turėtų sugebėti atsistoti savarankiškai. Reaktyvūs architektūros modeliai išsprendžia kai kuriuos aukščiau išvardintus orkestravimo iššūkius.

Aš linkęs galvoti apie reaktyviąją architektūrą kaip į įvykį orientuotą architektūros modelį, taikomą mikropaslaugoms. Užuot turėję centrinį orkestrą, kuris kontroliuoja, kokie veiksmai įvyksta, logika, ši logika yra integruota į kiekvieną tarnybą iš anksto.

Pagalvokite apie tai kaip apie koordinaciją ar choreografiją. Tarnybos žino, kaip į ką reaguoti ir kaip prieš laiką, pavyzdžiui, žygiuojanti grupė, atliekanti savo didelį skaičių po kelių mėnesių praktikos. Paslaugos naudoja įvykių srautą asinchroniniam įvykių perdavimui. Kelios paslaugos gali sunaudoti tuos pačius įvykius, atlikti tam tikrą apdorojimą ir tada rengti savo įvykius atgal į įvykių srautą tuo pačiu metu. Įvykių srautas neturi jokios logikos ir yra skirtas kaip kvailas vamzdis.

Asinchroninis reaktyviosios architektūros pobūdis pašalina blokavimą arba laukimą, kuris nutinka atliekant orkestravimo (užklausos / atsakymo) tipo apdorojimą. Paslaugos gali rengti renginius ir tęsti tvarkymą. Renginių srauto naudojimas tokiu būdu leidžia atsieti gamintojo ir vartotojų ryšius - gamintojui nereikia žinoti, ar vartotojas dirba ir veikia prieš rengdamas įvykį, ar vartotojas gavo įvykį, kuris buvo sukurtas.

Be to, kai kuriais atvejais gamintojai gali norėti nukreipti komandas į konkrečią paslaugą ir gauti patvirtinimą, kad vartotojas jas gavo. Be to, vartotojai / gamintojai gali norėti vartoti / rengti renginius iš / į renginių srautą. Tai yra teisingas modelis, ir dažnai rasite abu metodus, naudojamus kartu reaktyviojoje architektūroje.

Privalumai

  • Įgalina greitesnį duomenų apdorojimą, nes paslaugos gali būti vykdomos lygiagrečiai / asinchroniškai.
  • Lengviau pridėti / atnaujinti paslaugas, nes jas galima lengvai įjungti / ištraukti iš įvykių srauto.
  • Gerai suderinamas su judriu pristatymo modeliu, nes komandos gali sutelkti dėmesį į tam tikras paslaugas, o ne į visą programą.
  • Kontrolė paskirstoma, todėl nebėra vieno orkestro, kuris tarnautų kaip pagrindinis gedimo taškas.
  • Keli modeliai gali būti naudojami su reaktyvia architektūra, kad būtų galima gauti papildomų pranašumų. Pvz., Įvykių tiekimas yra tada, kai „Event Stream“ saugo visus įvykius ir įgalina pakartoti įvykius. Tokiu būdu, jei paslauga sumažėjo, kol renginiai dar buvo kuriami, grįžusi internete ji galėjo pakartoti tuos įvykius, kad atkurtų. Be to, komandų užklausos atsakomybės atskyrimas (CQRS) gali būti naudojamas atskirti skaitymo ir rašymo veiklą. Tai leidžia kiekvieną iš jų pakeisti atskirai. Tai labai naudinga, jei turite programą, kuri yra lengvai perskaityta ir lengva rašyti, arba atvirkščiai.

Kompromisai

  • Async programavimas dažnai yra reikšmingas požiūris į kūrėjus. Aš linkęs manyti, kad tai panašu į rekursiją, kai jūs negalite išsiaiškinti, kaip kodas vykdys, tiesiog pažvelgdamas į jį, turite apgalvoti visas galimybes, kurios tam tikru laiko momentu galėtų būti tikros.
  • Sudėtingumas pasislenka. Vietoj to, kad srauto valdymas būtų centralizuotas orchestratoriuje, srauto valdymas dabar yra suskaidytas ir paskirstytas atskiroms tarnyboms. Kiekviena paslauga turėtų savo srauto logiką, ir ši logika nustatytų, kada ir kaip ji turėtų reaguoti, remdamasi konkrečiais įvykio srauto duomenimis.

Hibridai

Daugelis kūrėjų nustatė, kad vienodas metodas neveikia programinės įrangos architektūros. Manau, kad tai ypač pasakytina apie reagavimo ir orkestravimo modelius. Ką jūs darote, jei jūsų naudojimo atvejis patenka į pilkąją zoną, kuriai būdingos reaktyviosios ir orkestravimo ypatybės? Pvz., Galbūt turite sinchroninio ir asinchroninio apdorojimo derinį; sinchroniniai asinchroninės veiklos blokai arba atvirkščiai. Manau, kad tokiose situacijose yra vienas ar keli hibridiniai modeliai, kurie gali sukurti pridėtinę vertę, ir į juos reikėtų atsižvelgti.

Vienas projektavimo principas, į kurį reikia atsižvelgti naudojant hibridinį metodą, yra išlaikyti pagrindinę paslaugų sąveiką reaktyvią, kad būtų pasiektas didesnis asinchroninio apdorojimo lygis. Jei atliksite priešingai (naudodamiesi orkestravimo šablonais tarp paslaugų ir asinchroniniais modeliais tarnyboje), apribosite bendrą asinchroninio apdorojimo kiekį, kurį galite atlikti. Žemiau apžvelgsime du skirtingus hibridinius modelius, kuriuose kartu su orkestracija naudojami reaktyvūs modeliai.

Hibridas Nr. 1 - reaktyvus tarp ir orkestravimas viduje

Pirmasis hibridinis modelis naudoja reaktyvųjį ryšį tarp paslaugų ir paslaugos organizavimą. Šiame pavyzdyje A, B ir C paslaugos reaguoja viena į kitą. A paslauga sunaudoja įvykį, kuris suaktyvina skambučius į papildomas D, E ir F paslaugas. Šie papildomi paslaugų skambučiai gali būti asinchroniniai arba sinchroniniai. A paslauga sukuria įvykį, gautą iš tų trijų paslaugų skambučių.

Privalumai

  • Paslaugos yra atsietos (bet ne paslaugos, teikiamos A tarnyboje).
  • Asinchroninis apdorojimas įgalinamas naudojant įvykius tarp tarnybų.
  • Bendras srautas pasiskirsto. Kiekviena paslauga turi savo srauto logiką.

Kompromisai

  • A tarnyboje yra sujungimas su D, E ir F paslaugomis.
  • Priklausomai nuo projekto, A tarnyboje gali būti sinchroninis apdorojimas, kuris blokuoja užklausas.

2 hibridas - reaktyvus tarp ir koordinatorius, kuris skatina srautą

Antrasis hibridinis modelis naudoja reaktyvųjį ryšį tarp tarnybų ir koordinatorių srautui valdyti. Šiame pavyzdyje koordinatorius yra tarsi reaktyvusis orkestras. Jis vartoja komandų ir įvykių sąvokas - komandos yra tai, ką reikia padaryti, o įvykiai - tai, kas buvo padaryta. Koordinatorius rengia komandas įvykių srautui, o atitinkamos mikroprogramos, kurios iš anksto užprogramuotos komandoms, sunaudoja komandą, atlieka tam tikrą apdorojimą ir sukuria įvykius įvykių sraute. Šiame pavyzdyje paslaugos A ir C prasideda tuo pačiu metu. Koordinatorius sunaudoja įvykius iš įvykių srauto ir prireikus reaguoja į jam rūpimus įvykius.

Privalumai

  • Paslaugos yra atsietos (tačiau tarp paslaugų ir koordinatorių yra tam tikras ryšys).
  • Asinchroninis apdorojimas įgalinamas naudojant įvykius tarp tarnybų.
  • Reaktyviajame koordinatoriuje vienoje vietoje galima pamatyti bendrą srautą.

Kompromisai

  • Koordinatorius turi ryšį su tarnybomis - ypač su tuo, kad reikia žinoti, kokių komandų tarnybai reikia norint reaguoti.
  • Koordinatoriui nusileidus, gali būti paveikta visa reaktyvioji sistema.

Kada naudoti orkestravimo versiją Reaktyvus vs. Hibridai

Taigi ar viskas turėtų būti reaguojama į priekį? Ar orkestravimas yra praeitis? Dirbdamas skirtingais naudojimo atvejais sužinojau, kad yra tinkamų scenarijų, kuriuose kiekvienas modelis turi prasmę. Čia mes eisime per keletą hipotetinių sąlygų, kur galėtų būti taikoma gryna reaktyvi, gryna orkestracija ar hibridinis modelis.

Gryno reaktyvaus naudojimo atvejai

  • Jei visas ar didžioji dalis jūsų apdorojimo gali būti atliekama asinchroniškai. Reaktyvusis architektūros modelis yra labai tinkamas apdorojimui, kuris turi vykti lygiagrečiai. Jei jūsų apdorojimas gali būti atliekamas asinchroniškai iki minimumo iki nulio, tada reaktyvusis modelis gali būti per didelis.
  • Jei decentralizuotas srautas į kiekvieną paslaugą yra valdomas. Koreliacijos ID gali būti naudojami norint iš naujo sukurti centralizuotą stebėjimo ir audito vaizdą.
  • Jei prioritetas yra greitis rinkai. Mikro paslaugų derinimas su reaktyviu metodu padeda maksimaliai sumažinti atsiejimą ir sumažinti priklausomybes, suteikiant gaminiams galimybę greičiau patekti į rinką.

Gryno orkestro naudojimo atvejai

  • Jei visi arba dauguma jūsų žingsnių turi būti atlikti nuosekliai, lygiagretaus apdorojimo galimybėmis iki minimumo iki nulio.
  • Jei yra noras išlaikyti bendrą srauto valdymą centralizuotą. Tai gali būti sudėtinga, bet aš matau scenarijų, kai srauto centralizavimas galėtų būti prasmingas. Tiksliau, jei galimybė pamatyti srautą iš vienos pusės į kitą yra didelis prioritetas tiek projektavimo, tiek vykdymo metu. Viena iš sąlygų, kai tai gali būti tiesa, yra tai, kad turite šimtus paslaugų, kurių kiekviena turi kelis skirtingus srautus, atsižvelgiant į tai, kas yra tvarkoma. Tokiu atveju gali būti lengviau valdyti srautą centrinėje vietoje, o ne paskirstyti.
  • Atsiejimas nėra prioritetas.

Mišraus naudojimo atvejai

Kada naudoti reaktyvųjį paslaugų teikimą ir paslaugų organizavimą

  • Jei visas ar didžioji dalis jūsų apdorojimo gali būti atliekama asinchroniškai.
  • Jei decentralizuotas srautas į kiekvieną paslaugą yra valdomas.
  • Jei prioritetas yra greitis rinkai.
  • Jei yra nuoseklūs veiksmai, kurie taikomi tik tam tikrai paslaugai, o ne visoms paslaugoms.

Kada srautui valdyti reikia reaguoti tarp tarnybų ir koordinatoriaus

  • Jei yra sinchroniniai asinchroninio apdorojimo blokai.
  • Jei bendras srautas galėtų pasikeisti atsižvelgiant į tvarkomus duomenis, ir tas srautas galėtų apimti kelis šimtus mikro paslaugų.
  • Jei reikia pamatyti bendrą srautą iš vieno galo į kitą projektavimo ir vykdymo metu.
  • Jei reikia kuo labiau atsieti, kad būtų pašalintos priklausomybės.

Išvada

Apskritai, visos trys kategorijų modeliai - orkestravimas, reaktyvusis ir hibridinis - gali būti taikomi skirtinguose scenarijuose ir naudojimo atvejais. Iš tikrųjų nė vienas iš jų nebūtinai yra geresnis už kitus ar tinka visiems poreikiams. Jei klausiate: „Ar turėčiau naudoti orkestraciją ar reaktyvų požiūrį savo programoje? Ir ar galima naudoti abu? “Mano rekomendacija pirmiausia bus įvertinti naudojant reaktyviąją architektūrą, tada grįžti iš ten, jei tai netinka jūsų naudojimui. Tai padės garantuoti, kad pasirinksite geriausią jūsų poreikiams pritaikytą architektūrą su tinkamai įvertintais jūsų projekto privalumais ir trūkumais.

ATSKLEIDIMO PAREIŠKIMAS: Šios nuomonės yra tos pačios autorės. Jei šiame pranešime nenurodyta kitaip, „Capital One“ nėra susijusi su jokia iš paminėtų bendrovių ir jai jos nepatvirtina. Visi naudojami ar rodomi prekių ženklai ir kita intelektinė nuosavybė priklauso jų savininkams. Šis straipsnis yra © 2018 „Capital One“.