Service mesh izmantoŔanas scenāriji

Service mesh izmantoŔanas scenāriji

PiezÄ«me:: Ŕī raksta autors (Luc Perkins) — izstrādātāju advokāts organizācijā CNCF, kas ir mājvieta tādiem open-source projektiem kā Linkerd, SMI (Service Mesh Interface) un Kuma (starpcitu, vai esat kādreiz domājuÅ”i, kāpēc Å”ajā sarakstā nav Istio?..). Atkal cenÅ”oties ieviest DevOps kopienā labāku izpratni par modÄ«gu burbuli ar nosaukumu Ā«service meshĀ», viņŔ izklāsta 16 raksturÄ«gas iespējas, ko sniedz Ŕādas risinājumus.

MÅ«sdienās pakalpojumu tÄ«kls ― viena no karstākajām tēmām programmatÅ«ras inženierijā (un pamatoti!). Es uzskatu, ka Ŕī tehnoloÄ£ija ir neticami perspektÄ«va un sapņoju redzēt tās plaÅ”u izplatÄ«bu (protams, kad tam ir jēga). Tomēr tā joprojām ir apvÄ«ta noslēpumainÄ«bas aurā vairumam cilvēku. Turklāt pat tie, kas ir labi pazÄ«stami ar to, bieži vien grÅ«tÄ«bas atrast formulējumu tās priekÅ”rocÄ«bām un tam, ko tā tieÅ”i sevÄ« ietver (ieskaitot jÅ«su paklausÄ«go kalpu). Å ajā rakstā es mēģināŔu labot situāciju, uzskaitot dažādus lietojuma scenārijus Ā«pakalpojumu tÄ«klamĀ»*.

* Piezīme. tulk.: Ŕeit un turpmāk rakstā tiks izmantots tieŔi Ŕāds tulkojums («pakalpojumu tīkls») jaunajam terminam service mesh.

Bet vispirms vēlos izdarīt dažus novērojumus:

  • Es nekad neesmu strādājis ar pakalpojumu tÄ«kliem un neesmu tos izmantojis ārpus projektiem, kas tika uzsākti manas izglÄ«tÄ«bas labad. No otras puses, tieÅ”i es uzrakstÄ«ju daudz dokumentācijas iekŔējā service mesh uzņēmumā Twitter 2015. gadā (toreiz vēl pat netika dēvēts par Ā«pakalpojumu tÄ«kluĀ») un piedalÄ«jos tÄ«mekļa vietnes un dokumentācijas izstrādē, Linkerd, tāpēc tas kaut ko nozÄ«mē.
  • Mans saraksts ir piemērojoÅ”s un nepilnÄ«gs. Ir iespējami man nezināmi lietojuma scenāriji, un ar laiku noteikti radÄ«sies jauni varianti, attÄ«stoties tehnoloÄ£ijai un pieaugot tās popularitātei.
  • Vienlaikus tālu ne katra esoŔā service mesh realizācija atbalsta visus uzskaitÄ«tos lietojuma gadÄ«jumus. Tāpēc mani izteikumi, piemēram, Ā«service mesh var…» ir jālas kā Ā«atseviŔķi, iespējams, arÄ« visi populārie service mesh realizācijas var…».
  • Piemēru secÄ«ba nav nekādā veidā nozÄ«mÄ«ga.

ÄŖss saraksts:

  • pakalpojumu atklāŔana;
  • Å”ifrēŔanu;
  • autentifikācija un autorizācija;
  • slodzes sadalīŔana;
  • circuit breaking;
  • automātiskā mērogoÅ”ana;
  • kanāriju izvietojumi;
  • zilā-zaļā izvietojumi;
  • veselÄ«bas pārbaude;
  • load shedding;
  • trafika spogulēŔana;
  • izolācija;
  • pieprasÄ«jumu skaita ierobežoÅ”ana, atkārtotas mēģinājumi un laika ierobežojumi;
  • telemetrija;
  • audits;
  • vizualizācija.

1. Pakalpojumu atklāŔana

TL;DR: Pievienojieties citiem pakalpojumiem tīklā, izmantojot viegli atpazīstamus nosaukumus.

Pakalpojumiem jābÅ«t spējÄ«giem automātiski Ā«atrastĀ» viens otru, izmantojot atbilstoÅ”us nosaukumus — piemēram, service.api.production, pets/staging vai cassandra. Mākoņu vidēm piemÄ«t elastÄ«ba, un aiz viena nosaukuma var slēpties daudzi pakalpojumu instance. Ir skaidrs, ka Ŕādā situācijā fiziski nav iespējams ierakstÄ«t visus IP adreses.

Turklāt, kad viens pakalpojums atrod citu, tam jābÅ«t spējÄ«gam sÅ«tÄ«t pieprasÄ«jumus Å”im pakalpojumam, neuztraucoties, ka tie nonāks pie tā nedarbojoŔās instances. Citiem vārdiem sakot, service mesh jāuzrauga visu pakalpojumu instance darbspēja un jāatjaunina hostu saraksts maksimāli aktuālā stāvoklÄ«.

Katra service mesh ievieÅ” pakalpojumu atklāŔanas mehānismu savā veidā. PaÅ”reiz visizplatÄ«tākais veids ir deleģēŔana ārējiem procesiem, piemēram, DNS Kubernetes. Pagātnē Twitter Å”iem mērÄ·iem mēs izmantojām nosaukumu sistēmu Finagle. Turklāt service mesh tehnoloÄ£ija padara iespējamu pielāgotu nosaukumu mehānismu parādīŔanos (lai gan es vēl neesmu sastapis nevienu SM ar Ŕādu funkcionalitāti).

2. Å ifrēŔana

TL;DR: AtbrÄ«vojieties no neÅ”ifrēta trafika starp pakalpojumiem, un ļaujiet Å”im procesam bÅ«t automatizētam un skalojamam.

Ir patÄ«kami apzināties, ka ļaunprātÄ«gi lietotāji nevar iekļūt jÅ«su iekŔējā tÄ«klā. TÄ«kla ugunsmÅ«ri lieliski to panāk. Bet kas notiks, ja hakeris tomēr iekļūst iekŔā? Vai viņŔ varēs darÄ«t ar iekŔējo pakalpojumu trafiku visu, ko vēlas? Cerēsim, ka tas tā nenotiks. Lai novērstu lÄ«dzÄ«gu scenāriju, bÅ«tu jāīsteno nulles ticamÄ«bas (zero-trust) tÄ«kls, kurā viss trafiks starp pakalpojumiem ir Å”ifrēts. Lielākā daļa mÅ«sdienu pakalpojumu tÄ«klu to sasniedz, izmantojot savstarpējo TLS (mutual TLS, mTLS). Dažos gadÄ«jumos mTLS darbojas visa mākoņu un klusteru ietvaros (domāju, ka arÄ« starpplanētas komunikācijas kādreiz tiks organizētas lÄ«dzÄ«gi).

Protams, mTLS service mesh nav obligāta. Katrs pakalpojums var pats parÅ«pēties par savu TLS, taču tas nozÄ«mē, ka bÅ«s jāatrod veids, kā Ä£enerēt sertifikātus, izplatÄ«t tos pa pakalpojuma hostiem, iekļaut lietojumprogrammā kodu, kas ielādē Å”os sertifikātus no failiem. Jā, vēl nedrÄ«kst aizmirst par Å”o sertifikātu atjaunināŔanu noteiktos laika posmos. Pakalpojumu tÄ«kli automatizē mTLS, izmantojot sistēmas, piemēram, SPIFFE, kas, savukārt, automatizē sertifikātu izdoÅ”anas un rotācijas procesu.

3. Autentifikācija un autorizācija

TL;DR: Uzziniet, kurÅ” ir pieprasÄ«juma iniciators, un nosakiet, ko viņam ir atļauts darÄ«t vēl pirms pieprasÄ«jums sasniedz pakalpojumu.

Pakalpojumi bieži vēlas zināt, kas kurÅ” izpilda pieprasÄ«jumu (autentifikācija), un, izmantojot Å”o informāciju, izlemj, ko vai konkrētai personai ir atļauts darÄ«t (autorizācija). Å ajā gadÄ«jumā aiz vietniekvārda ā€œkurÅ”ā€ var slēpties:

  1. Citi pakalpojumi. To sauc par ā€œpeerā€ autentifikāciju. Piemēram, pakalpojumsvēlas piekļūt pakalpojumam web . Pakalpojumu tÄ«kli parasti risina Ŕādas problēmas ar mTLS: sertifikāti Å”ajā gadÄ«jumā kalpo kā nepiecieÅ”amais identifikators. dbDaži cilvēki lietotāji. To sauc par ā€œpieprasÄ«jumaā€ autentifikāciju.
  2. Piemēram, lietotājs haxor69vēlas iegādāties jaunu lampu. Pakalpojumu tÄ«kli nodroÅ”ina dažādus mehānismus, piemēram, JSON Web Tokens Daudziem no mums ir nācies to darÄ«t lietojumprogrammas kodā. Ierodas pieprasÄ«jums, mēs apskatām tabulu , atrodam lietotāju un salÄ«dzinām paroli, tad pārbaudām kolonnu.

    permissions lietotājiutt. Pakalpojumu tÄ«klā tas notiek vēl pirms pieprasÄ«jums sasniedz pakalpojumu. permissions Pēc tam, kad mēs esam noskaidrojuÅ”i, no kura ir bijis pieprasÄ«jums, ir jānosaka, ko konkrētai personai ir atļauts darÄ«t. Daži pakalpojumu tÄ«kli ļauj izvirzÄ«t pamata politikas (par to, kas un ko var darÄ«t) kā YAML failus vai komandlÄ«nijā, savukārt citi piedāvā integrāciju ar ietvariem, piemēram,

. Galvenais mērÄ·is ir panākt, lai jÅ«su pakalpojumi pieņemtu visus pieprasÄ«jumus, droÅ”i pieņemot, ka tie ir no uzticama avota Open Policy AgentŔī rÄ«cÄ«ba ir atļauta. un 4. Slodzes sadalīŔana

TL;DR: Sadali slodzi pa pakalpojumu instancēm pēc noteikta parauga.

TL;DR: Sadaliet slodzi pakalpojuma instancēm saskaņā ar noteiktu paraugu.

Ā«ServissĀ» sastāvā servisa sektora ļoti bieži ir daudzas identiskas kopijas. Piemēram, Å”odien serviss cache sastāv no 5 kopijām, bet rÄ«t to skaits var pieaugt lÄ«dz 11. PieprasÄ«jumi, kas tiek sÅ«tÄ«ti uz cache, jādistribūē atbilstoÅ”i noteiktam mērÄ·im. Piemēram, minimizēt aizturi vai maksimizēt iespējamo piekļuvi funkcionējoÅ”ai kopijai. Visbiežāk tiek izmantots apaļās sadales algoritms (Round-robin), taču pastāv arÄ« daudzi citi — piemēram, svērto (weighted) pieprasÄ«jumu metode (var izvēlēties priekÅ”roces mērÄ·us), riņķa (ring) hashēŔana (saskaņotas hashēŔanas izmantoÅ”ana augÅ”upvērstu hostu gadÄ«jumā) vai vismazākā pieprasÄ«jumu skaita metoda (priekÅ”roka tiek dota kopijai ar vismazākajiem pieprasÄ«jumiem).

Klasiskajiem balancerim ir arÄ« citas funkcijas, kā, piemēram, HTTP keÅ”atmiņa un DDoS aizsardzÄ«ba, taču tās nav ļoti aktuālas east-west tipa trafika gadÄ«jumā (t.i., trafika, kas notiek datu centrā ― tulk. piezÄ«me), kas ir tipiska servisa tÄ«klu pielietoÅ”anas joma. Protams, nav obligāti izmantot servisa tÄ«klu slodzes balansēŔanai, taču tas ļauj noteikt un kontrolēt balansēŔanas politikas katram servisam no centralizētas vadÄ«bas slāņa, tādējādi novērÅ”ot nepiecieÅ”amÄ«bu palaist un konfigurēt atseviŔķus balancerus tÄ«kla kaudzes ietvaros.

5. Cirku pārtraukŔana (circuit breaking)

TL;DR: Apturiet trafiku uz problemātisko servisu un kontrolējiet bojājumus sliktāko scenāriju gadījumā.

Ja kāda iemesla dēļ serviss netiek galā ar trafiku, servisa tÄ«kls nodroÅ”ina vairākas Å”o problēmu risināŔanas iespējas (par citām tiks stāstÄ«ts atbilstoÅ”ajos sadaļās). Cirku pārtraukÅ”ana ir visstingrākais veids, kā atslēgt servisu no trafika. Tomēr pats par sevi tas nav jēgpilns — nepiecieÅ”ams rezerves plāns. Var ieviest pretspiedienu (backpressure) uz servisiem, kas izpilda pieprasÄ«jumus (tikai neaizmirstiet konfigurēt savu servisa tÄ«klu Å”im nolÅ«kam!), vai arÄ«, piemēram, krāsot statusa lapu sarkanā krāsā un novirzÄ«t lietotājus uz alternatÄ«vu lapu ar ā€œkrÄ«toÅ”u vaļuā€ (ā€œTwitter nedarbojasā€).

Servisa tÄ«kli ļauj ne tikai noteikt, kad sekos atslēgÅ”ana un ko pēc tā sekos. Å ajā gadÄ«jumā "kad" var ietvert jebkuru daudzumu noteiktu parametru: kopējo pieprasÄ«jumu skaitu noteiktā periodā, paralēlo savienojumu skaitu, gaidoÅ”us pieprasÄ«jumus, aktÄ«vās atkārtotas mēģinājumu utt.

Jūs, iespējams, nevēlēsieties ļaunprātīgi izmantot circuit breaking, bet patīkami apzināties, ka ir rezerves plāns galējā gadījumā.

6. Automātiskā mērogoÅ”ana

TL;DR: Palieliniet vai samaziniet pakalpojuma instanču skaitu atkarībā no noteiktiem kritērijiem.

Service mesh nav plānotāji, tāpēc tie nenodroÅ”ina mērogoÅ”anu paÅ”i. Tomēr tie var sniegt informāciju, uz kuras pamata plānotāji pieņems lēmumus. Tā kā service mesh piekļūst visam satiksmei starp pakalpojumiem, tiem ir plaÅ”a informācija par to, kas notiek: kuri pakalpojumi saskaras ar problēmām, kuri ir ļoti maz noslogoti (resursi tiek izŔķērdēti) utt. Piemēram, Kubernetes mērogo pakalpojumus atkarÄ«bā no resurss, ko podi izmanto CPU un atmiņā

(sk. mÅ«su ziņojumu " ", bet ja jÅ«s nolemsiet veikt mērogoÅ”anu, pamatojoties uz jebkuru citu rādÄ«tāju (mÅ«su gadÄ«jumā - kas saistÄ«ts ar satiksmi), bÅ«s nepiecieÅ”ama speciāla metrika. VadlÄ«nijasAutomātiskā mērogoÅ”ana un resursu pārvaldÄ«ba KubernetesĀ» — tulkotāja piezÄ«me.)kā Ŕāda parāda, kā to izdarÄ«t, izmantojot , bet pats process ir diezgan sarežģīts. Mēs vēlētos, lai service mesh to atvieglotu, ļaujot vienkārÅ”i uzstādÄ«t nosacÄ«jumus, piemēram, "palieliniet pakalpojuma instanču skaitu Envoy, Istio un Prometheus, ja gaidoÅ”o izpildi pieprasÄ«jumu skaits pārsniegs sliekŔņa vērtÄ«bu minÅ«tes laikā." auth7. Kanāriju izlaides

TL;DR: Izmēģiniet jaunas funkcijas vai pakalpojumu versijas daļai lietotāju.

TL;DR: Testējiet jaunās funkcijas vai pakalpojuma versijas noteiktā lietotāju grupā.

Teiksim, jÅ«s izstrādājat kādu SaaS produktu un plānojat izlaiest tā jauno versiju. JÅ«s to esat izmēģinājis testēŔanas vidē, un tas ir darbojies lieliski. Tomēr jÅ«s joprojām uztrauc jautājumi par tā uzvedÄ«bu reālajos apstākļos. Citiem vārdiem sakot, ir nepiecieÅ”ams pārbaudÄ«t jauno versiju reālos uzdevumos, neuzņemoties risku ar lietotāju uzticÄ«bu. Kanāriju izvietojumi ir lieliski piemēroti Å”im mērÄ·im. Tie ļauj demonstrēt jaunu funkciju noteiktai lietotāju apakÅ”grupai. Å Ä« apakÅ”grupa var sastāvēt no vislojalākajiem lietotājiem vai tiem, kas izmanto bezmaksas produkta versiju, vai no lietotājiem, kuri ir izteikuÅ”i vēlmi bÅ«t "izmēģinājuma trusīŔiem."

Servisa tÄ«kli to realizē, ļaujot norādÄ«t kritērijus, kas nosaka, kurÅ” un kādu versiju lietojumprogrammas redzēs, un attiecÄ«gi marÅ”rutējot satiksmi. Tajā pat laikā paÅ”i servisi neko nemaina. 1.0 versijas serviss uzskata, ka visi pieprasÄ«jumi nāk no lietotājiem, kuri tieÅ”i to arÄ« ir jāredz, savukārt 1.1 versijas uzskata to paÅ”u attiecÄ«bā uz saviem lietotājiem. Bet jÅ«s, tajā paŔā laikā, varat mainÄ«t satiksmes procentu starp veco un jauno versiju, pāradresējot pieaugoÅ”o lietotāju skaitu uz jauno, ja tā darbojās stabila un jÅ«su "izmēģinājuma" lietotāji piekrÄ«t.

8. Zilā-zaļā izvietojumi

TL;DR: Izlaidiet jaunu forÅ”u funkciju, bet esiet gatavi nekavējoties to atgriezt atpakaļ.

Jēga zilā-zaļajos izvietojumos ir izlaist jauno "zilo" servisu, palaižot to paralēli vecajam, "zaļajam". Ja viss notiek raiti un jaunais serviss izrādās labs, veco var pakāpeniski izslēgt. (Diemžēl, kādreiz arÄ« Å”im jaunajam "zilajam" servisam bÅ«s tāda pati liktenis kā "zaļajam", un tas pazudÄ«s…) Zilā-zaļie izvietojumi atŔķiras no kanāriju, jo jaunā funkcija aptver uzreiz visus lietotājus (nevis daļu); jēga Å”eit ir bÅ«t gatavam "rezervju piestātnei", ja kaut kas notiks ne tā.

Servisa mezhi piedāvā ļoti ērtu veidu, kā testēt "zilā" servisa un nekavējoties pārslēgties uz darbojoÅ”o "zaļo" gadÄ«jumā, ja iestājas problēmas. Nemaz nerunājot par to, ka tie sniedz daudz informācijas (skatÄ«t punktu "Telemetrija" zemāk) par "zilā" darbu, kas palÄ«dz saprast, vai tas ir gatavs pilnvērtÄ«gai ekspluatācijai.

PiezÄ«me:: PlaŔāk par dažādām izvietoÅ”anas stratēģijām Kubernetes (ieskaitot minētās kanāriju, zilo/zaļo un citas) var izlasÄ«t Å”ajā rakstā.

9. Veselības pārbaude

TL;DR: Sekojiet lÄ«dzi tam, kuri servisa instancēm ir funkcionējoÅ”as, un reaģējiet uz tām, kuras vairs tādas nav.

VeselÄ«bas pārbaude (health check) palÄ«dz pieņemt lēmumu par to, vai servisa instancēm ir gatavi pieņemt un apstrādāt trafiku. Piemēram, HTTP servisa gadÄ«jumā veselÄ«bas pārbaude var izskatÄ«ties kā GET pieprasÄ«jums uz endpoint /health. Atbilde 200 OK norādÄ«s, ka instancē ir veselÄ«ga, jebkura cita atbilde norādÄ«s, ka tā nav gatava pieņemt trafiku. Servisa mezhi ļauj norādÄ«t, kādā veidā tiks pārbaudÄ«ta funkcionēŔana un biežumu, ar kādu Ŕī pārbaude tiks veikta. Å o informāciju var izmantot citām vajadzÄ«bām — piemēram, slodzes izlÄ«dzināŔanai un circuit breaking.

Tādējādi veselÄ«bas pārbaude nav patstāvÄ«gs lietoÅ”anas scenārijs, bet parasti tiek izmantota, lai sasniegtu citas mērÄ·us. AtkarÄ«bā no veselÄ«bas pārbaudes rezultātiem var bÅ«t nepiecieÅ”amas ārējas darbÄ«bas (attiecÄ«bā uz citām servisa mezhu mērÄ·iem): piemēram, atjaunināt statusa lapu, izveidot problēmu GitHub vai aizpildÄ«t JIRA biļeti. Un servisa mezhi piedāvā ērtu mehānismu visu Å”o automatizācijai.

10. Slodzes pārneŔana (load shedding)

TL;DR: Novirziet trafiku kā atbildi uz īslaicīgu pieprasījuma pieaugumu.

Ja kāds serviss ir pārblÄ«vēts ar trafiku, jÅ«s varat pagaidu novirzÄ«t daļu no Ŕī trafika uz citu vietu (t.i., "nolaist", "pārvietot" (shed) to tur). Piemēram, uz rezerves servisu vai datu centru, vai uz pastāvÄ«gu Pulsar Tēma. LÄ«dz ar to pakalpojums turpinās apstrādāt daļu pieprasÄ«jumu, nevis pilnÄ«bā apstāsies. Slodzes atlaiÅ”ana ir vēlams risinājums, nevis ķēdes pārtraukums, bet tomēr nevajadzētu to pārmērÄ«gi izmantot. Tas palÄ«dz novērst kaskādes kļūmes, pēc kurām apstājas pakalpojumi lejupplÅ«smā.

11. Paralelizācija/īspoguļoŔanas trafiks

TL;DR: Nosūtiet vienu pieprasījumu uzreiz vairākās vietās.

Dažreiz ir nepiecieÅ”ams nosÅ«tÄ«t pieprasÄ«jumu (vai noteiktu pieprasÄ«jumu kopu) uzreiz vairākos pakalpojumos. RaksturÄ«gs piemērs ir daļas ražoÅ”anas trafika nosÅ«tīŔana uz staging pakalpojumu. Galvenais tÄ«mekļa serveris ražoÅ”anā nosÅ«ta pieprasÄ«jumu uz zemāk esoÅ”o pakalpojumu products.production un tikai uz to. Savukārt pakalpojumu tÄ«kls intelektuāli kopē Å”o pieprasÄ«jumu un nosÅ«ta to uz products.staging, par ko tÄ«mekļa serveris pat nenojauÅ”.

Vēl viens saistÄ«ts scenārijs, kas izmanto pakalpojumu tÄ«klu un ko var realizēt virs trafika paralelizācijas, ir regresijas testēŔana. Tā paredz, ka vieni un tie paÅ”i pieprasÄ«jumi tiek nosÅ«tÄ«ti dažādām pakalpojuma versijām un tiek pārbaudÄ«ts, vai visas versijas uzvedas vienādi. LÄ«dz Å”im man nav bijusi iespēja saskarties ar pakalpojumu tÄ«klu, kurā bÅ«tu iekļauta regresijas testēŔanas sistēma, piemēram, Diffy, bet pati ideja izskatās perspektÄ«va.

12. Izolācija

TL;DR: Sadaliet savu pakalpojumu tīklu mazās apakŔtīklos.

Tā arÄ« pazÄ«stama kā segmentācija, izolācija ir māksla dalÄ«t pakalpojumu tÄ«klu loÄ£iski atseviŔķos segmentos, kas neko nezin viens par otru. Izolācija ir lÄ«dzÄ«ga virtuālo privāto tÄ«klu veidoÅ”anai. Principā atŔķirÄ«ba ir tāda, ka jÅ«s joprojām varat izmantot visas pakalpojumu tÄ«kla priekÅ”rocÄ«bas (piemēram, pakalpojumu atklāŔanu), taču ar papildu droŔību. Piemēram, ja uzbrucējs spēj iekļūt pakalpojumā kādā no apakÅ”tÄ«klām, viņŔ nespēs redzēt, kādi pakalpojumi darbojas citos apakÅ”tÄ«klos, vai pārņemt to trafiku.

Turklāt priekÅ”rocÄ«bas var bÅ«t arÄ« organizatoriskas. Iespējams, vēlēsieties dalÄ«t pakalpojumus apakÅ”tÄ«klos atkarÄ«bā no uzņēmuma struktÅ«ras un atbrÄ«vot izstrādātājus no kognitÄ«vās slodzes, kas saistÄ«ta ar nepiecieÅ”amÄ«bu atcerēties visu pakalpojumu tÄ«klu.

13. PieprasÄ«jumu biežuma ierobežoÅ”ana, atkārtoti mēģinājumi un laika ierobežojumi

TL;DR: Vairs nav nepiecieÅ”ams iekļaut kodu bāzē svarÄ«gas uzdevumu pārvaldÄ«bas funkcijas.

Visas Ŕīs lietas varētu tikt uzskatÄ«tas par atseviŔķiem izmantoÅ”anas gadÄ«jumiem, bet es izlēmu tās apvienot, jo tām ir viena kopÄ«ga Ä«paŔība: tās uzņemas uzdevumus par pieprasÄ«jumu dzÄ«ves cikla pārvaldÄ«bu, ko parasti veiksmÄ«gi paveic piemēroÅ”anas bibliotēkas. Ja jÅ«s attÄ«stāt tÄ«mekļa serveri, kas veidots Ruby on Rails (neintegrēts ar pakalpojumu tÄ«klu), kas veic pieprasÄ«jumus pie aizmugures pakalpojumiem caur gRPC, lietotnei paÅ”ai bÅ«s jānosaka, ko darÄ«t, ja N pieprasÄ«jumi beidzas neveiksmÄ«gi. BÅ«s arÄ« jānoskaidro, cik lielu trafiku Å”ie pakalpojumi spēj apstrādāt, un jāiekodē Å”ie parametri, izmantojot Ä«paÅ”u bibliotēku. Turklāt lietotnei bÅ«s jāizlemj, kad ir laiks padoties un ļaut pieprasÄ«jumam nosacÄ«t.

UZdevu nodoÅ”ana pakalpojumu tÄ«klam nozÄ«mē ne tikai to, ka pakalpojumu izstrādātājiem vairs nav jādomā par to, bet arÄ« to, ka to var apskatÄ«t plaŔākā kontekstā. Ja tiek izmantota sarežģīta pakalpojumu ķēde, teiksim, A → B → C → D → E, jāņem vērā viss pieprasÄ«juma dzÄ«ves cikls. Ja mērÄ·is ir pagarināt laika limitus pakalpojumā C, ir loÄ£iski to darÄ«t kā vienu kopumu, nevis pa daļām: atjauninot pakalpojuma kodu un gaidot, kamēr pull pieprasÄ«jums tiks akceptēts un CI sistēma izvietos atjaunināto pakalpojumu.

14. Telemetrija

TL;DR: Ievāciet visu nepiecieŔamo (un ne gluži) informāciju no pakalpojumiem.

Telemetrija ir vispārējs termins, kas ietver metrikas, izplatÄ«to izsekoÅ”anu un žurnālus. Pakalpojumu tÄ«kli piedāvā mehānismus, lai vāktu un apstrādātu visus trÄ«s datu tipus. Å eit viss kļūst nedaudz neskaidrs, jo iespējamo variantu skaits ir pārāk liels. Metriku vākÅ”anai ir Prometheus un citi rÄ«ki, žurnālu vākÅ”anai var izmantot fluentd, Loki, Vector u.c. (piemēram, ClickHouse ar mÅ«su loghouse K8s — tulkojumā), izplatÄ«tai izsekoÅ”anai ir Jaeger utt. Katrs pakalpojumu tÄ«kls var atbalstÄ«t vienus rÄ«kus un neatbalstÄ«t citus. Interesanti, vai projekts Open Telemetry spēs nodroÅ”ināt kādu konverÄ£enci.

Å ajā gadÄ«jumā service mesh tehnoloÄ£ijas priekÅ”rocÄ«ba ir tāda, ka sidecar konteineri principā var savākt visus iepriekÅ” uzskaitÄ«tos datus no saviem pakalpojumiem. Citiem vārdiem sakot, jums ir pieejama vienota telemetrijas vākÅ”anas sistēma, un service mesh var apstrādāt visu Å”o informāciju dažādos veidos. Piemēram:

  • pārraidÄ«t logus no konkrēta pakalpojuma CLI;
  • uzraudzÄ«t pieprasÄ«jumu apjomu no service mesh paneles;
  • vāk dublikātus izsekojumus un novirzÄ«t tos uz sistēmu, piemēram, Jaeger.

UzmanÄ«bu, subjektÄ«vs apgalvojums: VispārÄ«gi runājot, telemetrija ir joma, kurā ir nevēlams spēcÄ«gs service mesh iejaukÅ”anās. Pamata informācijas vākÅ”ana un noteiktu ā€žzelta metrijuā€, piemēram, veiksmÄ«gu pieprasÄ«jumu procentu un aizkavi, reāllaikā uzraudzīŔana ir normāla prakse, taču cerēsim, ka nepiecurlināsim tādus FrankeÅ”teina stekus, kas mēģinās aizstāt specializētas sistēmas, no kurām dažas jau ir lieliski nostiprinājuŔās un labi izpētÄ«tas.

15. Audits

TL;DR: Tas, kurÅ” aizmirst vēstures mācÄ«bas, ir nolemts tās atkārtot.

Audits ir māksla novērot svarÄ«gus notikumus sistēmā. Service mesh gadÄ«jumā tas var nozÄ«mēt izsekot, kurÅ” ir veicis pieprasÄ«jumus konkrētiem endpoint nākamo pakalpojumu vai cik reizes pēdējā mēnesÄ« noticis kāds notikums, kas attiecas uz droŔību.

Ir acÄ«mredzams, ka audits ir ļoti cieÅ”i saistÄ«ts ar telemetriju. Tomēr atŔķirÄ«ba ir tāda, ka telemetrija parasti tiek asociēta ar tādām lietām kā veiktspēja un tehniskā precizitāte, kamēr audits var attiekties uz juridiskiem un citiem jautājumiem, kas pārsniedz striktu tehnisko sfēru (piemēram, atbilstÄ«bu GDPR – Vispārējam datu aizsardzÄ«bas regulējumam).

16. Vizualizācija

TL;DR: Lai dzÄ«vo React.js – neizsmeļams dÄ«vainu interfeisu avots.

VarbÅ«t ir piemērotāks termins, bet es to nezināŔu. Es vienkārÅ”i domāju par service mesh vai tās dažiem komponentiem grafisko attēlojumu. Å Ä«s vizualizācijas var ietvert rādÄ«tājus, piemēram, vidējās aizkaves, informāciju par sidecar konteineru konfigurāciju, veselÄ«bas pārbaudes rezultātus un brÄ«dinājumus.

Darbs pakalpojumu orientētā vidē ir saistÄ«ts ar daudz lielāku kognitÄ«vo slodzi salÄ«dzinājumā ar Viņa Majestāti MonolÄ«tu. Tādēļ kognitÄ«vā spiediena mazināŔanai jābÅ«t prioritātei. Banāls grafiskais interfeiss pakalpojumu tÄ«klam ar iespēju vienkārÅ”i nospiest pogu un saņemt nepiecieÅ”amo rezultātu var izrādÄ«ties izŔķiroÅ”s Ŕīs tehnoloÄ£ijas popularitātes pieaugumam.

Netika iekļauti sarakstā

Sākotnēji es plānoju iekļaut sarakstā vēl dažus lietoÅ”anas scenārijus, taču pēc tam nolēmu to nedarÄ«t. LÅ«k, tie kopā ar manām lēmumu pieņemÅ”anas pamatotÄ«bām:

  • Vairāku datu centru. Manā izpratnē tas nav tik daudz lietoÅ”anas scenārijs, cik Å”aura un specifiska pakalpojumu tÄ«klu vai konkrētu funkciju kopuma izmantoÅ”ana, piemēram, pakalpojumu atklāŔana.
  • Ingress un egress. Tas ir saistÄ«ts ar jomu, taču es sevi ierobežoju (iespējams, mākslÄ«gi) ar lietoÅ”anas scenāriju "east-west'' trafiks. Ingress un egress pelna atseviŔķu rakstu.

Secinājums

Pagājām tas viss! Atkal, Å”is saraksts ir diezgan nosacÄ«ts un visticamāk nav pilnÄ«gs. Ja jums Ŕķiet, ka esmu ko aizmirsis vai kļūdÄ«jies, sazinieties ar mani Twitter (@lucperkins). LÅ«dzu, ievērojiet pieklājÄ«bas noteikumus.

P.S. no tulka

Kā ilustrācijas materiāls rakstam tika izmantots attēls no raksta "What is a Service Mesh (and when to use one)?" (autore — Gregory MacKinnon). Tajā redzams, kā daļa no funkcionalitātes, kas iepriekÅ” bija lietotnēs (zaļā krāsā), pārgāja uz pakalpojumu tÄ«klu, nodroÅ”inot to savstarpējās attiecÄ«bas (zilā krāsā).

Lasiet arī mūsu emuāra rakstos:

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster