Mikropakalpojumu novērojamība piedāvā izkliedētu izsekošanu, metriku un žurnālus neatkarīgos pakalpojumos, savukārt monolītā reģistrēšana koncentrējas uz centralizētiem ierakstiem no vienas lietojumprogrammas. Pareizā izvēle ir atkarīga no sistēmas sarežģītības, mēroga un tā, cik daudz ieskatu komandām ir nepieciešams pakalpojumu mijiedarbībā.
Daudzdimensionāla pieeja, kas apvieno izsekošanas datus, metrikas un žurnālus, lai izprastu uzvedību izkliedētos, neatkarīgi izvietotos pakalpojumos.
Tradicionāla pieeja, kurā viena lietojumprogramma raksta žurnāla ierakstus centralizētos failos vai vienā žurnālu krātuvē atkļūdošanai un auditēšanai.
| Funkcija | Novērojamība mikropakalpojumos | Monolītās sistēmas reģistrēšana |
|---|---|---|
| Arhitektūra | Izplatīts daudzos pakalpojumos | Viena vienota lietojumprogramma |
| Primārie datu tipi | Izsekošana, metrika un žurnāli | Galvenokārt žurnāli, dažreiz metrikas |
| Pieprasījuma izsekošana | Izplatīta izsekošana ar aptverošo kontekstu | Pavedienu lokālā vai sesiju bāzes izsekošana |
| Instrumentu sarežģītība | Augsts — nepieciešama instrumentācija visos pakalpojumos | Zems — pietiek ar vienu žurnāla cauruļvadu |
| Mērogojamība | Horizontāli mērogojas ar pakalpojumu skaitu | Ierobežota ar vienas lietojumprogrammas caurlaidspēju |
| Neveiksmes diagnoze | Norāda, kurš pakalpojums izraisīja latentumu vai kļūdas | Vieglāk viena procesa ietvaros, grūtāk robežās |
| Uzglabāšanas prasības | Liela apjoma, bieži vien laika rindu datubāzes | Vidēji, parasti plakani faili vai viens indekss |
| Ieviešanas izmaksas | Ievērojamas sākotnējās investīcijas | Zemākas sākotnējās iestatīšanas izmaksas |
Mikropakalpojumu novērojamība pieņem, ka nav iespējams iepriekš paredzēt katru kļūmes režīmu, tāpēc tiek apkopoti pietiekami dažādi telemetrijas dati, lai pēc problēmu rašanās uzdotu jaunus jautājumus. Monolītā reģistrēšana izmanto vienkāršāku pieeju: tiek apkopoti pietiekami daudz teksta ierakstu, lai rekonstruētu notikušo pieprasījuma laikā. Pirmā pieeja žurnālus traktē kā vienu signālu starp daudziem, bet otrā pieeja žurnālus traktē kā primāro signālu sistēmas uzvedības izpratnei.
Kad mikropakalpojumu iestatījumos rodas problēmas, inženieri pāriet uz izkliedētajām trasēm, lai precīzi redzētu, kurš pakalpojums radīja latentumu vai atgrieza kļūdu. Monolītā izstrādātāji parasti atver žurnālfailu, meklē laika zīmogu vai lietotāja ID un izlasa secīgus ierakstus. Monolīta ceļš šķiet intuitīvāks, taču tas nedarbojas, kad sistēma kļūst pietiekami liela, ka viens žurnālfails kļūst apgrūtinošs.
Novērojamības steki parasti apvieno instrumentācijas bibliotēku, piemēram, OpenTelemetry, izsekošanas aizmugursistēmu, piemēram, Jaeger vai Tempo, metriku krātuvi, piemēram, Prometheus, un informācijas paneļa slāni, piemēram, Grafana. Monolītai reģistrēšanai bieži vien ir nepieciešams daudz mazāk — reģistrēšanas ietvars, žurnālu nosūtītājs, piemēram, Filebeat, un varbūt ELK vai OpenSearch klasteris. Mikropakalpojumu rīku ķēdei ir nepieciešama lielāka operacionālā brieduma pakāpe, taču tā atmaksājas, kad sistēmas kļūst sarežģītas.
Izkliedētā izsekošana palielina tīkla lēcienus un serializācijas izmaksas, jo posmi tiek izplatīti pāri pakalpojumu robežām, lai gan izlases stratēģijas ļauj pārvaldīt papildu izmaksas. Monolītā reģistrēšana notiek tuvu lietojumprogrammas procesam, tāpēc veiktspējas kritums galvenokārt rodas diska ievades/izvades un žurnāla formatēšanas dēļ. Abas pieejas var pasliktināt veiktspēju, ja reģistrēšana ražošanas vidē tiek atstāta detalizētā līmenī, taču mikropakalpojumu vidēm parasti ir nepieciešama rūpīgāka pielāgošana.
Novērojamība izceļas vidēs ar biežu izvietošanu, poliglotiem pakalpojumiem un komandām, kurām nepieciešama neatkarīga komponentu īpašniecība. Monolītā reģistrēšana joprojām ir piemērota mazākām lietojumprogrammām, mantotajām sistēmām vai scenārijiem, kuros atbilstība normatīvajiem aktiem prasa vienkāršas audita takas. Daudzas organizācijas faktiski izmanto abus — saglabā tradicionālos žurnālus atbilstības nodrošināšanai, vienlaikus pievienojot novērošanas rīkus inženiertehniskai ieskatu iegūšanai.
Ar žurnāliem vien pietiek, lai atkļūdotu jebkuru sistēmu.
Žurnāli labi darbojas monolītos, bet zaudē efektivitāti izkliedētās sistēmās, kur viens pieprasījums skar daudzus pakalpojumus. Metrika un izsekošanas dati aizpilda nepilnības, parādot modeļus un cēloņsakarības, ko žurnāli nevar viegli atklāt.
Novērojamība ir tikai iedomāta reģistrēšana ar jaunu nosaukumu.
Novērojamība ir plašāka disciplīna, kas ietver žurnālus, bet pievieno arī metrikas un pēdas kā pirmās klases signālus. Mērķis mainās no ierakstu meklēšanas uz patvaļīgu jautājumu uzdošanu par sistēmas darbību, neizplatot jaunu kodu.
Monolītām sistēmām nav nepieciešama novērojamība.
Pat atsevišķas lietojumprogrammas gūst labumu no metrikas, izsekošanas datiem un strukturētiem žurnāliem, kad tie sasniedz jēgpilnu mērogu. Novērojamība ir saistīta ar sistēmas stāvokļa izpratni, kas attiecas neatkarīgi no arhitektūras.
Izplatītā izsekošana ir pārāk dārga lietošanai ražošanā.
Mūsdienu izsekošanas sistēmas izmanto uz lietotāju galviņu vai asti balstītu izlasi, lai iegūtu reprezentatīvu pieprasījumu apakškopu. Tas samazina papildu slodzi, vienlaikus nodrošinot pietiekami daudz datu, lai diagnosticētu lielāko daļu problēmu.
Pāreja uz mikropakalpojumiem automātiski uzlabo novērojamību.
Mikropakalpojumi apgrūtina novērojamību, nevis atvieglo to, jo tagad ir jāuzrauga vairāk kustīgu daļu. Bez atbilstošas instrumentācijas un rīkiem redzamība faktiski samazinās, salīdzinot ar labi instrumentētu monolītu.
Izvēlieties mikropakalpojumu novērojamību, ja jūsu sistēma aptver daudzus neatkarīgus pakalpojumus un jums ir jāsaprot starppakalpojumu mijiedarbība reāllaikā. Vienkāršākām lietojumprogrammām, kur centralizēti ieraksti nodrošina pietiekamu redzamību un darbības izmaksas ir svarīgākas par detalizētu ieskatu, izvēlieties monolītu reģistrēšanu. Praksē nobriedušas sistēmas bieži vien apvieno abas pieejas, nevis pilnībā apņemas izmantot vienu.
Adaptīvā infrastruktūra dinamiski pielāgojas mainīgajām darba slodzēm, izmantojot automatizāciju un mērogošanu reāllaikā, savukārt statiskās infrastruktūras dizains balstās uz fiksētiem, iepriekš konfigurētiem resursiem. Izvēle starp tiem ir atkarīga no darba slodzes mainīguma, budžeta paredzamības un darbības brieduma jūsu mākoņvidē.
Augstas caurlaidspējas apkalpošanas sistēmas apstrādā milzīgu pieprasījumu apjomu ar milisekundes līmeņa latentumu, nodrošinot ieteikumu dzinēju un reklāmu platformu darbību. API ar mazu datplūsmu apkalpo mazākas lietotāju bāzes, kur vienkāršība, izmaksu efektivitāte un uzturēšanas vieglums ir svarīgāki par neapstrādātu mērogu.
Augstas caurlaidspējas ieteikumu apkalpošana koncentrējas uz miljonu vienumu ranžēšanu katrā pieprasījumā plašā mērogā, savukārt zemas latentuma API sistēmas piešķir prioritāti ātram, paredzamam atbildes laikam vispārējas nozīmes vaicājumiem. Abas pieprasa veiktspēju zem 100 ms, bet risina fundamentāli atšķirīgas inženiertehniskās problēmas mūsdienu mākoņinfrastruktūrā.
Šis salīdzinājums izvērtē Amazon Web Services un Google Cloud, analizējot to pakalpojumu piedāvājumus, cenu modeļus, globālo infrastruktūru, veiktspēju, izstrādātāju pieredzi un optimālos lietošanas gadījumus, palīdzot organizācijām izvēlēties mākoņplatformu, kas vislabāk atbilst to tehniskajām un biznesa prasībām.
Baitu nobīdes kontrolpunkti un bezstāvokļa atkopšana ir principiāli atšķirīgas pieejas kļūdu tolerancei izkliedētās sistēmās, kur pirmā saglabā precīzas straumes pozīcijas precīzai atsākšanas iespējai, bet otrā atjauno stāvokli no nulles, izmantojot nemainīgus datu avotus, aizstājot krātuves pieskaitāmās izmaksas rekonstrukcijas vienkāršības labad.
