Microsoteenused - millal reageerida vs. Orkestraat

Enamik meist tunneb mikroteenuste põhimõisteid ja nende eeliseid; siiski on sageli vähem üksmeelt selles, kuidas neid õigesti rakendada. Mikrosideteenuseid kasutava rakenduse ehitamisel peate otsustama, kuidas mikroteenused suhelda saavad. Nende arutelude käigus kerkib üldine küsimus: “Kas peaksin oma rakenduses kasutama orkestratsiooni või reaktiivset lähenemist? Ja kas on võimalik kasutada mõlemat? ”

Nagu iga tehnoloogilise otsuse puhul, on ka igal lähenemisel plusse ja miinuseid, mida tuleb hinnata just teie konkreetset projekti silmas pidades. Selles artiklis käsitleme kõiki neid mustreid üksikasjalikult koos mõne näitega sellest, millal on kõige parem neid kasutada.

Orkestreerimise eelised ja kompromissid

Orkestreerimine on traditsiooniline viis teenus-orienteeritud arhitektuuri (SOA) erinevate teenuste koostoime haldamiseks. Orkestreerimise korral on tavaliselt üks kontroller, kes toimib kogu teenuse interaktsiooni “orkestrina”. Tavaliselt järgib see päringu / vastuse tüübi mustrit.

Näiteks kui vaja oli helistada kolmele teenusele kindlas järjekorras, siis orkestriühendaja helistab igaühele neist, oodates vastust enne järgmisele helistamist.

Kasu

  • Pakub head viisi rakenduse voo juhtimiseks sünkroonse töötlemise korral. Näiteks kui teenus A peab enne teenuse B käivitamist edukalt lõpule jõudma.

Kompromissid

  • Sidub teenused kokku, luues sõltuvusi. Kui teenus A on maas, ei helistata kunagi teenustele B ja C.
  • Kui kõigi päringute jaoks on olemas orkestri jagatud tsentraalne eksemplar, on orkestril üks tõrkepunkt. Kui see langeb, peatub kogu töötlemine.
  • Kasutatakse sünkroonset töötlemist, mis blokeerib taotlused. Selles näites on töötluse täielik kestus summa, mis kulub teenuse A + teenuse B + teenuse C väljakutsumiseks.

Reaktiivsed eelised ja kompromissid

Mikrosideteenuste arhitektuuri ehitamisel tahame vältida sõltuvuste loomist igas mikroteenuses; see tähendab, et iga teenus peaks suutma iseseisvalt seista. Reaktiivsed arhitektuurimustrid lahendavad mõne eespool loetletud orkestratsiooni väljakutse.

Ma kipun mõtlema reaktiivsest arhitektuurist kui sündmustepõhisest arhitektuurimustrist, mida rakendatakse mikroteenuste jaoks. Selle asemel, et omada keskset orkestrit, mis juhib loogikat selle kohta, millised toimingud toimuvad, on see loogika igasse teenusesse sisse ehitatud enne tähtaega.

Mõelge sellele kui koordineerimisele või koreograafiale. Teenistused teavad, millele reageerida ja kuidas saab enne tähtaega marssida bänd, kes esindab pärast kuudepikkust harjutamist oma suurt numbrit. Teenused kasutavad sündmuste voogu sündmuste asünkroonseks edastamiseks. Mitu teenust võivad tarbida samu sündmusi, teha mõnda töötlemist ja seejärel toota oma sündmused tagasi sündmustevoogu, samal ajal. Sündmusevoogul puudub igasugune loogika ja see on mõeldud nukraks toruks.

Reaktiivse arhitektuuri asünkroonne olemus eemaldab blokeerimise või ootamise, mis juhtub orkestratsiooni (päringu / vastuse) tüüpi töötlemisega. Teenused võivad luua üritusi ja hoida töötlemist. Sündmusevoo kasutamine selleks võimaldab tootjate ja tarbijate vahelist suhtlust lahti ühendada - tootja ei pea enne sündmuse tootmist teadma, kas tarbija töötab ja töötab, või kui tarbija sai selle sündmuse, mis oli toodetud.

Mõnel juhul võivad tootjad soovida suunata käsud konkreetsele teenusele ja saada kinnitust, et tarbija sai selle kätte. Lisaks võivad tarbijad / tootjad soovida tarbida / toota üritusi sündmusevoost / sinna. See on kehtiv muster ja sageli leiate reaktiivses arhitektuuris mõlemad lähenemisviisid.

Kasu

  • Võimaldab kiiremat otsatöötlust, kuna teenuseid saab teostada paralleelselt / asünkroonselt.
  • Lihtsam on teenuste lisamine / värskendamine, kuna neid saab hõlpsalt sündmusevoo sisse ja välja lülitada.
  • Vastab hästi paindlikule tarnimismudelile, kuna meeskonnad saavad kogu rakenduse asemel keskenduda kindlatele teenustele.
  • Juhtimine on jaotatud, nii et enam pole ühte orkestrit, mis oleks rikke keskpunkt.
  • Reaktiivse arhitektuuriga saab täiendavate eeliste saamiseks kasutada mitut mustrit. Näiteks on sündmuste allhange siis, kui sündmuste voog salvestab kõik sündmused ja võimaldab sündmuste kordust. Nii saaks mõni teenus alla minna, kui sündmusi veel toodeti, ja siis, kui see veebis tagasi tuli, saaks ta neid sündmusi korrata, et neist järele jõuda. Samuti saab lugemis- ja kirjutamistegevuse eraldamiseks kasutada käsu päringu vastutuse eraldamist (CQRS). See võimaldab neid kõiki iseseisvalt skaleerida. See on kasulik, kui teil on lugemisraske ja kirjutamiseks kerge rakendus või vastupidi.

Kompromissid

  • Asynci programmeerimine on arendajatele sageli oluline mõttevahetus. Ma kipun seda mõtlema sarnaselt rekursioonile, kus te ei saa aru, kuidas kood käivitub, kui seda lihtsalt vaadata, peate mõtlema läbi kõik võimalused, mis konkreetsel ajahetkel võiksid tõsi olla.
  • Keerukus on nihkunud. Selle asemel, et voolu juhtimine oleks orkestris tsentraliseeritud, on voo juhtimine nüüd laiali jaotatud ja jaotatud üksikute teenuste vahel. Igal teenusel oleks oma vooguloogika ja see loogika tuvastaks sündmusevoo konkreetsete andmete põhjal, millal ja kuidas see peaks reageerima.

Hübriidid

Paljud arendajad on leidnud, et kõigile sobiv lahendus ei toimi tarkvararakenduste arhitektuuris hästi. Usun, et see kehtib eriti reageerivate ja orkestratsioonimustrite kohta. Mida teha, kui teie kasutusjuhtum jääb halli piirkonda, millel on nii reaktiivse kui ka orkestratsioonimustri mõned omadused? Võib-olla on teil näiteks sünkroonse ja asünkroonse töötluse segu; kas asünkroonsete tegevuste sünkroonsed plokid või vastupidi. Usun, et nendes olukordades on üks või mitu hübriidmudelit, mis võivad anda lisaväärtust ja mida tuleks teie projekti puhul arvestada.

Hübriidmeetodi kasutamisel tuleb arvestada ka teenuste peamise interaktsiooni reageerimisega, et saavutada kõrgem asünkroonse töötluse tase. Vastupidine toiming (teenuste korraldamise ja teenuse asünkroonsete mustrite vahelise korralduse mustrite kasutamine) piirab asünkroonse töötlemise üldist mahtu, mida saate teha. Allpool tutvume kahe erineva hübriidmustriga, mis kasutavad koos orkestreerimisega ka reaktiivseid mustreid.

Hübriid nr 1 - reaktiivne vahel ja sisemuses orkestratsioon

Esimene hübriidmuster kasutab reageerivaid teenuste vahel ja teenuse siseselt korraldamist. Selles näites on teenused A, B ja C üksteisega reageerivad. Teenus A tarbib sündmuse, mis käivitab selle täiendavate teenuste D, E ja F kõnede korraldamiseks. Need lisateenuste kõned võivad olla asünkroonsed või sünkroonsed. Teenus A genereerib seejärel sündmuse nende kolme teeninduskõne tulemusega.

Kasu

  • Teenused on lahti ühendatud (kuid mitte teenuses A olevad teenused).
  • Asünkroonset töötlemist võimaldavad sündmuste võimendamine teenuste vahel.
  • Üldine voog on jaotatud. Iga teenus sisaldab oma vooluloogikat.

Kompromissid

  • Teenuses A on ühendatud teenustega D, E ja F.
  • Sõltuvalt kujundusest võib teenuses A olla sünkroonne töötlemine, mis blokeerib taotlused.

Hübriid nr 2 - on reageeriv ja koordineerib voolu suurendamist

Teises hübriidskeemis kasutatakse voolu juhtimiseks reaktiivset teenuste ja koordinaatori vahel. Selles näites on koordinaator nagu reaktiivorkester. See kasutab käskude ja sündmuste mõisteid - käsud on asjad, mida tuleb teha, ja sündmused on asjad, mis on tehtud. Koordinaator koostab sündmustevoo jaoks käsud ja vastavad käskude jaoks eelprogrammeeritud mikroteenused kasutavad seda käsku, teostavad mõned töötlused ja seejärel toovad sündmused sündmusevoogu. Selles näites avalduvad teenused A ja C korraga. Koordinaator tarbib sündmusi sündmusevoost ja reageerib vajadusel talle hoolivatele sündmustele.

Kasu

  • Teenused on lahutatud (kuid teenuste ja koordinaatori vahel on teatav seotus).
  • Asünkroonset töötlemist võimaldavad sündmuste võimendamine teenuste vahel.
  • Üldist voolu saab reaktiivkoordinaatoris näha ühes kohas.

Kompromissid

  • Koordinaatoril on teenustega sidumine - nimelt see, et nad peavad teadma, milliseid käske teenus reageerimiseks vajab.
  • Kui koordinaator läheb alla, võib see mõjutada kogu reaktiivset süsteemi.

Millal kasutada orkestreerimist vs. Reaktiivne vs. Hübriidid

Nii et edasi liikudes peaks kõik olema reageeriv? Kas orkestratsioon on minevik? Erinevate kasutusjuhtude uurimisel olen leidnud, et on olemas kehtivad stsenaariumid, kus iga muster on mõistlik. Siin kõnnime läbi mõned hüpoteetilised tingimused, kus võiks kohaldada puhast reaktiivset, puhast orkestratsiooni või hübriidskeemi.

Puhta reaktiivse kasutamise juhtumid

  • Kui kogu töötlemist või enamikku teie töödest saab teha asünkroonselt. Reaktiivne arhitektuurimuster sobib suurepäraselt töötlemiseks, mis peab toimuma paralleelselt. Kui töötlemist saab asünkroonselt teostada minimaalselt nullini, võib reaktiivne muster olla liiga suur.
  • Kui iga teenuse voo detsentraliseerimine on juhitav. Korrelatsiooni ID-de abil saab seire ja auditeerimise jaoks tsentraliseeritud vaate uuesti luua.
  • Kui esmatähtis on turule jõudmise kiirus. Mikrosideteenuste ühendamine reaktiivse lähenemisega aitab maksimeerida lahti sidumist ja minimeerida sõltuvusi, võimaldades toodetel kiiremini turule jõuda.

Puhtad orkestratsiooni kasutamise juhtumid

  • Kui kõik või enamus teie toimingutest tuleb teha järjestikku, võimaldades paralleelseks töötlemiseks minimaalselt nulli.
  • Kui on soov hoida üldine voo juhtimine tsentraliseeritud. See võib olla keeruline, kuid näen stsenaariumi, kus voo koondamine võiks olla mõistlik. Täpsemalt, kui võimalus näha otsast lõpuni voogu ühes kohas on esmatähtis nii projekteerimis- kui ka käitamisajal. Üks tingimus, kus see võib tõsi olla, on see, kui teil on sadu teenuseid, millel kõigil on mitu erinevat voogu vastavalt sellele, mida töödeldakse. Sellisel juhul võib voolu hõlpsam hallata keskses kohas, selle jaotamise asemel.
  • Lahtisidumine pole prioriteet.

Hübriidkasutuse juhtumid

Millal kasutada reaktiivset teenuste vahel ja teenuse siseselt korraldamist

  • Kui kogu töötlemist või enamikku teie töödest saab teha asünkroonselt.
  • Kui iga teenuse voo detsentraliseerimine on juhitav.
  • Kui esmatähtis on turule jõudmise kiirus.
  • Kui on olemas järjestikused toimingud, mis kehtivad ainult teenuses, mitte teenustes.

Millal kasutada voolu juhtimiseks teenuste ja koordinaatori vahel reaktiivset

  • Kui asünkroonse töötluse sünkroonsed plokid on olemas.
  • Kui üldine voog saaks töödeldavate andmete põhjal muutuda ja see voog võiks hõlmata mitusada mikroteenust.
  • Kui on vaja näha kogu kogu otsvoolu projekteerimis- ja käitamisajal.
  • Kui on vaja sõltuvusi kõrvaldada võimalikult palju lahtisidumist.

Järeldus

Üldiselt võivad kõik kolm mustrikategooriat - orkestreerimine, reaktiivne ja hübriid - erinevates stsenaariumides ja kasutusjuhtudel rakenduda. Sellisena ei ole ükski tingimata teistest parem ega sobi kõigi vajaduste jaoks. Kui küsite: „Kas ma peaksin oma rakenduses kasutama orkestratsiooni või reaktiivset lähenemist? Ja kas on võimalik kasutada mõlemat? ”Minu soovitus on kõigepealt hinnata reaktiivse arhitektuuri kasutamist ja seejärel liikuda sealt tagasi, kui see ei sobi teie kasutusjuhu jaoks. See aitab tagada, et valite oma vajadustele parima arhitektuuri koos oma projekti jaoks spetsiifiliselt hinnatud eeliste ja miinustega.

AVALIKUSTAMISE AVALDUS: Need arvamused on autori arvamused. Kui selles postituses ei ole märgitud teisiti, pole Capital One seotud ega kuulu ühegi nimetatud äriühinguga. Kõik kasutatavad või kuvatavad kaubamärgid ja muu intellektuaalomand on nende vastavate omanike omanduses. See artikkel on © 2018 Capital One.