🥇Paslaugų tinklo naudojimo atvejai

Pastaba. vert.: Šio straipsnio autorius (Luc Perkins) yra kūrėjų advokatas CNCF organizacijoje, kurioje yra tokie atvirojo kodo projektai kaip Linkerd, SMI (Service Mesh Interface) ir Kuma (beje, ar jūs taip pat susimąstėte, kodėl Istio yra nėra šiame sąraše?). Dar kartą bandydamas padėti DevOps bendruomenei geriau suprasti madingą ažiotažą, vadinamą „paslaugų tinkleliu“, jis išvardija 16 būdingų galimybių, kurias suteikia tokie sprendimai.

Šiandien aptarnavimo tinklelis ― viena karščiausių temų programinės įrangos inžinerijos srityje (ir pagrįstai!). Manau, kad ši technologija yra neįtikėtinai perspektyvi ir norėčiau, kad ji būtų plačiai pritaikyta (žinoma, kai tai prasminga). Tačiau daugumai žmonių jį vis dar gaubia paslapties aura. Tuo pačiu metu net tie, kurie garsus su juo dažnai sunku suformuluoti jo pranašumus ir tiksliai pasakyti, kas tai yra (įskaitant ir jūsų). Šiame straipsnyje pabandysiu ištaisyti situaciją išvardindamas įvairius naudojimo atvejai „paslaugų tinkleliai“*.

* Pastaba vertimas: čia ir toliau straipsnyje būtent šis vertimas („service mesh“) bus naudojamas dar naujam terminui „service mesh“.

Bet pirmiausia noriu pateikti keletą pastabų:

Niekada nedirbau su tarnybiniais tinkleliais ir nenaudojau jų ne pagal savo mokymosi projektus. Kita vertus, aš buvau tas, kuris 2015 m. parašiau aibę dokumentacijos „Twitter“ vidiniam paslaugų tinkleliui (tada tai net nebuvo vadinama „paslaugų tinkleliu“) ir dalyvavau kuriant svetainę bei dokumentaciją. Linkerd, vadinasi, tai kažką reiškia.
Mano sąrašas yra apytikslis ir neišsamus. Gali būti, kad man nežinomi naudojimo atvejai, ir laikui bėgant, tobulėjant technologijai ir augant jos populiarumui, greičiausiai atsiras naujų galimybių.
Tuo pačiu metu ne kiekvienas esamas paslaugų tinklo diegimas palaiko visus išvardytus naudojimo atvejus. Todėl mano teiginiai, tokie kaip „service mesh can...“ turėtų būti skaitomi kaip „individualūs, o galbūt visi populiarūs paslaugų tinklo diegimai gali...“.
Pavyzdžių tvarka neturi jokio skirtumo.

Trumpas sąrašas:

paslaugos atradimas;
šifravimas;
autentifikavimas ir autorizavimas;
apkrovos balansavimas;
grandinės pertraukimas;
automatinis mastelio keitimas;
Kanarų dislokacijos;
mėlynai žalios dislokacijos;
sveikatos patikrinimas;
apkrovos nusileidimas;
eismo veidrodis;
izoliacija;
užklausų dažnio ribojimas, bandymai pakartotinai ir skirtis laikas;
telemetrija;
auditas;
vizualizacija.

1. Paslaugos atradimas

TL;DR: Prisijunkite prie kitų tinklo paslaugų naudodami paprastus pavadinimus.

Paslaugos turėtų turėti galimybę automatiškai „rasti“ viena kitą naudodami tinkamus pavadinimus, pvz., service.api.production, pets/staging arba cassandra. Debesų aplinka yra elastinga, o vienas pavadinimas gali paslėpti daugybę paslaugos atvejų. Akivaizdu, kad tokioje situacijoje fiziškai neįmanoma užkoduoti visų IP adresų.

Be to, kai viena paslauga randa kitą, ji turėtų galėti siųsti užklausas tai paslaugai, nebijodama, kad jos atsidurs sugedusio egzemplioriaus įvestyje. Kitaip tariant, paslaugų tinklelis turi stebėti visų paslaugų egzempliorių būklę ir kuo atnaujintą prieglobos sąrašą.

Kiekvienas paslaugų tinklelis paslaugų aptikimo mechanizmą įgyvendina skirtingai. Šiuo metu labiausiai paplitęs būdas yra perduoti išoriniams procesams, pvz., Kubernetes DNS. Anksčiau „Twitter“ šiam tikslui naudojome pavadinimų sistemą Finagle. Be to, paslaugų tinklelio technologija leidžia atsirasti pasirinktiniams pavadinimų mechanizmams (nors dar nemačiau jokio SM diegimo su tokia funkcija).

2. Šifravimas

TL;DR: Atsikratykite nešifruoto srauto tarp paslaugų ir padarykite šį procesą automatizuotą bei keičiamo dydžio.

Malonu žinoti, kad užpuolikai negali įsiskverbti į jūsų vidinį tinklą. Ugniasienės tai atlieka puikų darbą. Bet kas atsitiks, jei įsilaužėlis pateks į vidų? Ar jis galės daryti ką nori su vidaus srautu? Tikėkimės, kad taip neatsitiks. Norėdami išvengti šio scenarijaus, turėtumėte įdiegti nulinio pasitikėjimo tinklą, kuriame visas srautas tarp paslaugų yra užšifruotas. Dauguma šiuolaikinių paslaugų tinklelio tai pasiekia abipusiai TLS (abipusis TLS, mTLS). Kai kuriais atvejais mTLS veikia ištisuose debesyse ir klasteriuose (manau, kad tarpplanetiniai ryšiai kada nors bus sutvarkyti panašiai).

Žinoma, mTLS paslaugų tinkleliui neprivaloma. Kiekviena paslauga gali pasirūpinti savo TLS, tačiau tai reiškia, kad turėsite rasti būdą, kaip generuoti sertifikatus, paskirstyti juos tarp paslaugų prieglobos ir įtraukti kodą į programą, kuri įkels šiuos sertifikatus iš failų. Taip, nepamirškite reguliariai atnaujinti šių sertifikatų. Paslaugų tinkleliai automatizuoja mTLS su tokiomis sistemomis kaip SPIFFE, kurios savo ruožtu automatizuoja sertifikatų išdavimo ir rotacijos procesą.

3. Autentifikavimas ir autorizacija

TL;DR: nustatykite, kas yra užklausos teikėjas, ir apibrėžkite, ką jam leidžiama daryti, kol užklausa net nepasiekia paslaugos.

Paslaugos dažnai nori žinoti kas atlieka užklausą (autentifikaciją), o pasinaudodamas šia informacija nusprendžia kad duotam subjektui leidžiama tai daryti (įgaliojimas). Šiuo atveju įvardis „kas“ gali paslėpti:

Kitos paslaugos. Tai vadinama „autentifikavimu“ bendraamžis“ Pavyzdžiui, aptarnavimas web nori prisijungti prie paslaugos db. Paslaugų tinkleliai tokias problemas dažniausiai išsprendžia naudodami mTLS: sertifikatai šiuo atveju veikia kaip būtinas identifikatorius.
Kai kurie vartotojai. Tai vadinama „autentifikavimu“ prašymas“ Pavyzdžiui, vartotojas haxor69 nori nusipirkti naują lempą. Serviso tinkleliai suteikia įvairių mechanizmų, pvz. JSON žiniatinklio žetonai.
Daugelis iš mūsų tai padarė programos kode. Ateina prašymas, žiūrime per lentelę users, suraskite vartotoją ir palyginkite slaptažodį, tada patikrinkite stulpelį permissions ir tt Serviso tinklelio atveju tai įvyksta dar prieš tai, kai užklausa pasiekia paslaugą.

Kai išsiaiškinsime, kas gavo užklausą, turime nustatyti, ką šiam subjektui leidžiama daryti. Kai kurie paslaugų tinkleliai leidžia nustatyti pagrindines strategijas (apie tai, kas ką gali padaryti) kaip YAML failus arba komandų eilutėje, o kiti siūlo integraciją su tokiomis sistemomis kaip Atviras politikos agentas. Galutinis tikslas yra, kad jūsų tarnybos priimtų bet kokią užklausą, saugiai darant prielaidą, kad ji gaunama iš patikimo šaltinio и šis veiksmas leidžiamas.

4. Apkrovos balansavimas

TL;DR: paskirstykite apkrovą tarp paslaugų egzempliorių pagal tam tikrą modelį.

„Paslauga“ paslaugų skyriuje labai dažnai susideda iš daugelio identiškų atvejų. Pavyzdžiui, šiandien paslauga cache susideda iš 5 egzempliorių, o rytoj jų skaičius gali padidėti iki 11. Prašymai siunčiami į cache, turi būti platinami pagal konkretų tikslą. Pavyzdžiui, sumažinkite delsą arba padidinkite tikimybę pasiekti veikiančią egzempliorių. Dažniausiai naudojamas Round-robin algoritmas, tačiau yra daug kitų – pavyzdžiui, svertinis metodas. (svertinis) užklausos (galite pasirinkti pageidaujamus taikinius), skambinti (žiedas) maišos (naudojant nuoseklią maišą tarp pirminių kompiuterių) arba mažiausiai užklausų metodą (pirmenybė teikiama egzemplioriui, turinčiam mažiausiai užklausų).

Klasikiniai balansuotojai turi ir kitų funkcijų, tokių kaip HTTP talpyklos kaupimas ir DDoS apsauga, tačiau jos nėra labai aktualios rytų-vakarų srautui (ty duomenų centre tekančiam srautui – apytiksliai vertimas) (tipinė paslaugų tinklo apimtis). Žinoma, nebūtina naudoti paslaugų tinklo apkrovos balansavimui, tačiau jis leidžia nustatyti ir valdyti kiekvienos paslaugos balansavimo strategijas iš centralizuoto valdymo lygmens, todėl nereikia paleisti ir konfigūruoti atskirų apkrovos balansavimo įrenginių tinklo krūvoje. .

5. Grandinės pertraukimas

TL;DR: Sustabdykite srautą į probleminę paslaugą ir suvaldykite žalą blogiausiu atveju.

Jei dėl kokių nors priežasčių paslauga negali susidoroti su srautu, paslaugų tinklelis pateikia keletą šios problemos sprendimo variantų (kiti bus aptarti atitinkamuose skyriuose). Grandinės nutraukimas yra sunkiausias būdas atjungti paslaugą nuo eismo. Tačiau savaime tai nėra prasminga – reikia atsarginio plano. Gali būti suteiktas nugaros spaudimas (Nugaros spaudimas) į paslaugas, kurios teikia užklausas (tik nepamirškite tam sukonfigūruoti savo paslaugų tinklo!), arba, pavyzdžiui, nuspalvinti būsenos puslapį raudonai ir nukreipti vartotojus į kitą puslapio versiją su „krentančiu banginiu“ („Twitter is“ žemyn“).

Paslaugų tinkleliai ne tik leidžia apibrėžti kur įvyks išjungimas ir kad tai seks. Šiuo atveju „kada“ gali apimti bet kokį nurodytų parametrų derinį: bendrą užklausų skaičių per tam tikrą laikotarpį, lygiagrečių jungčių skaičių, laukiančias užklausas, aktyvius bandymus ir kt.

Tikriausiai nenorite piktnaudžiauti grandinės pertraukimu, bet malonu žinoti, kad turite atsarginį planą kritinei situacijai.

6. Automatinis mastelio keitimas

TL;DR: padidinkite arba sumažinkite paslaugų egzempliorių skaičių, atsižvelgdami į nurodytus kriterijus.

Aptarnavimo tinkleliai nėra planuotojai, todėl jie to nedaro vykdyti mastelio save. Tačiau jie gali suteikti informacijos, kurie planuotojai pagrįs savo sprendimus. Kadangi paslaugų tinkleliai turi prieigą prie viso srauto tarp paslaugų, jie turi daug informacijos apie tai, kas vyksta: kurios paslaugos turi problemų, kurios paslaugos yra labai mažai apkraunamos (joms skiriamas pajėgumas išeikvotas) ir pan.

Pavyzdžiui, „Kubernetes“ paskirsto paslaugas pagal „Pods“ procesoriaus ir atminties naudojimą (žr. mūsų ataskaitą "Automatinis mastelio keitimas ir išteklių valdymas Kubernetes“ – apytiksliai. vertimas.), bet jei nuspręsite keisti mastelį pagal bet kurią kitą metriką (mūsų atveju susijusią su srautu), jums reikės specialios metrikos. Valdymas kaip šitas parodo, kaip tai padaryti pasiuntinys, Tas pats и Prometėjas, tačiau pats procesas yra gana sudėtingas. Norėtume, kad paslaugų tinklelis tai supaprastintų, leisdamas tiesiog nustatyti tokias sąlygas kaip „padidinti paslaugų atvejų skaičių auth, jei laukiamų užklausų skaičius per minutę viršija slenkstį.

7. Kanarų dislokacijos

TL;DR: Išbandykite naujas funkcijas arba paslaugų versijas tam tikram vartotojų pogrupiui.

Tarkime, kad kuriate SaaS produktą ir ketinate išleisti šaunią naują jo versiją. Jūs tai išbandėte scenoje ir jis puikiai veikė. Tačiau vis dar yra tam tikrų rūpesčių dėl jos elgesio realiomis sąlygomis. Kitaip tariant, turite išbandyti naują versiją, kad išvengtumėte realių problemų, nerizikuodami vartotojų pasitikėjimu. Kanarų dislokavimas tam puikiai tinka. Jie leidžia parodyti naują funkciją tam tikram vartotojų pogrupiui. Šį pogrupį gali sudaryti ištikimiausi vartotojai arba tie, kurie dirba su nemokama produkto versija, arba vartotojai, kurie išreiškė norą būti „jūrų kiaulytėmis“.

Paslaugų tinkleliai tai įgyvendina leisdami nurodyti kriterijus, kurie nustato, kas matys kurią programos versiją, ir atitinkamai nukreipia srautą. Tačiau pačioms tarnyboms niekas nesikeičia. 1.0 paslaugos versija mano, kad visos užklausos gaunamos iš vartotojų, kurie turėtų ją matyti, o 1.1 versija mano, kad taip pat ir jos naudotojai. Tuo tarpu galite pakeisti srauto procentą tarp senosios ir naujosios versijų, nukreipdami vis didesnį vartotojų skaičių į naują, jei ji veikia stabiliai ir jūsų „tyros kiaulytės“ duos pirmenybę.

8. Mėlynai žalios dislokacijos

TL;DR: išleiskite šaunią naują funkciją, bet būkite pasirengę nedelsiant viską atsiimti.

Reikšmė mėlynai žalios dislokacijos yra įdiegti naują „mėlynąją“ paslaugą, paleidžiant ją lygiagrečiai su senąja „žaliąja“. Jei viskas klostysis sklandžiai, o nauja paslauga veikia gerai, senoji gali būti palaipsniui išjungta. (Deja, kažkada ši nauja „mėlyna“ paslauga pakartos „žaliosios“ likimą ir išnyks...) Mėlynai žalios spalvos diegimai skiriasi nuo kanarinių tuo, kad naujoji funkcija apima visi vienu metu vartotojai (ne dalis); Esmė yra turėti „saugų uostą“, jei kas nors nutiktų.

Serviso tinkleliai yra labai patogus būdas išbandyti „mėlyną“ paslaugą ir, iškilus problemoms, akimirksniu pereiti prie veikiančios „žalios“. Jau nekalbant apie tai, kad pakeliui jie suteikia daug informacijos (žr. "Telemetrija" žemiau) apie "mėlynosios" darbą, kuri padeda suprasti, ar jis yra paruoštas pilnam darbui.

Pastaba. vert.: Daugiau apie įvairias Kubernetes diegimo strategijas (įskaitant minėtą kanarinę, mėlyną/žalią ir kitas) galite perskaityti Šis straipsnis.

9. Sveikatos patikrinimas

TL;DR: Sekite, kurie paslaugų egzemplioriai veikia, ir reaguokite į tuos, kurie nebeveikia.

Sveikatos patikrinimas (sveikatos patikrinimas) padeda nuspręsti, ar paslaugų egzemplioriai yra pasirengę priimti ir apdoroti srautą. Pavyzdžiui, HTTP paslaugų atveju būklės patikrinimas gali atrodyti kaip GET užklausa galutiniam taškui /health. Atsakymas 200 OK reikš, kad egzempliorius yra sveikas, bet kuris kitas – kad jis nepasirengęs priimti srauto. Aptarnavimo tinkleliai leidžia nurodyti funkcionalumo tikrinimo būdą ir dažnumą, kuriuo šis patikrinimas bus atliekamas. Tada ši informacija gali būti naudojama kitiems tikslams, pavyzdžiui, apkrovai balansuoti ir grandinės pertraukimui.

Taigi sveikatos tikrinimas nėra savarankiškas naudojimo atvejis, o dažniausiai naudojamas siekiant kitų tikslų. Be to, atsižvelgiant į sveikatos patikrinimų rezultatus, gali prireikti veiksmų, nepriklausančių nuo kitų paslaugų tinklo tikslų: pavyzdžiui, atnaujinti būsenos puslapį, sukurti problemą „GitHub“ arba užpildyti JIRA bilietą. O paslaugų tinklelis siūlo patogų mechanizmą visa tai automatizuoti.

10. Apkrovos nusileidimas

TL;DR: peradresuokite srautą reaguojant į laikiną naudojimo padidėjimą.

Jei tam tikra paslauga yra perkrauta srautu, galite laikinai nukreipti dalį šio srauto į kitą vietą (ty „išmesti“, „perkelti“). (tvartas) jis ten). Pavyzdžiui, į atsarginės kopijos tarnybą ar duomenų centrą arba į nuolatinį Paspausti tema. Dėl to paslauga ir toliau apdoros kai kurias užklausas, o ne strigs ir nustos apdoroti viską. Apkrovos mažinimas yra geresnis nei grandinės nutraukimas, tačiau vis tiek nepatartina ja piktnaudžiauti. Tai padeda išvengti pakopinių gedimų, dėl kurių paskesnės paslaugos sugenda.

11. Eismo lygiagretinimas/veidrodis

TL;DR: Siųsti vieną užklausą į kelias vietas vienu metu.

Kartais reikia siųsti užklausą (arba tam tikrą užklausų pasirinkimą) kelioms tarnyboms vienu metu. Tipiškas pavyzdys yra dalies gamybos srauto siuntimas į sustojimo paslaugą. Pagrindinis gamybos žiniatinklio serveris siunčia užklausą paskesnei tarnybai products.production ir tik jam. Ir paslaugų tinklelis protingai nukopijuoja šią užklausą ir siunčia ją products.staging, kurios žiniatinklio serveris net nežino.

Kitas susijęs paslaugų tinklo naudojimo atvejis, kurį galima įgyvendinti kartu su srauto lygiagrečiavimu, yra regresinis testas. Tai apima tų pačių užklausų siuntimą skirtingoms paslaugos versijoms ir patikrinimą, ar visos versijos veikia vienodai. Dar nesu susidūręs su paslaugų tinklelio diegimu su tokia integruota regresijos testavimo sistema Diffy, bet pati idėja atrodo daug žadanti.

12. Izoliacija

TL;DR: suskaidykite savo paslaugų tinklą į mini tinklus.

Taip pat žinomas kaip segmentavimasIzoliavimas yra menas padalinti paslaugų tinklą į logiškai skirtingus segmentus, kurie nieko nežino vienas apie kitą. Izoliavimas yra panašus į virtualių privačių tinklų kūrimą. Esminis skirtumas yra tas, kad vis tiek galite mėgautis visais paslaugų tinklelio privalumais (pvz., paslaugų atradimu), tačiau su papildoma apsauga. Pavyzdžiui, jei užpuolikas gali įsiskverbti į paslaugą viename potinklyje, jis negalės matyti, kokios paslaugos veikia kituose potinkliuose arba perimti jų srauto.

Be to, nauda gali būti ir organizacinė. Galbūt norėsite suskirstyti savo paslaugas pagal savo įmonės struktūrą ir atleisti kūrėjus nuo pažintinės apkrovos, kai jie turi turėti omenyje visą paslaugų tinklą.

13. Užklausų dažnio ribojimas, pakartotiniai bandymai ir skirtieji laikas

TL;DR: jums nebereikia įtraukti sudėtingų užklausų valdymo užduočių į savo kodų bazę.

Visi šie dalykai gali būti laikomi atskirais naudojimo atvejais, tačiau nusprendžiau juos sujungti dėl vieno bendro bruožo: jie perima užklausų gyvavimo ciklo valdymo užduotis, kurias paprastai tvarko programų bibliotekos. Jei kuriate žiniatinklio serverį Ruby on Rails (neintegruotą su paslaugų tinkleliu), kuris teikia užklausas užpakalinėms paslaugoms per grRPC, programa turės nuspręsti, ką daryti, jei nepavyks pateikti N užklausų. Taip pat turėsite išsiaiškinti, kiek srauto šios paslaugos galės apdoroti ir užkoduoti šiuos parametrus naudodami specialią biblioteką. Be to, programa turės nuspręsti, kada laikas pasiduoti ir leisti užklausai pasibaigti (remiantis skirtuoju laiku). O norint pakeisti bet kurį iš aukščiau paminėtų parametrų, žiniatinklio serverį teks sustabdyti, iš naujo sukonfigūruoti ir vėl paleisti.

Šių užduočių perkėlimas į paslaugų tinklą ne tik reiškia, kad paslaugų kūrėjams nereikės apie jas galvoti, bet ir tai, kad jas bus galima peržiūrėti globaliau. Jei naudojama sudėtinga paslaugų grandinė, tarkime, A -> B -> C -> D -> E, reikia atsižvelgti į visą užklausos gyvavimo ciklą. Jei užduotis yra pratęsti C paslaugos skirtąjį laiką, logiška tai padaryti iš karto, o ne dalimis: atnaujinant paslaugos kodą ir laukiant, kol bus priimtas ištraukimo prašymas ir CI sistema įdiegs atnaujintą paslaugą.

14. Telemetrija

TL;DR: surinkite visą reikalingą (ir ne visai) informaciją iš tarnybų.

Telemetrija yra bendras terminas, apimantis metriką, paskirstytą sekimą ir žurnalus. Paslaugų tinkleliai siūlo visų trijų tipų duomenų rinkimo ir apdorojimo mechanizmus. Čia viskas šiek tiek neaiški, nes galimų variantų skaičius yra per didelis. Yra metrikų rinkimas Prometėjas ir kiti įrankiai, kuriais galima rinkti rąstus sklandžiai, Loki, vektorius ir kt. (pavyzdžiui, ClickHouse su mūsų rąstinis namas K8 - apytiksl. vertimas.), paskirstytam sekimui yra Jaeger ir taip toliau. Kiekvienas paslaugų tinklelis gali palaikyti kai kuriuos įrankius, o ne kitus. Bus įdomu pamatyti, ar projektas gali Atidarykite telemetriją suteikti tam tikrą konvergenciją.

Šiuo atveju „service mesh“ technologijos pranašumas yra tas, kad šoninių priekabų konteineriai iš principo gali surinkti visus aukščiau nurodytus duomenis iš savo servisų. Kitaip tariant, jūs turite vieną telemetrijos rinkimo sistemą, o paslaugų tinklelis gali apdoroti visą šią informaciją įvairiais būdais. Pavyzdžiui:

uodegos žurnalai iš tam tikros paslaugos CLI;
stebėti užklausų kiekį iš paslaugų tinklo prietaisų skydelio;
rinkti paskirstytus pėdsakus ir persiųsti juos tokiai sistemai kaip Jaeger.

Dėmesio, subjektyvus sprendimas: Paprastai tariant, telemetrija yra sritis, kurioje nepageidautina stiprūs trikdžiai iš aptarnavimo tinklo. Rinkti pagrindinę informaciją ir skrydžio metu sekti kai kurias auksines metrikas, pvz., užklausų sėkmės rodiklį ir delsą, yra gerai, bet tikėkimės, kad neatsiras Frankenšteino krūvos, bandančios pakeisti specializuotas sistemas, kai kurios iš jų jau pasitvirtino ir gerai ištirtos. .

15. Auditas

TL;DR: Tie, kurie pamiršta istorijos pamokas, yra pasmerkti jas pakartoti.

Auditas – tai menas stebėti svarbius įvykius sistemoje. Paslaugų tinklelio atveju tai gali reikšti stebėjimą, kas pateikė užklausas konkrečių paslaugų galutiniams taškams arba kiek kartų per pastarąjį mėnesį įvyko koks nors su sauga susijęs įvykis.

Akivaizdu, kad auditas yra labai glaudžiai susijęs su telemetrija. Skirtumas tas, kad telemetrija dažniausiai siejama su tokiais dalykais kaip produktyvumas ir techninis vientisumas, o auditas gali būti susijęs su teisiniais ir kitais klausimais, peržengiančiais griežtai techninę sferą (pavyzdžiui, atitiktį GDPR – ES Bendrajam duomenų apsaugos reglamentui).

16. Vizualizacija

TL;DR: Tegyvuoja React.js – neišsenkantis įmantrių sąsajų šaltinis.

Galbūt yra geresnis terminas, bet aš jo nežinau. Turiu galvoje tiesiog grafinį paslaugų tinklo ar kai kurių jo komponentų vaizdą. Šios vizualizacijos gali apimti tokius rodiklius kaip vidutinis delsos laikas, šoninės priekabos konfigūracijos informacija, sveikatos patikrinimo rezultatai ir įspėjimai.

Darbas į paslaugas orientuotoje aplinkoje apima daug didesnį pažintinį krūvį, palyginti su Jo Didenybe Monolitu. Todėl pažinimo spaudimas turėtų būti sumažintas bet kokia kaina. Paprasta grafinė paslaugų tinklelio sąsaja su galimybe spustelėti mygtuką ir gauti norimą rezultatą gali būti lemiamas šios technologijos populiarumo augimui.

Į sąrašą nebuvo įtraukti

Iš pradžių ketinau į sąrašą įtraukti dar keletą naudojimo atvejų, bet tada nusprendžiau to nedaryti. Štai jos ir mano sprendimo priežastys:

Daugiafunkcis duomenų centras. Mano nuomone, tai ne tiek naudojimo atvejis, kiek siaura ir specifinė paslaugų tinklelio taikymo sritis arba kai kurių funkcijų rinkinys, pvz., paslaugų atradimas.
Įėjimas ir išėjimas. Tai susijusi sritis, bet aš apsiribojau (galbūt dirbtinai) tik „rytų–vakarų eismas“ naudojimo atveju. Įėjimas ir išėjimas nusipelno atskiro straipsnio.

išvada

Tai kol kas viskas! Vėlgi, šis sąrašas yra labai savavališkas ir greičiausiai neišsamus. Jei manote, kad ką nors praleidau arba ką nors padariau ne taip, susisiekite su manimi Twitter (@luckerkins). Prašau gerbti padorumo taisykles.

PS iš vertėjo

Straipsnio pavadinimo iliustracija paremta vaizdu iš straipsnio „Kas yra „Service Mesh“ (ir kada jį naudoti)?“(Gregory MacKinnon). Tai rodo, kaip kai kurios programų funkcijos (žalia spalva) buvo perkeltos į paslaugų tinklą, užtikrinantį tarpusavio ryšį (mėlyna spalva).

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com