- Lai mikropakalpojumi būtu dzīvotspējīgi ražošanā, ir nepieciešama rūpīga pakalpojumu, datu, noturības un līgumu izstrāde.
- Kubernetes/OpenShift, CI/CD un GitOps nodrošina liela mēroga izvietošanas, mērogošanas un darbības automatizāciju.
- Nulles uzticēšanās drošība, stabila konfigurācijas pārvaldība un novērojamība ar OpenTelemetry ir platformas pamatprincipi.
- Produktu komandas organizācija un izkliedētā pārvaldība ir tikpat svarīga kā izvēlētā tehnoloģija.
Mikropakalpojumu arhitektūras ieviešana reālā vidē nenozīmē tikai monolīta sadalīšanu mazākos elementos; tā ietver infrastruktūras, komandu, procesu, datu, drošības un darbību pārdomāšanu . Kad sistēma pāriet no teorijas uz ražošanas klasteri, rodas problēmas saistībā ar pakalpojumu atklāšanu, līgumiem starp komandām, CI/CD, novērojamību, noturību un mērogojamību. Ja šīs problēmas netiek pareizi risinātas, tās var pārvērst mikropakalpojumus izkliedētā haosā.
Labā ziņa ir tā, ka šodien mums ir uzkrāta bagātīga pieredze no tādām organizācijām kā Netflix, Amazon, Google un citiem lieliem uzņēmumiem, kas ražošanas vidē pārvalda simtiem mikropakalpojumu . Balstoties uz šīm atziņām, kā arī uz labāko praksi uzņēmumu vidē, izmantojot Kubernetes un OpenShift, mēs varam izstrādāt ļoti stabilu pieeju mikropakalpojumu projektēšanai, ieviešanai un darbībai plašā mērogā, nezaudējot kontroli.
Kāpēc izvietot mikropakalpojumus ražošanas vidē (un kad tas nav tā vērts)
Labi izstrādāta mikropakalpojumu arhitektūra ļauj strādāt ar nelielām, autonomām un daudzfunkcionālām komandām , kas uzņemas atbildību par pakalpojumu no sākuma līdz beigām. Katra komanda darbojas precīzi definētā kontekstā, var bieži izvietot un uzņemties pilnu atbildību par savu pakalpojumu, samazinot izstrādes cikla laiku un paātrinot jaunu funkciju piegādi.
Vēl viena būtiska priekšrocība ir neatkarīga mērogošana katram pakalpojumam . Jums nav jāpārmēro visa lietojumprogramma, ja tikai katalogā, norēķinu lapā vai publiskajā API ir datplūsmas pieaugums. Jūs varat pielāgot katru mikropakalpojumu horizontāli vai vertikāli atbilstoši tā slodzes modelim, precīzi izmērīt katras funkcijas izmaksas un saglabāt pieejamību pat tad, ja konkrētā apgabalā ir patēriņa pieaugums.
Šo pakalpojumu pakotnes un izvietošanas veids atvieglo nepārtrauktu ieviešanu ar zemu risku . Katra mikropakalpojuma neatkarīga izlaišana ievērojami vienkāršo jaunu ideju testēšanu un problemātisko versiju atjaunošanu: nekonsekventa izvietošana, zilās/zaļās atcelšanas un automatizētas atcelšanas samazina kļūmju izmaksas un nodrošina iespēju eksperimentiem.
No tehnoloģiskā viedokļa mikropakalpojumi veicina brīvību izvēlēties valodas, ietvarus un datubāzes katram pakalpojumam. Ne visas vajadzības ietilpst vienā tehnoloģiju grupā: jums var būt biznesa pakalpojumi .NET vai Java valodā, datu apstrāde Scala/Spark valodā, specializēti pakalpojumi Python vai F# valodā vai mākslīgā intelekta mikropakalpojumi R valodā. Šī kontrolētā daudzveidība ļauj jums izmantot pareizo rīku katram gadījumam, nepiespiežot visu lietojumprogrammu globālām tehnoloģiskām pārmaiņām.
Turklāt sistēmas sadalīšana mazos, precīzi definētos elementos atvieglo funkcionalitāšu atkārtotu izmantošanu kā pamatelementus . Mikropakalpojumu, kas sākotnēji izveidots kā daļa no lielākas funkcionalitātes, vēlāk var atkārtoti izmantot kā citu sistēmas daļu atkarību, nepārrakstot loģiku. Un, tā kā pakalpojumi ir izolēti, viena no tiem kļūme parasti izraisa daļēju sistēmas degradāciju, nevis pilnīgu sistēmas darbības pārtraukumu, ja vien noturība ir paredzēta jau no paša sākuma.
Arhitektūras un pakalpojumu dizains
Lai mikropakalpojumi labi darbotos ražošanas vidē, ir svarīgi sākt ar rūpīgu pakalpojumu robežu un atbildības izstrādi . Praktiski tas parasti sākas ar rupji detalizētu pakalpojumu identificēšanu esošajā monolītā: lielas funkcionālās zonas vai biznesa domēni (piemēram, pasūtījumi, katalogs, lietotāji, norēķini), kuriem jau ir zināma loģiska atdalīšana.
Sākot ar šiem lielajiem pamatelementiem, process ietver dizaina pilnveidošanu, lai iegūtu smalki detalizētus mikropakalpojumus, kas darbojas ar saskaņotu datu kopu , kam ir savs modelis un kas precīzi zina, kas tiem ir jālasa no citiem pakalpojumiem vai jāraksta tajos. Šis process parasti balstās uz domēna vadītas dizaina (DDD) koncepcijām un ierobežotiem kontekstiem, neļaujot mikropakalpojumam kļūt par "mini monolītu".
API, kas nodrošina šo pakalpojumu pieejamību, ir jābūt precīzi definētiem un stabiliem līgumiem . Tas nozīmē stingru dokumentāciju (REST ar OpenAPI, gRPC ar .proto failiem utt.), skaidru versiju veidošanu, iespēju robežās atpakaļsaderības saglabāšanu un līgumu validācijas automatizāciju, lai atklātu bojātas izmaiņas, pirms tās nonāk ražošanas vidē.
Vidēs ar desmitiem vai simtiem pakalpojumu ir svarīgi iekļaut noturības modeļus jau no projektēšanas stadijas, lai sistēma būtu sagatavota daļējām kļūmēm . Tādi modeļi kā ķēdes pārtraucēji, atkārtoti mēģinājumi ar pārtraukumu, precīzi definēti taimauti, starpsienas un pretspiediens palīdz novērst to, ka viena pakalpojuma kļūme izraisa pārējo pakalpojuma darbības pārtraukumu. Haosa inženierijas rīki, piemēram, ChaosMonkey vai Gremlin, ir noderīgi, lai praktiski pārbaudītu platformas darbību simulētu pārtraukumu gadījumā.
Daudzas sarežģītas sistēmas apvieno relatīvi vienkāršus CRUD pakalpojumus ar sarežģītākiem pakalpojumiem, kas apstrādā mainīgus biznesa noteikumus. Ne visiem mikropakalpojumiem ir nepieciešama sarežģīta iekšējā arhitektūra : daži var būt vienkārši HTTP kontrolieri ar pamata piekļuvi datiem, savukārt citi, piemēram, pasūtījumu vai rēķinu izrakstīšanas pakalpojumi, var izmantot sarežģītākus modeļus (DDD, CQRS, domēna notikumus utt.).
Ražošanas infrastruktūra: mākonis, konteineri un Kubernetes/OpenShift
Reālā pieredze rāda, ka mikropakalpojumi darbojas daudz labāk, ja tie tiek izvietoti mākoņinfrastruktūrā ar konteineriem un orķestrēšanu, nekā uz izolētām virtuālajām mašīnām. Tādas platformas kā Kubernetes un OpenShift nodrošina nepieciešamos primitīvus pakalpojumu iesaiņošanai konteineros, mērogošanai, atjaunināšanai, slodzes līdzsvarošanai un augstas pieejamības pārvaldībai.
Parasti katrs mikropakalpojums ir iepakots konteinera attēlā, kura pamatā ir korporatīvais bāzes attēls (piemēram, OpenJDK 21 Java pakalpojumiem), ko pārvalda infrastruktūras komanda. Šis bāzes attēls tiek atjaunināts ar drošības ielāpiem, un, izlaižot jaunu versiju, izstrādātāju komandas ir atbildīgas par savu pakalpojumu atjaunošanu un atkārtotu izvietošanu atbilstošajās vidēs.
Kubernetes/OpenShift vidē pamata izvietošanas vienība ir pods, kas iekapsulē vienu vai vairākus konteinerus . Parasti mikropakalpojums atbilst poda tipam un tiek izvietots, izmantojot tādus resursus kā izvietojumi (bezvalsts pakalpojumiem) vai StatefulSets (ja ir saistīts stāvoklis). Jau no paša sākuma tiek definēts minimālais repliku skaits katrā vidē, lai testēšanas, pirmsražošanas un ražošanas vidēm būtu to kritiskumam atbilstoši pieejamības līmeņi.
Automātiska mērogošana tiek ieviesta, izmantojot HorizontalPodAutoscaler (HPA) , kas pielāgo repliku skaitu, pamatojoties uz tādiem rādītājiem kā centrālā procesora jauda, atmiņa vai citi pielāgoti rādītāji. Platformai ir arī jākonfigurē pod anti-afinitātes noteikumi, lai izplatītu viena un tā paša pakalpojuma replikas dažādos mezglos, novēršot visu instanču apturēšanu viena mezgla kļūmes dēļ.
Attiecībā uz vertikālo izmēru noteikšanu resources.requests un resources.limits tiek izmantoti , lai definētu centrālā procesora un atmiņas diapazonu, ko pods var patērēt. Piemēram, rezervējot vismaz 100 MB centrālā procesora un 256 MB atmiņas, un atļaujot attiecīgi līdz 500 MB un 2 GB Java pakalpojumam, pielāgojot JVM (Xms, Xmx, Xss), lai lietderīgi izmantotu konteinera resursus.
Valsts pārvaldība: bezvalstnieki un stāvokļiem atbilstoši mikropakalpojumi
Lielākā daļa biznesa mikropakalpojumu ir izstrādāti kā bezstāvokļa pakalpojumi . Tas nozīmē, ka podā netiek glabāta informācija, kas nepieciešama, lai izdzīvotu pēc atkārtotas palaišanas; stāvoklis tiek saglabāts ārējās datubāzēs, ziņojumu rindās vai citās krātuvēs. Šī pieeja atvieglo dinamisku horizontālu mērogošanu un netraucētu izvietošanu, jo jebkura kopija var apstrādāt jebkuru pieprasījumu.
Tomēr pastāv scenāriji, kad nav citas alternatīvas, kā vien pastāvīgie sējumi atbalstīt stāvokļu mikropakalpojumus . Tas attiecas uz dažām datubāzēm, izkliedētām failu sistēmām vai komponentiem, kuriem nepieciešama lokālu datu uzturēšana. Šie podi parasti tiek izvietoti ar StatefulSets, saistīti ar PersistentVolumes, izmantojot PersistentVolumeClaims, un mērogoti vertikāli, nevis horizontāli.
Ja mikropakalpojumam ir nepieciešama pastāvīga krātuve, tiek pieprasīts PersistentVolumeClaim (PVC) pieprasījums ar tā lielumu, piekļuves režīmu un paredzēto lietojumu , un operāciju komanda to nodrošina saskaņā ar platformas politikām. Šis PVC ir norādīts izvietošanas manifestā un pievienots podam, lai pakalpojums varētu pastāvīgi lasīt un rakstīt datus.
Lai gan konkrētos gadījumos var būt nepieciešami stāvokļu modeļi, vispārējais ieteikums ir saglabāt pēc iespējas vairāk pakalpojumu bez stāvokļiem . Tas vienkāršo izvietošanu, mērogošanu, noturību un atkopšanu pēc katastrofām, kā arī samazina darbības sarežģītību vidēs ar daudziem mikropakalpojumiem.
Datu decentralizācija un pakalpojumu suverenitāte
Tradicionālajās infrastruktūrās ir ierasts centralizēt datubāzes un krātuvi, lai palielinātu efektivitāti. Izmantojot mikropakalpojumus, šī pieeja ir pretrunā ar komandas autonomiju un atdalīšanu . Ja daudziem pakalpojumiem ir viena un tā pati relāciju shēma, jebkuras strukturālas izmaiņas var bloķēt vairākas komandas un netīši pārtraukt saderību.
Tāpēc ieteicamā prakse ir tāda, lai katram mikropakalpojumam būtu savs datu modelis un datubāze , lai gan izstrādes vidē šī datubāze darbojas kā konteiners klasterī, lai vienkāršotu izvietošanu. Ražošanā parasti tiek izmantotas mākonī pārvaldītas instances vai citi augstas pieejamības datubāzes serveri, vienmēr saglabājot skaidru īpašumtiesību robežu.
Tas nenozīmē, ka nav datu integrācijas; tas nozīmē, ka pakalpojumu konsekvence tiek pārvaldīta ar notikumiem un asinhronu ziņojumapmaiņu , pieņemot galīgo konsekvenci, kad tas ir saprātīgi. Bieži tiek izmantota notikumu kopne (RabbitMQ, Azure Service Bus, Kafka utt.), lai izplatītu stāvokļa izmaiņas starp mikropakalpojumiem, samazinot spēcīgas atkarības no vienas datubāzes.
Mākoņplatforma ļauj komandām viegli izvēlēties optimālo datubāzes veidu katram pakalpojumam (relāciju, dokumentu, atslēgas-vērtības, laika rindas utt.), neuzspiežot vienu konkrētu tehnoloģiju. Galvenais ir tas, ka projektēšanā tiek ņemta vērā shēmu un struktūru migrācijas iespēja, nepārkāpjot līgumus ar citiem pakalpojumiem, un ka lēmumi par datiem tiek pieņemti atbilstoši katra mikropakalpojuma domēna robežām.
Decentralizēta pārvaldība, komandas un organizācija
Pāreja uz mikropakalpojumiem, nemainot organizāciju, rada problēmas. Klasisko funkcionālo silo vietā, kas sastāv no tīkliem, sistēmām, datubāzēm, izstrādes un darbības , tiek veicināta struktūra, kuras pamatā ir produktu komandas, apvienojot izstrādes, kvalitātes nodrošināšanas, DevOps un, attiecīgā gadījumā, biznesa vai datu analītiķu profilus.
Katra komanda ir atbildīga par vienu vai vairākiem mikropakalpojumiem vienā un tajā pašā funkcionālajā jomā, veicot gan izstrādi, gan darbību (jūs to veidojat, jūs to darbināt) . Tas nozīmē, ka komanda pārvalda savus CI/CD cauruļvadus, sadarbojas ar infrastruktūru specifisku vajadzību nodrošināšanai un piedalās uzraudzībā un incidentu reaģēšanā. Infrastruktūra un mākoņplatforma koncentrējas uz kopīgu un standartizētu pakalpojumu sniegšanu.
Lai novērstu šīs izkliedētās pārvaldības ieslīgšanu anarhijā, ir svarīgi definēt vieglus standartus un koplietojamus katalogus : apstiprinātus bāzes attēlus, izvietošanas modeļus, nosaukumu piešķiršanas konvencijas vārdtelpām un pakalpojumiem, API vadlīnijas, Dockerfile un Kustomize veidnes utt. Šīs vadlīnijas kalpo kā "aizsargmargas", kas orientē komandas, neierobežojot to spēju pieņemt lēmumus.
Daudzās uzņēmumu vidēs katram projektam vai domēnam tiek izmantotas atsevišķas vārdtelpas , vismaz pa vienai katrai videi (izstrāde, pirmsražošana, ražošana). Liels projekts var izplatīt savus mikropakalpojumus vairākās vārdtelpās, ja vien iekšējā komunikācija ir pareizi konfigurēta un tiek ievēroti drošības noteikumi.
CI/CD, automatizācija un GitOps modelis
Ja arhitektūra ietver desmitiem vai simtiem mikropakalpojumu, vienīgais veids, kā tos uzturēt darbspējīgus, ir veikt ievērojamus ieguldījumus pilnīgas automatizācijas procesā . Tas ietver konsekventus CI/CD cauruļvadus, deklaratīvas izvietošanas definīcijas, automatizētu testēšanu un automātiskus atcelšanas mehānismus.
Tipisks nepārtrauktas integrācijas un piegādes cauruļvads apstrādā koda kompilēšanu, testu veikšanu, kvalitātes analīzi ar tādiem rīkiem kā SonarQube , konteinera attēla izveidi no korporatīvā Dockerfile un izvietošanas manifestu atjaunināšanu. Pēc tam sistēma, piemēram, ArgoCD vai līdzīga, piemēro izmaiņas klasterī, izmantojot GitOps pieeju.
Katrā mikropakalpojumu repozitorijā parasti ir iekļauts standartizēts Dockerfile fails, cauruļvada konfigurācijas fails (piemēram, ci.json) , kvalitātes analīzes īpašības un izvietošanas direktorijs ar Kubernetes definīcijām (Kustomize vai Helm), kas atdalītas pēc vides. Repozitorija tīmekļa āķi aktivizē cauruļvadu, kad notiek tādi notikumi kā tagu nosūtīšana vai apvienošanas pieprasījumi.
GitOps modelis nosaka Git repozitoriju kā patiesības avotu infrastruktūrai un izvietošanai . Tur tiek versijas izvietošanas, pakalpojumu, konfigurācijas karšu, PVC, SealedSecrets un citu resursu manifestiem, un īpaši rīki apstrādā klastera stāvokļa sinhronizāciju ar Git definēto. Tas nodrošina izsekojamību, pieprasījumu pārskatīšanu un vienkāršas atcelšanas iespējas.
Iestatījumi, noslēpumi un drošība
Nobriedušā mikropakalpojumu platformā konfigurācijas pārvaldība balstās uz ConfigMap nesensitīviem parametriem un Secrets konfidenciālai informācijai . Katram mikropakalpojumam parasti ir sava videi specifiska ConfigMap, kurā tiek glabāti tādi rekvizīti kā atkarīgo pakalpojumu URL, funkcionalitātes karodziņi un regulēšanas parametri.
Noslēpumi (akreditācijas dati, atslēgas, žetoni, sertifikāti) tiek apstrādāti, ievērojot stingras drošības politikas . Mazāk kritiskās vidēs var būt pieņemami tos glabāt vienkāršā tekstā, ko pārvalda izstrādātāju komanda, taču pirmsražošanas un ražošanas vidēs ieteicams tos šifrēt, izmantojot tādus rīkus kā Sealed Secrets vai īpašus mākonī balstītus ārējos pārvaldniekus.
Ja slepenais kods ir jākoplieto starp vairākiem pakalpojumiem (piemēram, OTEL Collector akreditācijas dati vai kopīga atslēgu krātuve ), to var centralizēt konfigurācijas repozitorijā katrai vārdtelpai. Projekti, kas koplieto šo vārdtelpu, koordinē tās atjaunināšanu pēc nepieciešamības, saglabājot kontroli pār to, kas var lasīt vai modificēt šos resursus.
Runājot par komunikāciju drošību, dominējošais modelis ir nulles uzticēšanās : nekas netiek uzskatīts par pašsaprotamu tikai tāpēc, ka datplūsma ir "iekšēja". Visiem zvaniem starp pakalpojumiem, gan iekšējiem, gan ārējiem, jābūt autentificētiem un autorizētiem, ideālā gadījumā izmantojot mTLS, JWT žetonus vai citus līdzvērtīgus mehānismus. Mikropakalpojumi akli nedeleģē drošību API pārvaldniekam vai tīklam; tie veic arī savas pārbaudes.
Saziņa starp mikropakalpojumiem, API un ziņojumapmaiņu
Nobriedušā mikropakalpojumu arhitektūrā komunikācijas slānis ir sadalīts vairākos gadījumos. Datplūsmai no klientiem (pārlūkprogrammām, mobilajām lietotnēm, trešajām pusēm) uz aizmugursistēmu tiek izmantotas publicētas API, kuras pārvalda API pārvaldnieks . Šīs API parasti ir RESTful (bieži vien izmantojot OpenAPI) vai dažos gadījumos gRPC, kas ir pieejams caur vārteju.
Izsaukumus starp mikropakalpojumiem, kas atrodas vienā un tajā pašā vārdtelpā vai pat vairākās vārdtelpās viena projekta ietvaros, parasti apstrādā iekšējie Kubernetes pakalpojumi ar iekšējo DNS . Šie izsaukumi apiet publisko API pārvaldnieku, bet ievēro drošības, autentifikācijas un autorizācijas politikas. Šādos scenārijos var izmantot pakalpojumu tīklu vai iekšējās vārtejas, kas nodrošina kopīgu politiku ievērošanu.
Ja mikropakalpojumi pieder dažādām funkcionālām jomām vai projektiem , komunikācija organizācijas līmenī tiek uzskatīta par “publisku”. Šādos gadījumos ir ierasta prakse izmantot API pārvaldnieku vai sadarbspējas kopni, kur tiek pārvaldīti līgumi, kvotas, drošība, versiju veidošana un auditēšana, novēršot tiešu savienošanu starp neatkarīgiem klasteriem vai nosaukumtelpām.
Attiecībā uz integrāciju ar mantotajām vai ārējām sistēmām, kas ne vienmēr var nodrošināt modernus API, ir ierasts paļauties uz īpašiem savienotājiem sadarbspējas kopnē . Tādā veidā mikropakalpojumi runā kopīgā valodā (piemēram, notikumi vai iekšējie REST API), un savienotājs apstrādā tulkošanu uz mantoto sistēmu un no tās, vienmēr ar uzlabotu drošību.
Papildus sinhronajai komunikācijai galveno lomu spēlē asinhronā ziņojumapmaiņa . To izmanto, lai atdalītu procesus, absorbētu impulsus, izplatītu biznesa notikumus starp pakalpojumiem un uzlabotu noturību. Katram notikumam parasti ir precīzi definēta un versiju shēma ar izsekošanas mehānismiem, lai novērstu sabrukumu starp ražotājiem un patērētājiem, tiem attīstoties.
Novērojamība, OTEL savācējs un darbība
Sistēmā, kas sastāv no daudziem mikropakalpojumiem, problēmas diagnosticēšana bez labas novērojamības ir gandrīz neiespējama. Tāpēc metrika, centralizēta reģistrēšana un izkliedētas izsekošanas ir integrētas jau no projektēšanas stadijas , ļaujot izprast, kas notiek gan pakalpojuma, gan platformas līmenī.
Šīs shēmas centrālā sastāvdaļa ir OpenTelemetry Collector (OTEL Collector) , kas tiek izvietots vārdtelpā vai centralizēti, lai apkopotu metriku, žurnālus un izsekošanas datus no visiem komponentiem. Mikropakalpojumiem ir jāzina tikai tas, ka tiem jānosūta telemetrija uz Collector; pēc tam Collector to pārsūta uz novērošanas sistēmām (Prometheus, Grafana, Jaeger, Elastic utt.), pakalpojumam nezinot sīkāku informāciju.
Infrastruktūras slānim mezglu līmeņa kolektori un eksportētāji tiek izmantoti , lai apkopotu centrālā procesora, atmiņas, diska, tīkla un žurnālu metrikas no podiem un nosūtītu tās attiecīgi uz Prometheus un Elasticsearch. Tādi rīki kā Grafana un Kibana tiek izmantoti, lai vizualizētu šo informāciju, izveidotu informācijas paneļus un definētu brīdinājumus ar viedajiem sliekšņiem un saistītajām izpildes grāmatām.
Ja projektam ir nepieciešama ļoti specifiska metriku vai izsekošanas apstrāde, tas var izvietot savu OTEL Collector instanci savā vārdtelpā, ja vien tam ir darbības apstiprinājums un ražošanas uzturēšanas modelis ir skaidrs.
Testēšanas stratēģija, līgumi un vietējās attīstības pieredze
Izplatītu mikropakalpojumu arhitektūras testēšanai ir nepieciešama sarežģītāka testēšanas stratēģija nekā monolīta testēšanai. Vienību testi joprojām ir svarīgi, taču arvien svarīgāki kļūst līgumtesti (API un notikumiem), integrācijas testi starp pakalpojumiem un pilna cikla testi, kas aptver visas plūsmas.
Lai novērstu saderības problēmas, tiek izmantotas tādas metodes kā uz patērētāju orientēta līgumu testēšana , kur klienti definē API cerības un pakalpojumu sniedzēji tās izpilda. Katras līguma izmaiņas tiek automātiski pārbaudītas CI cauruļvados, novēršot izvietošanu, kas bojā zināmus patērētājus.
Kad pakalpojumu skaits pārsniedz simtu, visas sistēmas lokāla replicēšana kļūst nepraktiska. Tāpēc izstrāde balstās uz atkarīgo pakalpojumu simulācijām vai tunelēšanu uz attālām vidēm . Izstrādātāji parasti palaiž tikai daļu mikropakalpojumu un pārējos aizstāj ar imitācijām, viltojumiem vai simulatoriem, vai novirza noteiktus izsaukumus uz koplietojamu integrācijas vidi.
Pilnīga testēšana arvien vairāk balstās uz īslaicīgām vidēm vai "priekšskatījumiem", kas izveidoti no funkciju zariem , kuri izveido izolētu vidi ar pakalpojumiem, kas attiecas uz šo funkcionalitāti. Tas samazina berzi starp komandām, samazina efektu "tas darbojas manā datorā" un atklāj integrācijas problēmas, pirms nonāk dārgākās vidēs, piemēram, pirmsražošanas vidē.
Mikropakalpojumu izvietošanas modeļi ražošanas vidē
Papildus Kubernetes ir vairāki mikropakalpojumu izvietošanas modeļi ražošanas vidē, kas ir vērts zināt, jo tie risina dažādus izolācijas, izmaksu un brieduma scenārijus . Viens no vecākajiem modeļiem ir vairāki pakalpojumu gadījumi katrā resursdatorā, kur viens fizisks vai virtuāls resursdators darbina vairākus dažādu pakalpojumu gadījumus, parasti koplietojamā lietojumprogrammu serverī.
Katras virtuālās mašīnas pakalpojuma instances modelī katrs pakalpojums ir iepakots kā virtuālās mašīnas attēls (piemēram, EC2 AMI) un darbojas savā instancē. Tas nodrošina spēcīgu izolāciju, taču tas nozīmē lielāku resursu patēriņu un lēnāku startēšanas laiku. Tādi rīki kā Packer vai mākoņpakalpojumu sniedzējiem specifiski risinājumi atvieglo ražošanai gatavu virtuālās mašīnas attēlu ģenerēšanu.
Visizplatītākais modelis mūsdienās ir pakalpojuma instance katrā konteinerā , kur katrs mikropakalpojums tiek veidots kā konteinera attēls un izvietots orķestratorā (Kubernetes, OpenShift utt.). Konteineri ir vieglāki nekā virtuālās mašīnas, tiek ļoti ātri palaisti un ļauj pakot visu nepieciešamo pakalpojumam, vienkāršojot izvietošanu un nodrošinot automātisku mērogošanu.
Visbeidzot, popularitāti ir ieguvušas bezserveru pieejas, piemēram, AWS Lambda . Šīs pakotnes funkcijas, kas reaģē uz HTTP pieprasījumiem vai notikumiem no citiem pakalpojumiem (S3, DynamoDB, rindām utt.), lietotājiem maksājot tikai par to, ko viņi izmanto. Šis modelis ir īpaši piemērots ļoti maziem mikropakalpojumiem vai īslaicīgiem notikumu vadītiem uzdevumiem, lai gan tas ievieš papildu apsvērumus par novērojamību, auksto startēšanu un izpildes ierobežojumiem.
Praksē daudzas organizācijas galu galā izveido hibrīda ekosistēmu: sistēmas pamatdaļa darbojas uz konteineriem un orķestratoriem, savukārt atsevišķi palīgkomponenti tiek ieviesti kā bezservera funkcijas vai kā specializētas virtuālās mašīnas, vienmēr ar skaidrām saskarnēm un precīzi definētiem protokoliem, lai tos integrētu veselumā.
Runājot par visa šī ieviešanu ražošanā, atšķirību rada ne tikai izvēlētā tehnoloģija, bet arī tādas arhitektūras izveide, kas pieļauj kļūdas, mērogojas tur, kur nepieciešams, tiek izvietota automātiski un ir novērojama . Ar produktu saskaņotām komandām, labi pārvaldītiem līgumiem, decentralizētiem datiem un stabilu mākoņplatformu mikropakalpojumi no solījuma kļūst par efektīvu un ilgtspējīgu veidu, kā attīstīt sarežģītas lietojumprogrammas gadiem ilgi.