Mikropaslaugų diegimas gamybinėje aplinkoje

Informatec Digital » Ištekliai » Mikropaslaugų diegimas gamybinėje aplinkoje

Mikropaslaugų architektūros diegimas realioje aplinkoje reiškia ne tik monolito suskaidymą į mažesnius gabalus; tai apima infrastruktūros, komandų, procesų, duomenų, saugumo ir operacijų permąstymą . Kai sistema pereina iš teorijos į gamybinį klasterį, kyla problemų dėl paslaugų atradimo, sutarčių tarp komandų, CI/CD, stebimumo, atsparumo ir mastelio keitimo. Jei šios problemos nebus tinkamai išspręstos, jos gali paversti mikropaslaugas paskirstytu chaosu.

Geros naujienos yra tai, kad šiandien turime sukaupę daug patirties iš tokių organizacijų kaip „Netflix“, „Amazon“, „Google“ ir kitų didelių korporacijų, kurios gamybinėje aplinkoje valdo šimtus mikropaslaugų . Remdamiesi šiomis pamokomis ir geriausia praktika įmonių aplinkoje, naudojant „Kubernetes“ ir „OpenShift“, galime sukurti labai patikimą požiūrį į mikropaslaugų projektavimą, diegimą ir valdymą dideliu mastu neprarandant kontrolės.

Kodėl verta diegti mikropaslaugas gamyboje (ir kada tai neverta)

Gerai suprojektuota mikropaslaugų architektūra leidžia dirbti su mažomis, autonominėmis ir daugiafunkcinėmis komandomis , kurios prisiima atsakomybę už visą paslaugą. Kiekviena komanda veikia aiškiai apibrėžtame kontekste, gali dažnai diegti ir prisiimti visą atsakomybę už savo paslaugą, taip sutrumpindama kūrimo ciklo laiką ir paspartindama naujų funkcijų diegimą.

Dar vienas svarbus privalumas yra nepriklausomas mastelio keitimas kiekvienai paslaugai . Jums nereikia perkrauti visos programos, jei tik kataloge, atsiskaitymo sistemoje ar viešojoje API padidėja srautas. Galite reguliuoti kiekvieną mikropaslaugą horizontaliai arba vertikaliai pagal jos apkrovos modelį, tiksliai išmatuoti kiekvienos funkcijos kainą ir išlaikyti prieinamumą, net jei konkrečioje srityje padidėja suvartojimas.

Šių paslaugų paketavimo ir diegimo būdas palengvina nuolatinį, mažos rizikos diegimą . Kiekvienos mikropaslaugos išleidimas atskirai leidžia daug paprasčiau testuoti naujas idėjas ir atkurti problemines versijas: nematomi diegimai, mėlyni/žali atšaukimai ir automatiniai atšaukimai sumažina gedimų kainą ir suteikia erdvės eksperimentams.

Technologiniu požiūriu, mikropaslaugos skatina laisvę pasirinkti kalbas, sistemas ir duomenų bazes kiekvienai paslaugai. Ne visi poreikiai telpa į tą patį technologijų rinkinį: verslo paslaugos gali būti .NET arba Java, duomenų apdorojimas Scala/Spark, specializuotos paslaugos Python arba F#, o dirbtinio intelekto mikropaslaugos R. Ši kontroliuojama įvairovė leidžia kiekvienu atveju naudoti tinkamą įrankį, neverčiant visos programos keistis pasauliniu technologiniu požiūriu.

Be to, sistemos suskaidymas į mažas, aiškiai apibrėžtas dalis palengvina funkcijų pakartotinį panaudojimą kaip statybinius blokus . Mikropaslauga, iš pradžių sukurta kaip didesnio funkcionalumo dalis, vėliau gali būti pakartotinai panaudota kaip kitų sistemos dalių priklausomybė, neperrašant logikos. Kadangi paslaugos yra izoliuotos, vienos iš jų gedimas paprastai sukelia dalinį sistemos degradavimą, o ne visišką sistemos sutrikimą, jei atsparumas buvo numatytas nuo pat pradžių.

Architektūrinis ir paslaugų dizainas

Kad mikropaslaugos gerai veiktų gamyboje, būtina pradėti nuo kruopštaus paslaugų ribų ir atsakomybių projektavimo . Praktiškai tai paprastai pradedama nustatant grubiai suskirstytas paslaugas esamame monolite: didelės funkcinės sritys arba verslo sritys (pvz., užsakymai, katalogas, vartotojai, atsiskaitymas), kurios jau yra logiškai atskirtos.

Pradedant nuo šių didelių konstrukcinių blokų, procesas apima projekto tobulinimą, siekiant gauti smulkiai detalizuotas mikropaslaugas, kurios veiktų su nuosekliu duomenų rinkiniu , turėtų savo modelį ir tiksliai žinotų, ką joms reikia skaityti iš kitų paslaugų arba į jas rašyti. Šis procesas paprastai remiasi domeno valdomo projektavimo (DDD) koncepcijomis ir apribotais kontekstais, neleidžiant mikropaslaugai tapti „mini monolitu“.

Šias paslaugas teikiančios API turi turėti aiškiai apibrėžtas ir stabilias sutartis . Tai reiškia griežtą dokumentaciją (REST su OpenAPI, gRPC su .proto failais ir kt.), aiškų versijų kūrimą, atgalinio suderinamumo palaikymą, kur įmanoma, ir sutarčių patvirtinimo automatizavimą, siekiant aptikti svarbius pakeitimus prieš jiems pasiekiant gamybos aplinką.

Aplinkose, kuriose yra dešimtys ar šimtai paslaugų, labai svarbu nuo pat projektavimo etapo įtraukti atsparumo modelius, kad sistema būtų pasirengusi daliniams gedimams . Tokie modeliai kaip grandinės pertraukikliai, pakartotiniai bandymai su atidėjimu, tiksliai apibrėžti skirtieji laikai, pertvaros ir priešslėgis padeda išvengti, kad vienos paslaugos gedimas sutrikdytų kitų veikimą. Chaoso inžinerijos įrankiai, tokie kaip „ChaosMonkey“ ar „Gremlin“, yra naudingi praktiškai testuojant, kaip platforma elgiasi imituojamų sutrikimų atveju.

Daugelyje sudėtingų sistemų derinamos gana paprastos CRUD paslaugos su sudėtingesnėmis, kurios tvarko besikeičiančias verslo taisykles. Ne visoms mikropaslaugoms reikalinga sudėtinga vidinė architektūra : kai kurios gali būti paprasti HTTP valdikliai su pagrindine prieiga prie duomenų, o kitos, pavyzdžiui, užsakymų ar sąskaitų išrašymo paslaugos, gali naudoti sudėtingesnius šablonus (DDD, CQRS, domeno įvykius ir kt.).

Gamybos infrastruktūra: debesija, konteineriai ir „Kubernetes“ / „OpenShift“

Reali patirtis rodo, kad mikropaslaugos veikia daug geriau, kai jos diegiamos debesijos infrastruktūroje su konteineriais ir orkestravimu, nei izoliuotose virtualiose mašinose. Tokios platformos kaip „Kubernetes“ ir „OpenShift“ suteikia reikiamus primityvus elementus paslaugoms pakuoti į konteinerius, mastelio keitimui, atnaujinimui, apkrovos balansavimui ir didelio prieinamumo valdymui.

Paprastai kiekviena mikropaslauga yra supakuota į konteinerio atvaizdą, pagrįstą įmonės baziniu atvaizdu (pvz., „OpenJDK 21“, skirtu „Java“ paslaugoms), kurį tvarko infrastruktūros komanda. Šis bazinis atvaizdas yra nuolat atnaujinamas diegiant saugos pataisas, o išleidus naują versiją, kūrimo komandos yra atsakingos už savo paslaugų atkūrimą ir diegimą atitinkamose aplinkose.

„Kubernetes“ / „OpenShift“ sistemoje pagrindinis diegimo vienetas yra ankštis (ankštis), apimanti vieną ar daugiau konteinerių . Paprastai mikropaslauga atitinka ankšties tipą ir yra diegiama naudojant tokius išteklius kaip diegimai (paslaugoms be būsenos) arba „StatefulSets“ (kai yra susieta būsena). Nuo pat pradžių apibrėžiamas minimalus replikų skaičius kiekvienoje aplinkoje, kad testavimo, ikigamybinė ir gamybinė aplinkos turėtų prieinamumo lygius, atitinkančius jų kritiškumą.

Automatinis mastelio keitimas įgyvendinamas naudojant „HorizontalPodAutoscaler“ (HPA) , kuris koreguoja replikų skaičių pagal tokius rodiklius kaip procesoriaus, atminties ar kitus pasirinktinius rodiklius. Platforma taip pat turi sukonfigūruoti pod anti-afiniteto taisykles, kad tos pačios paslaugos replikos būtų paskirstytos skirtinguose mazguose, neleisdama, kad vieno mazgo gedimas išjungtų visus egzempliorius.

Kalbant apie vertikalų dydžio nustatymą, „resources.requests“ ir „resources.limits“ naudojami norint apibrėžti procesoriaus ir atminties diapazoną, kurį gali sunaudoti konteineris. Pavyzdžiui, rezervuojant mažiausiai 100 MB procesoriaus ir 256 MB atminties, o „Java“ paslaugai leidžiant atitinkamai iki 500 MB ir 2 GB, galima koreguoti JVM („Xms“, „Xmx“, „Xss“), kad būtų tinkamai panaudoti konteinerio ištekliai.

Būsenos valdymas: būsenos neturinčios ir būsenomis paremtos mikropaslaugos

Dauguma verslo mikropaslaugų yra sukurtos kaip paslaugos be būsenos . Tai reiškia, kad ankštyje nėra saugoma informacija, kuri reikalinga norint išlikti po perkrovimo; būsena išsaugoma išorinėse duomenų bazėse, pranešimų eilėse ar kitose saugyklose. Šis metodas palengvina dinaminį horizontalų mastelio keitimą ir sklandų diegimą, nes bet kuri kopija gali apdoroti bet kokią užklausą.

Tačiau pasitaiko situacijų, kai nėra kitos alternatyvos, kaip tik turėti būsenines mikropaslaugas, kurias palaiko nuolatiniai tomai . Taip yra kai kurių duomenų bazių, paskirstytų failų sistemų arba komponentų, kuriems reikia tvarkyti vietinius duomenis, atveju. Šie ankštys paprastai diegiami naudojant „StatefulSets“, susieti su „PersistentVolumes“ naudojant „PersistentVolumeClaims“, ir keičiami vertikaliai, o ne horizontaliai.

Kai mikropaslaugai reikalinga nuolatinė saugykla, pateikiama užklausa „PersistentVolumeClaim“ (PVC) su jos dydžiu, prieigos režimu ir numatytu panaudojimu , o operacijų komanda ją teikia pagal platformos politiką. Šis PVC nurodomas diegimo manifeste ir prijungiamas prie pod, kad paslauga galėtų nuolat skaityti ir rašyti duomenis.

Nors tam tikrais atvejais gali prireikti būsenos modelių, bendra rekomendacija yra kuo daugiau paslaugų išlaikyti be būsenos . Tai supaprastina diegimą, mastelio keitimą, atsparumą ir atkūrimą po nelaimių, taip pat sumažina veikimo sudėtingumą aplinkose, kuriose yra daug mikropaslaugų.

Duomenų decentralizavimas ir paslaugų suverenitetas

Tradicinėse infrastruktūrose įprasta centralizuoti duomenų bazes ir saugyklas, siekiant maksimaliai padidinti efektyvumą. Naudojant mikropaslaugas, šis metodas prieštarauja komandos autonomijai ir atsiejimui . Jei daugelis paslaugų naudoja tą pačią reliacinę schemą, bet koks struktūrinis pakeitimas gali užblokuoti kelias komandas ir netyčia sutrikdyti suderinamumą.

Todėl rekomenduojama, kad kiekviena mikropaslauga turėtų savo duomenų modelį ir duomenų bazę , nors kūrimo aplinkoje ta duomenų bazė veikia kaip konteineris klasteryje, siekiant supaprastinti diegimą. Gamybos aplinkoje paprastai naudojami debesyje valdomi egzemplioriai arba kiti didelio prieinamumo duomenų bazių serveriai, visada išlaikant aiškią nuosavybės ribą.

Tai nereiškia, kad nėra duomenų integracijos; tai reiškia, kad paslaugų nuoseklumas valdomas įvykiais ir asinchroniniu pranešimų siuntimu , priimant galutinį nuoseklumą, kai tai pagrįsta. Įprasta naudoti įvykių magistrales („RabbitMQ“, „Azure Service Bus“, „Kafka“ ir kt.), kad būtų galima perduoti būsenos pokyčius tarp mikropaslaugų, taip sumažinant stiprias priklausomybes nuo vienos duomenų bazės.

Debesijos platforma leidžia komandoms lengvai pasirinkti optimalų duomenų bazės tipą kiekvienai paslaugai (reliacinė, dokumentų, rakto ir reikšmės, laiko eilučių ir kt.), neprimetant vienos technologijos. Svarbiausia, kad projektuojant būtų atsižvelgta į schemų ir struktūrų perkėlimo galimybę nenutraukiant sutarčių su kitomis paslaugomis ir kad sprendimai dėl duomenų būtų priimami atsižvelgiant į kiekvienos mikropaslaugos srities ribas.

Paskirstytas valdymas, komandos ir organizacija

Perėjimas prie mikropaslaugų nekeičiant organizacijos reikalauja problemų. Vietoj klasikinių funkcinių silosų, kuriuos sudaro tinklai, sistemos, duomenų bazės, kūrimas ir operacijos , skatinama struktūra, pagrįsta produktų komandomis, sujungianti kūrimo, kokybės užtikrinimo, „DevOps“ ir, jei taikoma, verslo ar duomenų analitikų profilius.

Kiekviena komanda yra atsakinga už vieną ar daugiau mikropaslaugų toje pačioje funkcinėje srityje, tvarkydama tiek kūrimą, tiek veikimą (jūs kuriate, jūs jį paleidžiate) . Tai reiškia, kad komanda valdo savo CI/CD srautus, bendradarbiauja su infrastruktūra, atsižvelgdama į konkrečius poreikius, ir dalyvauja stebėsenoje bei incidentų reagavime. Infrastruktūra ir debesijos platforma orientuotos į bendrų ir standartizuotų paslaugų teikimą.

Siekiant užkirsti kelią šio paskirstyto valdymo nugrimzdimui į anarchiją, labai svarbu apibrėžti lengvus standartus ir bendrinamus katalogus : patvirtintus bazinius atvaizdus, ​​diegimo modelius, vardų erdvių ir paslaugų pavadinimų suteikimo konvencijas, API gaires, „Dockerfile“ ir „Kustomize“ šablonus ir kt. Šios gairės tarnauja kaip „apsauginės atramos“, kurios padeda komandoms orientuotis netrukdant joms priimti sprendimų.

Daugelyje įmonių aplinkų kiekvienam projektui arba sričiai naudojamos atskiros vardų erdvės , po bent vieną kiekvienai aplinkai (kūrimo, ikigamybinei, gamybinei). Didelis projektas gali paskirstyti savo mikropaslaugas keliose vardų erdvėse, jei tinkamai sukonfigūruotas vidinis ryšys ir laikomasi saugumo taisyklių.

CI/CD, automatizavimas ir „GitOps“ modelis

Kai architektūra apima dešimtis ar šimtus mikropaslaugų, vienintelis būdas jas išlaikyti veikiančias – daug investuoti į visapusišką automatizavimą . Tai apima nuoseklius CI/CD srautus, deklaratyvius diegimo apibrėžimus, automatizuotą testavimą ir automatinius atšaukimo mechanizmus.

Įprastas nuolatinės integracijos ir teikimo srautas tvarko kodo kompiliavimą, testų vykdymą, kokybės analizę naudojant tokius įrankius kaip „SonarQube“ , konteinerio atvaizdo kūrimą iš įmonės „Dockerfile“ ir diegimo manifestų atnaujinimą. Po to sistema, pvz., „ArgoCD“ ar panaši, pritaiko pakeitimus klasteryje naudodama „GitOps“ metodą.

Kiekvienoje mikropaslaugų saugykloje paprastai yra standartizuotas „Dockerfile“, srauto konfigūracijos failas (pvz., ci.json) , kokybės analizės ypatybės ir diegimo katalogas su „Kubernetes“ apibrėžimais („Kustomize“ arba „Helm“), suskirstytais pagal aplinką. Saugyklos žiniatinklio kabliai suaktyvina srautą, kai įvyksta tokie įvykiai kaip žymų perkėlimas arba sujungimo užklausos.

„GitOps“ šablonas nustato „Git“ saugyklą kaip patikimą infrastruktūros ir diegimo informacijos šaltinį . Joje versijos registruojamos diegimo, paslaugų, konfigūracijos žemėlapių, PVC, „SealedSecrets“ ir kitų išteklių manifestai, o specialūs įrankiai sinchronizuoja klasterio būseną su tuo, kas apibrėžta „Git“. Tai užtikrina atsekamumą, užklausų peržiūras ir paprastas atšaukimo galimybes.

Nustatymai, paslaptys ir saugumas

Brandžioje mikropaslaugų platformoje konfigūracijos valdymas remiasi „ConfigMap“ neskelbtiniems parametrams ir „Secrets“ konfidencialios informacijos parametrams . Kiekviena mikropaslauga paprastai turi savo aplinkai būdingą „ConfigMap“, kuriame saugomos tokios savybės kaip priklausomų paslaugų URL, funkcionalumo žymės ir derinimo parametrai.

Paslaptys (kredencialai, raktai, žetonai, sertifikatai) tvarkomos laikantis griežtų saugumo politikų . Mažiau kritinėse aplinkose gali būti priimtina jas laikyti paprasto teksto formatu, kurį tvarko kūrimo komanda, tačiau ikigamybinėje ir gamybinėje aplinkoje rekomenduojama jas užšifruoti naudojant tokias priemones kaip „Sealed Secrets“ arba specialius debesijos pagrindu veikiančius išorinius tvarkytuvus.

Kai slaptą raktą reikia bendrinti kelioms paslaugoms (pvz., „OTEL Collector“ kredencialams arba bendrai raktų saugyklai ), jį galima centralizuoti konfigūracijos saugykloje kiekvienoje vardų erdvėje. Projektai, kurie dalijasi ta vardų erdve, koordinuoja jos atnaujinimą pagal poreikį, išlaikydami kontrolę, kas gali skaityti ar modifikuoti šiuos išteklius.

Kalbant apie ryšių saugumą, dominuojantis modelis yra nulinis pasitikėjimas : niekas nelaikoma savaime suprantamu dalyku vien dėl to, kad srautas yra „vidinis“. Visi skambučiai tarp paslaugų, tiek vidiniai, tiek išoriniai, turi būti autentifikuoti ir autorizuoti, idealiu atveju naudojant mTLS, JWT žetonus ar kitus lygiaverčius mechanizmus. Mikropaslaugos aklai nedeleguoja saugumo API tvarkyklei ar tinklui; jos taip pat atlieka savo patikras.

Ryšys tarp mikropaslaugų, API ir pranešimų siuntimo

Brandžioje mikropaslaugų architektūroje komunikacijos sluoksnis yra padalintas į kelis atvejus. Srautui iš klientų (naršyklių, mobiliųjų programėlių, trečiųjų šalių) į galinę sistemą naudojamos publikuotos API sąsajos, kurias valdo API tvarkyklė . Šios API sąsajos paprastai yra RESTful (dažnai naudojant OpenAPI) arba, kai kuriais atvejais, gRPC, prieinamos per šliuzą.

Skambučius tarp mikropaslaugų, esančių toje pačioje vardų erdvėje arba net keliose to paties projekto vardų erdvėse, paprastai tvarko vidinės „Kubernetes“ paslaugos su vidiniu DNS . Šie skambučiai apeina viešąjį API tvarkytuvą, tačiau laikosi saugumo, autentifikavimo ir autorizacijos politikos. Tokiais atvejais galima naudoti paslaugų tinklą arba vidinius šliuzus, užtikrinančius bendrą politiką.

Kai mikropaslaugos priklauso skirtingoms funkcinėms sritims arba projektams , komunikacija organizacijos lygmeniu laikoma „vieša“. Tokiais atvejais įprasta naudoti API tvarkyklę arba sąveikumo magistralę, kurioje tvarkomos sutartys, kvotos, saugumas, versijų kūrimas ir auditas, užkertant kelią tiesioginiam susiejimui tarp nepriklausomų klasterių ar vardų erdvių.

Kalbant apie integraciją su pasenusiomis arba išorinėmis sistemomis, kurios ne visada gali teikti modernias API sąsajas, įprasta pasikliauti konkrečiomis jungtimis per sąveikumo magistralę . Tokiu būdu mikropaslaugos kalba bendra kalba (pavyzdžiui, įvykiai arba vidinės REST API sąsajos), o jungtis tvarko vertimą į pasenusią sistemą ir iš jos, visada užtikrindama didesnį saugumą.

Be sinchroninio ryšio, svarbų vaidmenį atlieka asinchroninis pranešimų siuntimas . Jis naudojamas procesams atsieti, absorbuoti pikus, skleisti verslo įvykius tarp paslaugų ir pagerinti atsparumą. Kiekvienas įvykis paprastai turi aiškiai apibrėžtą ir versuotą schemą su sekimo mechanizmais, kad būtų išvengta sutrikimų tarp gamintojų ir vartotojų jiems vystantis.

Stebimumas, OTEL kolekcionierius ir veikimas

Sistemoje, sudarytoje iš daugelio mikropaslaugų, diagnozuoti problemą be gero stebimumo yra beveik neįmanoma. Todėl metrikos, centralizuotas registravimas ir paskirstyti pėdsakai yra integruojami nuo pat projektavimo etapo , leidžiant suprasti, kas vyksta tiek paslaugos, tiek platformos lygmenimis.

Centrinis šios schemos komponentas yra „ OpenTelemetry Collector“ (OTEL Collector) , kuris diegiamas vardų erdvėje arba centralizuotai, kad būtų renkami visų komponentų metrikos, žurnalai ir pėdsakai. Mikroservisams tereikia žinoti, kad jie turėtų siųsti savo telemetriją į rinktuvą; rinktuvas tada persiunčia ją stebėjimo sistemoms („Prometheus“, „Grafana“, „Jaeger“, „Elastic“ ir kt.), o tarnybai nereikia žinoti išsamios informacijos.

Infrastruktūros sluoksnyje mazgų lygio rinktuvai ir eksportuotojai naudojami procesoriaus, atminties, disko, tinklo ir žurnalų metrikoms iš podų rinkti ir siųsti atitinkamai į „Prometheus“ ir „Elasticsearch“. Tokios priemonės kaip „Grafana“ ir „Kibana“ naudojamos šiai informacijai vizualizuoti, ataskaitų suvestinėms kurti ir įspėjimams su išmaniosiomis ribomis ir susijusiomis operacijų knygomis apibrėžti.

Kai projektui reikia labai specifinio metrikų ar pėdsakų apdorojimo, jis gali savo vardų erdvėje dislokuoti savo „OTEL Collector“ egzempliorių, jei jis turi veiklos patvirtinimą ir yra aiškus gamybos priežiūros modelis.

Testavimo strategija, sutartys ir vietinės plėtros patirtis

Paskirstytos mikropaslaugų architektūros testavimas reikalauja sudėtingesnės testavimo strategijos nei monolito testavimas. Vienetų testai išlieka būtini, tačiau vis svarbesni tampa sutartiniai testai (API ir įvykiams), integracijos testai tarp paslaugų ir ištisiniai testai, apimantys visus srautus.

Siekiant išvengti suderinamumo problemų, naudojami tokie metodai kaip į vartotoją orientuotas sutarčių testavimas , kai klientai apibrėžia API lūkesčius, o paslaugų teikėjai juos įvykdo. Kiekvienas sutarties pakeitimas yra automatiškai testuojamas CI srautuose, taip užkertant kelią diegimams, kurie sutrikdytų žinomų vartotojų veiklą.

Kai paslaugų skaičius viršija šimtą, visos sistemos replikavimas vietoje tampa nepraktiškas. Todėl kūrimas remiasi priklausomų paslaugų modeliavimu arba tuneliavimu į nuotolines aplinkas . Kūrėjai paprastai paleidžia tik dalį mikropaslaugų, o likusias užblokuoja imitacijomis, klastotėmis ar simuliatoriais arba nukreipia tam tikrus iškvietimus į bendrą integracijos aplinką.

Išsamus testavimas vis dažniau remiasi trumpalaikėmis aplinkomis arba iš funkcijų šakų sukurtomis „peržiūromis“ , kurios sukuria izoliuotą aplinką su su tuo funkcionalumu susijusiomis paslaugomis. Tai sumažina trintį tarp komandų, sumažina „viskas veikia mano kompiuteryje“ efektą ir aptinka integracijos problemas prieš pasiekiant brangesnes aplinkas, pvz., ikigamybinę versiją.

Mikropaslaugų diegimo modeliai gamyboje

Be „Kubernetes“, gamyboje yra keletas mikropaslaugų diegimo modelių, kuriuos verta žinoti, nes jie skirti skirtingiems izoliacijos, kainos ir brandos scenarijams . Vienas seniausių modelių yra keli paslaugų egzemplioriai viename pagrindiniame kompiuteryje, kai vienas fizinis arba virtualus pagrindinis kompiuteris vykdo kelis skirtingų paslaugų egzempliorius, paprastai bendrame programų serveryje.

VM paslaugos egzemplioriaus modelyje kiekviena paslauga yra supakuota kaip VM atvaizdas (pvz., EC2 AMI) ir veikia savo egzemplioriuje. Tai užtikrina tvirtą izoliaciją, tačiau sunaudojama daugiau išteklių ir paleidžiama lėčiau. Tokios priemonės kaip „Packer“ arba debesijos paslaugų teikėjams skirti sprendimai leidžia lengvai generuoti gamybai paruoštus VM atvaizdus.

Šiandien labiausiai paplitęs modelis yra paslaugos egzempliorius konteineryje , kur kiekviena mikropaslauga sukuriama kaip konteinerio atvaizdas ir diegiama orkestravimo įrangoje („Kubernetes“, „OpenShift“ ir kt.). Konteineriai yra lengvesni nei virtualios mašinos, paleidžiami labai greitai ir leidžia supakuoti viską, ko reikia paslaugai, supaprastinant diegimą ir įgalinant automatinį mastelio keitimą.

Galiausiai, išpopuliarėjo serverių neturintys metodai, tokie kaip AWS Lambda . Šie paketai apima funkcijas, kurios reaguoja į HTTP užklausas arba įvykius iš kitų paslaugų (S3, DynamoDB, eilių ir kt.), o vartotojai moka tik už tai, ką naudoja. Šis modelis ypač tinka labai mažoms mikropaslaugoms arba trumpalaikėms įvykių valdomoms užduotims, nors jis įtraukia papildomų aspektų, susijusių su stebimumu, šaltuoju paleidimu ir vykdymo apribojimais.

Praktiškai daugelis organizacijų sukuria hibridinę ekosistemą: pagrindinė sistemos dalis veikia konteineriuose ir orkestratorių įrenginiuose, o tam tikri pagalbiniai komponentai įgyvendinami kaip serverių neturinčios funkcijos arba specializuotos virtualios mašinos, visada su aiškiomis sąsajomis ir aiškiai apibrėžtais protokolais, skirtais juos integruoti į visumą.

Kalbant apie visa tai pritaikant gamybinėje aplinkoje, skirtumą lemia ne tik pasirinkta technologija, bet ir sukurta architektūra, kuri toleruoja gedimus, pritaikoma pagal poreikį, diegiama automatiškai ir yra stebima . Turint su produktais suderintas komandas, gerai valdomas sutartis, decentralizuotus duomenis ir tvirtą debesijos platformą, mikropaslaugos iš pažado tampa veiksmingu ir tvariu būdu plėtoti sudėtingas programas daugelį metų.