ProHoster > Š‘Š»Š¾Š³ > Administrācija > Servisa tÄ«kla lietoÅ”anas scenāriji

Servisa tīkla lietoŔanas scenāriji

Servisa tīkla lietoŔanas scenāriji

PiezÄ«me. tulk.: Å Ä« raksta autors (Luks Pērkinss) ir izstrādātāju advokāts CNCF organizācijā, kurā atrodas tādi atvērtā pirmkoda projekti kā Linkerd, SMI (Service Mesh Interface) un Kuma (starp citu, vai esat arÄ« aizdomājuÅ”ies, kāpēc Istio ir vai nav Å”ajā sarakstā?.). Vēlreiz mēģinot DevOps kopienai labāk izprast moderno ažiotāžu, ko sauc par "pakalpojumu tÄ«klu", viņŔ uzskaita 16 raksturÄ«gās iespējas, ko sniedz Ŕādi risinājumi.

Å odien servisa tÄ«kls ā€• viena no karstākajām tēmām programmatÅ«ras inženierijas jomā (un pamatoti!). Es domāju, ka Ŕī tehnoloÄ£ija ir neticami daudzsoloÅ”a, un es vēlētos, lai tā tiktu plaÅ”i izmantota (protams, kad tam ir jēga). Tomēr lielākajai daļai cilvēku to joprojām ieskauj noslēpumaina aura. Tajā paŔā laikā pat tie, kuri plaÅ”i pazÄ«stams ar to bieži ir grÅ«ti formulēt tā priekÅ”rocÄ«bas un to, kas tieÅ”i tas ir (ieskaitot jÅ«su patieso). Å ajā rakstā es mēģināŔu labot situāciju, uzskaitot dažādus lietoÅ”anas gadÄ«jumi "pakalpojumu tÄ«kli"*.

* PiezÄ«me tulk.: Å”eit un turpmāk rakstā tieÅ”i Å”is tulkojums (ā€œservice meshā€) tiks izmantots vēl jaunajam terminam service mesh.

Bet vispirms es vēlos izteikt dažus komentārus:

  • Es nekad neesmu strādājis ar servisa tÄ«kliem vai izmantojis tos ārpus savas izglÄ«tÄ«bas projektiem. No otras puses, es biju tas, kurÅ” 2015. gadā uzrakstÄ«ja daudz dokumentācijas Twitter iekŔējam pakalpojuma tÄ«klam (toreiz to pat nesauca par "pakalpojumu tÄ«klu") un piedalÄ«jos vietnes un dokumentācijas izstrādē. Linkerd, tātad tas kaut ko nozÄ«mē.
  • Mans saraksts ir aptuvens un nepilnÄ«gs. Iespējams, ir man nezināmi lietoÅ”anas gadÄ«jumi, un laika gaitā, attÄ«stoties tehnoloÄ£ijai un augot tās popularitātei, visticamāk, radÄ«sies jaunas iespējas.
  • Tajā paŔā laikā ne katra esoŔā pakalpojumu tÄ«kla ievieÅ”ana atbalsta visus uzskaitÄ«tos lietoÅ”anas gadÄ«jumus. Tāpēc mani apgalvojumi, piemēram, ā€œpakalpojumu tÄ«kls var...ā€ ir jālasa kā ā€œatseviŔķs, un, iespējams, visas populārās pakalpojumu tÄ«kla ievieÅ”anas var...ā€.
  • Piemēru secÄ«bai nav nekādas atŔķirÄ«bas.

ÄŖss saraksts:

  • pakalpojumu atklāŔana;
  • Å”ifrÄ“Å”ana;
  • autentifikācija un autorizācija;
  • slodzes balansÄ“Å”ana;
  • ķēdes pārtraukums;
  • automātiskā mērogoÅ”ana;
  • kanāriju izvietoÅ”ana;
  • zili zaļi izvietojumi;
  • veselÄ«bas pārbaude;
  • slodzes nolaiÅ”ana;
  • satiksmes atspoguļoÅ”ana;
  • izolācija;
  • pieprasÄ«juma ātruma ierobežoÅ”ana, atkārtojumi un taimauts;
  • telemetrija;
  • audits;
  • vizualizācija.

1. Pakalpojuma atklāŔana

TL;DR: izveidojiet savienojumu ar citiem tīkla pakalpojumiem, izmantojot vienkārŔus nosaukumus.

Pakalpojumiem jāspēj automātiski ā€œatrastā€ vienam otru, izmantojot atbilstoÅ”us nosaukumus, piemēram, service.api.production, pets/staging vai cassandra. Mākoņu vide ir elastÄ«ga, un viens nosaukums var paslēpt daudzus pakalpojuma gadÄ«jumus. Ir skaidrs, ka Ŕādā situācijā visas IP adreses fiziski nav iespējams kodēt.

Turklāt, kad viens pakalpojums atrod citu pakalpojumu, tam vajadzētu bÅ«t iespējai nosÅ«tÄ«t pieprasÄ«jumus Å”im pakalpojumam, nebaidoties, ka tie nonāks tā bojātās instances ievadē. Citiem vārdiem sakot, pakalpojumu tÄ«klam ir jāuzrauga visu pakalpojumu gadÄ«jumu stāvoklis un jāuztur resursdatoru saraksts pēc iespējas atjaunināts.

Katrs pakalpojumu tÄ«kls pakalpojuma atklāŔanas mehānismu ievieÅ” atŔķirÄ«gi. PaÅ”laik visizplatÄ«tākais veids ir deleģēt ārējiem procesiem, piemēram, Kubernetes DNS. Agrāk pakalpojumā Twitter mēs Å”im nolÅ«kam izmantojām nosaukumu sistēmu Finagle. Turklāt pakalpojumu tÄ«kla tehnoloÄ£ija ļauj izveidot pielāgotus nosaukumu pieŔķirÅ”anas mehānismus (lai gan es vēl neesmu redzējis nevienu SM ievieÅ”anu ar Ŕādu funkcionalitāti).

2. ŠifrēŔana

TL;DR: atbrÄ«vojieties no neÅ”ifrētas trafika starp pakalpojumiem un padariet Å”o procesu automatizētu un mērogojamu.

Ir patÄ«kami apzināties, ka uzbrucēji nevar iekļūt jÅ«su iekŔējā tÄ«klā. UgunsmÅ«ri to dara lielisku darbu. Bet kas notiek, ja hakeris iekļūst iekŔā? Vai viņŔ ar dienesta iekŔējo satiksmi varēs darÄ«t visu, ko vēlas? Cerēsim, ka tas tomēr nenotiks. Lai novērstu Å”o scenāriju, ir jāievieÅ” nulles uzticamÄ«bas tÄ«kls, kurā visa satiksme starp pakalpojumiem ir Å”ifrēta. Lielākā daļa mÅ«sdienu servisa tÄ«klu to panāk ar savstarpēju palÄ«dzÄ«bu TLS (savstarpējs TLS, mTLS). Dažos gadÄ«jumos mTLS darbojas veselos mākoņos un klasteros (es domāju, ka starpplanētu sakari kādreiz tiks sakārtoti lÄ«dzÄ«gi).

Protams, mTLS pakalpojumu tÄ«klam neobligāti. Katrs pakalpojums var rÅ«pēties par savu TLS, taču tas nozÄ«mē, ka jums bÅ«s jāatrod veids, kā Ä£enerēt sertifikātus, izplatÄ«t tos starp pakalpojumu resursdatoriem un iekļaut kodu lietojumprogrammā, kas ielādēs Å”os sertifikātus no failiem. Jā, neaizmirstiet Å”os sertifikātus regulāri atjaunot. Pakalpojumu tÄ«kli automatizē mTLS ar tādām sistēmām kā SPIFFE, kas savukārt automatizē sertifikātu izsniegÅ”anas un rotācijas procesu.

3. Autentifikācija un autorizācija

TL;DR: nosakiet, kas ir pieprasītājs, un definējiet, ko viņam ir atļauts darīt, pirms pieprasījums pat sasniedz pakalpojumu.

Dienesti bieži vēlas zināt kurÅ” veic pieprasÄ«jumu (autentifikācija), un, izmantojot Å”o informāciju, pieņem lēmumu ka noteiktai entÄ«tijai ir atļauts to darÄ«t (pilnvarojums). Å ajā gadÄ«jumā vietniekvārds ā€œkurÅ”ā€ var paslēpties:

  1. Citi pakalpojumi. To sauc par "autentifikāciju" lÄ«dzinieks" Piemēram, serviss web vēlas piekļūt pakalpojumam db. Pakalpojumu tÄ«kli parasti atrisina Ŕādas problēmas, izmantojot mTLS: sertifikāti Å”ajā gadÄ«jumā darbojas kā nepiecieÅ”amais identifikators.
  2. Daži cilvēki lietotāji. To sauc par "autentifikāciju" pieprasÄ«jumu" Piemēram, lietotājs haxor69 vēlas iegādāties jaunu lampu. Servisa sieti nodroÅ”ina dažādus mehānismus, piem. JSON tÄ«mekļa marÄ·ieri.

    Daudzi no mums to ir izdarÄ«juÅ”i lietojumprogrammas kodā. Ienāk pieprasÄ«jums, mēs skatāmies caur tabulu users, atrodiet lietotāju un salÄ«dziniet paroli, pēc tam pārbaudiet kolonnu permissions utt. Pakalpojuma tÄ«kla gadÄ«jumā tas notiek, pirms pieprasÄ«jums pat sasniedz pakalpojumu.

Kad esam noskaidrojuÅ”i, no kā ir saņemts pieprasÄ«jums, mums ir jānosaka, ko Ŕī vienÄ«ba drÄ«kst darÄ«t. Daži pakalpojumu tÄ«kli ļauj iestatÄ«t pamatpolitikas (par to, kas ko var darÄ«t) kā YAML failus vai komandrindā, savukārt citi piedāvā integrāciju ar tādiem ietvariem kā Atvērts politikas aÄ£ents. GalÄ«gais mērÄ·is ir, lai jÅ«su pakalpojumi pieņemtu jebkuru pieprasÄ«jumu, droÅ”i pieņemot, ka tas nāk no uzticama avota Šø Ŕī darbÄ«ba ir atļauta.

4. Slodzes balansēŔana

TL;DR: sadaliet slodzi starp pakalpojumu gadījumiem atbilstoŔi noteiktam modelim.

ā€œPakalpojumsā€ pakalpojumu sadaļā ļoti bieži sastāv no daudziem identiskiem gadÄ«jumiem. Piemēram, Å”odien pakalpojums cache sastāv no 5 eksemplāriem, un rÄ«t to skaits var pieaugt lÄ«dz 11. PieprasÄ«jumi nosÅ«tÄ«ti uz cache, jāizplata saskaņā ar konkrētu mērÄ·i. Piemēram, samaziniet latentumu vai palieliniet varbÅ«tÄ«bu, ka nonāksiet lÄ«dz darba instancei. Visbiežāk izmantotais algoritms ir Round-robin, bet ir arÄ« daudzi citi, piemēram, svērtā metode. (svērts) vaicājumi (varat izvēlēties vēlamos mērÄ·us), zvanÄ«t (gredzens) jaukÅ”ana (izmantojot konsekventu jaukÅ”anu augÅ”straumes saimniekdatoros) vai vismazāko pieprasÄ«jumu metodi (priekÅ”roka tiek dota instancei ar vismazāko pieprasÄ«jumu).

Klasiskajiem balansētājiem ir arÄ« citas funkcijas, piemēram, HTTP keÅ”atmiņa un DDoS aizsardzÄ«ba, taču tās nav Ä«paÅ”i piemērotas austrumu-rietumu trafikam (tas ir, trafikam, kas plÅ«st datu centra ietvaros - aptuveni tulk.) (tipisks pakalpojumu tÄ«kla apjoms). Protams, slodzes lÄ«dzsvaroÅ”anai nav nepiecieÅ”ams izmantot pakalpojumu tÄ«klu, taču tas ļauj iestatÄ«t un kontrolēt lÄ«dzsvaroÅ”anas politikas katram pakalpojumam no centralizēta vadÄ«bas slāņa, tādējādi novērÅ”ot nepiecieÅ”amÄ«bu palaist un konfigurēt atseviŔķus slodzes balansētājus tÄ«kla stekā. .

5. Ķēdes pārtraukums

TL;DR: apturiet satiksmi uz problemātisko pakalpojumu un kontrolējiet bojājumus sliktākajā gadījumā.

Ja kāda iemesla dēļ pakalpojums nevar tikt galā ar trafiku, servisa tÄ«kls nodroÅ”ina vairākas iespējas Ŕīs problēmas risināŔanai (citas tiks apspriestas attiecÄ«gajās sadaļās). Ķēdes pārrāvums ir vissmagākā iespēja pakalpojuma atvienoÅ”anai no satiksmes. Tomēr pats par sevi tam nav jēgas - ir nepiecieÅ”ams rezerves plāns. Var nodroÅ”ināt pretspiedienu (pretspiediens) pakalpojumiem, kas veic pieprasÄ«jumus (tikai neaizmirstiet Å”im nolÅ«kam konfigurēt savu pakalpojumu tÄ«klu!), vai, piemēram, statusa lapu nokrāsojot sarkanā krāsā un lietotājus novirzot uz citu lapas versiju ar ā€œkrÄ«toÅ”u valiā€ (ā€œTwitter ir uz lejuā€).

Servisa tÄ«kli ne tikai ļauj definēt kur sekos izslēgÅ”ana un ka tas sekos. Å ajā gadÄ«jumā ā€œkadā€ var ietvert jebkuru norādÄ«to parametru kombināciju: kopējais pieprasÄ«jumu skaits noteiktā periodā, paralēlo savienojumu skaits, neapstiprinātie pieprasÄ«jumi, aktÄ«vie mēģinājumi utt.

Jūs, iespējams, nevēlaties ļaunprātīgi izmantot ķēdes pārtraukumus, taču ir patīkami apzināties, ka jums ir rezerves plāns avārijas gadījumā.

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

TL;DR: Palieliniet vai samaziniet pakalpojumu gadījumu skaitu atkarībā no norādītajiem kritērijiem.

Pakalpojumu tÄ«kli nav plānotāji, tāpēc tie nav izpildÄ«t mērogojot sevi. Tomēr viņi var sniegt informāciju, uz kuriem plānotāji balstÄ«s savus lēmumus. Tā kā pakalpojumu tÄ«kliem ir pieejama visa satiksme starp pakalpojumiem, tiem ir plaÅ”a informācija par notiekoÅ”o: kuri pakalpojumi saskaras ar problēmām, kuri pakalpojumi ir ļoti maz noslogoti (tiem atvēlētā jauda tiek izniekota) utt.

Piemēram, Kubernetes mērogo pakalpojumus, pamatojoties uz pods CPU un atmiņas lietojumu (skatiet mÅ«su ziņojumu "AutomērogoÅ”ana un resursu pārvaldÄ«ba Kubernetes"- apm. tulk.), bet, ja izlemjat mērogot, pamatojoties uz jebkuru citu metriku (mÅ«su gadÄ«jumā saistÄ«bā ar satiksmi), jums bÅ«s nepiecieÅ”ama Ä«paÅ”a metrika. VadÄ«ba kā Å”is parāda, kā to izdarÄ«t ar sÅ«tnis, Istio Šø Prometejs, bet pats process ir diezgan sarežģīts. Mēs vēlētos, lai pakalpojumu tÄ«kls to vienkārÅ”otu, ļaujot mums vienkārÅ”i iestatÄ«t nosacÄ«jumus, piemēram, "palielināt pakalpojumu gadÄ«jumu skaitu auth, ja neapstiprināto pieprasÄ«jumu skaits pārsniedz slieksni minÅ«tes laikā."

7. Kanāriju izvietojumi

TL;DR: pārbaudiet jaunas funkcijas vai pakalpojuma versijas lietotāju apakŔkopai.

Pieņemsim, ka jÅ«s izstrādājat SaaS produktu un plānojat izlaist jaunu lielisku tā versiju. JÅ«s to pārbaudÄ«jāt iestudējumā, un tas darbojās lieliski. Taču joprojām pastāv zināmas bažas par viņas uzvedÄ«bu reālos apstākļos. Citiem vārdiem sakot, jums ir jāpārbauda jaunā versija uz reālām problēmām, neriskējot ar lietotāju uzticÄ“Å”anos. Kanāriju izvietojumi tam ir lieliski piemēroti. Tie ļauj parādÄ«t jaunu funkciju lietotāju apakÅ”kopai. Å Ä« apakÅ”kopa var sastāvēt no lojālākajiem lietotājiem vai tiem, kas strādā ar produkta bezmaksas versiju, vai lietotājiem, kuri ir izteikuÅ”i vēlmi kļūt par ā€œjÅ«rascÅ«ciņāmā€.

Pakalpojumu tÄ«kli to Ä«steno, ļaujot norādÄ«t kritērijus, kas nosaka, kurÅ” redzēs kuru lietojumprogrammas versiju, un attiecÄ«gi marÅ”rutējot trafiku. Taču paÅ”iem dienestiem nekas nemainās. Pakalpojuma versija 1.0 uzskata, ka visi pieprasÄ«jumi nāk no lietotājiem, kuriem tas ir jāredz, un versija 1.1 uzskata, ka tas pats attiecas uz saviem lietotājiem. Tikmēr jÅ«s varat mainÄ«t datplÅ«smas procentuālo daļu starp veco un jauno versiju, novirzot arvien lielāku lietotāju skaitu uz jauno versiju, ja tā darbojas stabili un jÅ«su ā€œizmēģinājuma cÅ«ciņasā€ dod iespēju.

8. Zili-zaļi izvietojumi

TL;DR: izlaidiet lielisku jaunu funkciju, taču esiet gatavs nekavējoties atsaukt visu.

NozÄ«me zili zaļi izvietojumi ir ieviest jaunu ā€œziloā€ pakalpojumu, palaižot to paralēli vecajam, ā€œzaļajamā€. Ja viss norit gludi un jaunais pakalpojums darbojas labi, tad veco var pakāpeniski atspējot. (Ak, kādreiz Å”is jaunais ā€œzilaisā€ pakalpojums atkārtos ā€œzaļāā€ likteni un pazudÄ«s...) Zili zaļie izvietojumi atŔķiras no kanārijputniem ar to, ka jaunā funkcija aptver visi uzreiz lietotāji (nav daļa); Å eit galvenais ir izveidot ā€œdroÅ”o ostuā€, ja kaut kas noiet greizi.

Servisa tÄ«kli piedāvā ļoti ērtu veidu, kā pārbaudÄ«t ā€œziloā€ pakalpojumu un problēmu gadÄ«jumā uzreiz pārslēgties uz funkcionējoÅ”u ā€œzaļoā€. Nemaz nerunājot par to, ka pa ceļam tie sniedz daudz informācijas (skat. ā€œTelemetrijaā€) par ā€œzilāā€ darbu, kas palÄ«dz saprast, vai tas ir gatavs pilnai darbÄ«bai.

PiezÄ«me. tulk.: Vairāk par dažādām Kubernetes izvietoÅ”anas stratēģijām (ieskaitot minēto kanārijputnu, zilo/zaļo un citas) varat lasÄ«t Å”eit Å is raksts.

9. Veselības pārbaude

TL;DR: sekojiet līdzi, kuri pakalpojumu gadījumi darbojas, un reaģējiet uz tiem, kas vairs nedarbojas.

VeselÄ«bas pārbaude (veselÄ«bas pārbaude) palÄ«dz izlemt, vai pakalpojumu gadÄ«jumi ir gatavi pieņemt un apstrādāt trafiku. Piemēram, HTTP pakalpojumu gadÄ«jumā stāvokļa pārbaude var izskatÄ«ties kā GET pieprasÄ«jums galapunktam /health... Atbilde 200 OK nozÄ«mēs, ka instance ir vesela, jebkura cita ā€“ ka tā nav gatava trafika uztverÅ”anai. Servisa tÄ«kli ļauj norādÄ«t gan veidu, kādā tiks pārbaudÄ«ta funkcionalitāte, gan Ŕīs pārbaudes veikÅ”anas biežumu. Pēc tam Å”o informāciju var izmantot citiem mērÄ·iem - piemēram, slodzes lÄ«dzsvaroÅ”anai un ķēdes pārtraukumiem.

Tādējādi veselÄ«bas pārbaude nav atseviŔķs lietoÅ”anas gadÄ«jums, bet parasti tiek izmantots citu mērÄ·u sasniegÅ”anai. Turklāt atkarÄ«bā no veselÄ«bas pārbaužu rezultātiem var bÅ«t nepiecieÅ”amas darbÄ«bas, kas nav saistÄ«tas ar citiem pakalpojumu tÄ«kla mērÄ·iem: piemēram, statusa lapas atjaunināŔana, problēmas izveidoÅ”ana vietnē GitHub vai JIRA biļetes aizpildÄ«Å”ana. Un servisa tÄ«kls piedāvā ērtu mehānismu, lai to visu automatizētu.

10. Slodzes atlaiŔana

TL;DR: novirzīt trafiku, reaģējot uz īslaicīgu lietojuma pieaugumu.

Ja kāds pakalpojums ir pārslogots ar trafiku, daļu no Ŕīs trafika varat Ä«slaicÄ«gi novirzÄ«t uz citu vietu (t.i., ā€œizgāztā€, ā€œpārsÅ«tÄ«tā€ (Ŕķūnis) viņŔ tur). Piemēram, uz rezerves pakalpojumu vai datu centru, vai uz pastāvÄ«gu prese temats. Rezultātā pakalpojums turpinās apstrādāt dažus pieprasÄ«jumus, nevis avarēs un pilnÄ«bā pārtrauks visu apstrādāt. Slodzes samazināŔana ir labāka nekā ķēdes pārtraukÅ”ana, taču joprojām nav ieteicams to ļaunprātÄ«gi izmantot. Tas palÄ«dz novērst kaskādes atteices, kas izraisa pakārtoto pakalpojumu avāriju.

11. Satiksmes paralēlizācija/spoguļoÅ”ana

TL;DR: nosūtiet vienu pieprasījumu uz vairākām vietām vienlaikus.

Dažreiz ir nepiecieÅ”ams nosÅ«tÄ«t pieprasÄ«jumu (vai noteiktu pieprasÄ«jumu atlasi) vairākiem pakalpojumiem vienlaikus. Tipisks piemērs ir daļas ražoÅ”anas trafika nosÅ«tÄ«Å”ana uz instalÄ“Å”anas pakalpojumu. Galvenais ražoÅ”anas tÄ«mekļa serveris nosÅ«ta pieprasÄ«jumu pakārtotajam pakalpojumam products.production un tikai viņam. Un pakalpojumu tÄ«kls saprātÄ«gi kopē Å”o pieprasÄ«jumu un nosÅ«ta to uz products.staging, par ko tÄ«mekļa serveris pat nezina.

Vēl viens saistÄ«ts pakalpojumu tÄ«kla izmantoÅ”anas gadÄ«jums, ko var ieviest papildus trafika paralēlizācijai, ir regresijas pārbaude. Tas ietver vienādu pieprasÄ«jumu nosÅ«tÄ«Å”anu dažādām pakalpojuma versijām un pārbaudi, vai visas versijas darbojas vienādi. Es vēl neesmu saskāries ar pakalpojumu tÄ«kla ievieÅ”anu ar tādu integrētu regresijas testÄ“Å”anas sistēmu kā Diffy, bet pati ideja Ŕķiet daudzsoloÅ”a.

12. Izolācija

TL;DR: sadaliet savu pakalpojumu tīklu minitīklos.

Zināms arÄ« kā segmentācijaIzolÄ“Å”ana ir māksla sadalÄ«t pakalpojumu tÄ«klu loÄ£iski atŔķirÄ«gos segmentos, kas neko nezina viens par otru. Izolācija ir nedaudz lÄ«dzÄ«ga virtuālo privāto tÄ«klu izveidei. BÅ«tiskā atŔķirÄ«ba ir tāda, ka jÅ«s joprojām varat baudÄ«t visas pakalpojuma tÄ«kla priekÅ”rocÄ«bas (piemēram, pakalpojuma atklāŔanu), taču ar papildu droŔību. Piemēram, ja uzbrucējs spēj iekļūt pakalpojumā vienā apakÅ”tÄ«klā, viņŔ nevarēs redzēt, kādi pakalpojumi darbojas citos apakÅ”tÄ«klos, vai pārtvert to trafiku.

Turklāt ieguvumi var bÅ«t arÄ« organizatoriski. Iespējams, vēlēsities izveidot apakÅ”tÄ«klu savus pakalpojumus, pamatojoties uz uzņēmuma struktÅ«ru, un atbrÄ«vot izstrādātājus no kognitÄ«vās slodzes, kas rodas, paturot prātā visu pakalpojumu tÄ«klu.

13. PieprasÄ«juma ātruma ierobežoÅ”ana, mēģinājumi un taimauts

TL;DR: jums vairs nav jāiekļauj rupji pieprasījumu pārvaldības uzdevumi savā kodu bāzē.

Visas Ŕīs lietas varētu uzskatÄ«t par atseviŔķiem lietoÅ”anas gadÄ«jumiem, taču es nolēmu tās apvienot vienas kopÄ«gas iezÄ«mes dēļ: tās pārņem pieprasÄ«jumu dzÄ«ves cikla pārvaldÄ«bas uzdevumus, ko parasti apstrādā lietojumprogrammu bibliotēkas. Ja izstrādājat tÄ«mekļa serveri Ruby on Rails (nav integrēts pakalpojumu tÄ«klā), kas veic aizmugurpakalpojumu pieprasÄ«jumus, izmantojot grRPC, lietojumprogrammai bÅ«s jāizlemj, kā rÄ«koties, ja N pieprasÄ«jumi neizdodas. Jums bÅ«s arÄ« jānoskaidro, cik lielu trafiku Å”ie pakalpojumi varēs apstrādāt un kodēt Å”os parametrus, izmantojot Ä«paÅ”u bibliotēku. Turklāt lietojumprogrammai bÅ«s jāizlemj, kad ir pienācis laiks padoties un ļaut pieprasÄ«jumam izbeigt (pamatojoties uz taimautu). Un, lai mainÄ«tu kādu no iepriekÅ” minētajiem parametriem, tÄ«mekļa serveris bÅ«s jāaptur, jāpārkonfigurē un jāsāk no jauna.

Å o uzdevumu izkrauÅ”ana servisa tÄ«klā nozÄ«mē ne tikai to, ka pakalpojumu izstrādātājiem par tiem nebÅ«s jādomā, bet arÄ« to, ka tos varēs apskatÄ«t globālākā veidā. Ja tiek izmantota sarežģīta pakalpojumu ķēde, piemēram, A -> B -> C -> D -> E, ir jāņem vērā viss pieprasÄ«juma dzÄ«ves cikls. Ja uzdevums ir pagarināt pakalpojuma C taimautus, ir loÄ£iski to darÄ«t visu uzreiz, nevis pa daļām: atjauninot pakalpojuma kodu un gaidot, lÄ«dz tiek pieņemts izvilkÅ”anas pieprasÄ«jums un CI sistēma izvietos atjaunināto pakalpojumu.

14. Telemetrija

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

Telemetrija ir vispārÄ«gs termins, kas ietver metriku, izplatÄ«tu izsekoÅ”anu un žurnālus. Pakalpojumu tÄ«kli piedāvā mehānismus visu trÄ«s veidu datu vākÅ”anai un apstrādei. Å eit lietas kļūst nedaudz neskaidras, jo iespējamo opciju skaits ir pārāk liels. Lai savāktu metriku, ir Prometejs un citi rÄ«ki, ko var izmantot žurnālu vākÅ”anai tekoÅ”i, Loki, vektors uc (piemēram, ClickHouse ar mÅ«su guļbÅ«ve K8s - apm. tulk.), izplatÄ«tai izsekoÅ”anai ir Vilnas triko un tā tālāk. Katrs pakalpojumu tÄ«kls var atbalstÄ«t dažus rÄ«kus, bet ne citus. BÅ«s interesanti redzēt, vai projekts var Atveriet telemetriju nodroÅ”ināt zināmu konverÄ£enci.

Å ajā gadÄ«jumā servisa tÄ«kla tehnoloÄ£ijas priekÅ”rocÄ«ba ir tāda, ka blakusvāģu konteineri principā var savākt visus iepriekÅ” minētos datus no saviem pakalpojumiem. Citiem vārdiem sakot, jÅ«su rÄ«cÄ«bā ir viena telemetrijas datu savākÅ”anas sistēma, un pakalpojumu tÄ«kls var apstrādāt visu Å”o informāciju dažādos veidos. Piemēram:

  • astes žurnāli no noteikta pakalpojuma CLI;
  • uzraudzÄ«t pieprasÄ«jumu apjomu no pakalpojumu tÄ«kla informācijas paneļa;
  • savāc izplatÄ«tās pēdas un pārsÅ«ta tās uz tādu sistēmu kā Jaeger.

UzmanÄ«bu, subjektÄ«vs spriedums: VispārÄ«gi runājot, telemetrija ir joma, kurā nav vēlami spēcÄ«gi traucējumi no servisa tÄ«kla. Pamatinformācijas vākÅ”ana un dažu zelta metrikas, piemēram, pieprasÄ«juma veiksmes rādÄ«tāja un latentuma, izsekoÅ”ana lidojumā ir labi, taču cerēsim, ka neparādÄ«sies FrankenÅ”teina skursteņi, kas mēģinātu aizstāt specializētās sistēmas, no kurām dažas jau ir sevi pierādÄ«juÅ”as un labi izpētÄ«tas. .

15.Revīzija

TL;DR: Tie, kas aizmirst vēstures mācības, ir lemti tās atkārtot.

Audits ir māksla novērot svarÄ«gus notikumus sistēmā. Pakalpojuma tÄ«kla gadÄ«jumā tas varētu nozÄ«mēt izsekoÅ”anu, kurÅ” veica pieprasÄ«jumus konkrētiem galapunktiem konkrētiem pakalpojumiem vai cik reižu ir noticis kāds ar droŔību saistÄ«ts notikums pēdējā mēneÅ”a laikā.

Ir skaidrs, ka audits ir ļoti cieÅ”i saistÄ«ts ar telemetriju. AtŔķirÄ«ba ir tāda, ka telemetrija parasti tiek saistÄ«ta ar tādām lietām kā produktivitāte un tehniskā integritāte, savukārt audits var attiekties uz juridiskiem un citiem jautājumiem, kas pārsniedz tikai tehnisko sfēru (piemēram, atbilstÄ«bu GDPR - ES VispārÄ«gajai datu aizsardzÄ«bas regulai).

16. Vizualizācija

TL;DR: lai dzÄ«vo React.js ā€” neizsmeļams iedomātu interfeisu avots.

Var bÅ«t labāks termins, bet es to nezinu. Es vienkārÅ”i domāju servisa tÄ«kla vai dažu tā komponentu grafisku attēlojumu. Å Ä«s vizualizācijas var ietvert tādus rādÄ«tājus kā vidējais latentums, blakusvāģa konfigurācijas informācija, veselÄ«bas pārbaudes rezultāti un brÄ«dinājumi.

Darbs uz pakalpojumu orientētā vidē ir saistÄ«ts ar daudz lielāku kognitÄ«vo slodzi, salÄ«dzinot ar Viņa Majestāti MonolÄ«tu. Tāpēc kognitÄ«vais spiediens ir jāsamazina par katru cenu. VienkārÅ”s servisa tÄ«kla grafiskais interfeiss ar iespēju noklikŔķināt uz pogas un iegÅ«t vēlamo rezultātu varētu bÅ«t izŔķiroÅ”s Ŕīs tehnoloÄ£ijas popularitātes pieaugumam.

Sarakstā netika iekļauti

Sākotnēji es plānoju sarakstā iekļaut vēl dažus lietoÅ”anas gadÄ«jumus, bet pēc tam nolēmu to nedarÄ«t. Å eit tie ir kopā ar mana lēmuma iemesliem:

  • Vairāku datu centrs. Manuprāt, tas nav tik daudz lietoÅ”anas gadÄ«jums, cik Å”aura un specifiska pakalpojumu tÄ«klu vai dažu funkciju kopuma, piemēram, pakalpojumu atklāŔanas, piemēroÅ”anas joma.
  • Ieeja un izeja. Å Ä« ir saistÄ«ta joma, bet esmu aprobežojies (varbÅ«t mākslÄ«gi) ar "austrumu-rietumu satiksmes" lietoÅ”anas gadÄ«jumu. IekļūŔana un izeja ir pelnÄ«jusi atseviŔķu rakstu.

Secinājums

Tas pagaidām ir viss! ArÄ« Å”is saraksts ir ļoti patvaļīgs un, visticamāk, nepilnÄ«gs. Ja uzskatāt, ka esmu kaut ko palaidis garām vai kaut kas nav kārtÄ«bā, lÅ«dzu, sazinieties ar mani Twitter (@luckerkins). LÅ«dzu, ievērojiet pieklājÄ«bas noteikumus.

PS no tulka

Raksta virsraksta ilustrācija ir balstÄ«ta uz attēlu no raksta "Kas ir Service Mesh (un kad to izmantot)?"(autors Gregorijs Makkinons). Tas parāda, kā dažas lietojumprogrammu funkcionalitātes (zaļā krāsā) ir pārvietotas uz pakalpojumu tÄ«klu, kas nodroÅ”ina starpsavienojumus starp tām (zilā krāsā).

Lasi arī mūsu emuārā:

Avots: www.habr.com

Iegādājieties uzticamu mitināŔanu vietnēm ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa vietņu mitināŔanu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster