ProHoster > Blogs > Administrācija > Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju

Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju

PiezÄ«me. tulk.: Servisa siets ir parādÄ«ba, kurai vēl nav stabila tulkojuma krievu valodā (pirms vairāk nekā 2 gadiem mēs piedāvājām opciju ā€œtÄ«kls pakalpojumiemā€, un nedaudz vēlāk daži kolēģi sāka aktÄ«vi popularizēt kombināciju ā€œservisa sietsā€). . PastāvÄ«gās runas par Å”o tehnoloÄ£iju ir noveduÅ”as pie situācijas, kad mārketinga un tehniskās sastāvdaļas ir pārāk cieÅ”i saistÄ«tas. Å is brÄ«niŔķīgais materiāls no viena no sākotnējā termina autoriem ir paredzēts, lai radÄ«tu skaidrÄ«bu inženieriem un ne tikai.

Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju
Komikss no Sebastjans Kaseress

Ievads

Ja esat programmatÅ«ras inženieris, kas strādā kaut kur aizmugursistēmu jomā, termins ā€œpakalpojumu tÄ«klsā€, iespējams, jau ir stingri iesakņojies jÅ«su prātā pēdējo pāris gadu laikā. Pateicoties dÄ«vainai sakritÄ«bai, Ŕī frāze arvien vairāk pārņem nozari, un ažiotāža un ar to saistÄ«tie reklāmas piedāvājumi aug kā sniega pikas, lidojot lejā no kalna un neliecinot par palēnināŔanās pazÄ«mēm.

Pakalpojuma tÄ«kls radās mākoņainā ekosistēmas duļķainajos, tendenciozajos Å«deņos. Diemžēl tas nozÄ«mē, ka liela daļa ar to saistÄ«to strÄ«du svārstās no ā€œmazkaloriju pļāpāŔanasā€ lÄ«dz ā€” izmantojot tehnisko terminu ā€” kliedzoŔām muļķībām. Bet, ja izfiltrējat visu troksni, varat atklāt, ka servisa tÄ«klam ir ļoti reāla, noteikta un svarÄ«ga funkcija.

Å ajā ziņojumā es centÄ«Å”os darÄ«t tieÅ”i to: sniegt godÄ«gu, padziļinātu, uz inženieri orientētu ceļvedi par pakalpojumu tÄ«klu. Es atbildÄ“Å”u vairāk nekā tikai uz jautājumu: "Kas tas ir?", - bet arÄ« "Kāpēc?"un "Kāpēc tagad?". Visbeidzot mēģināŔu ieskicēt, kāpēc (manuprāt) tieÅ”i Ŕī tehnoloÄ£ija ir izraisÄ«jusi tik traku ažiotāžu, kas pats par sevi ir interesants stāsts.

Kas es esmu?

Sveiki visiem! Mani sauc Viljams Morgans. Esmu viens no radÄ«tājiem Linkerd - pats pirmais servisa tÄ«kla projekts un projekts, kas vainojams termina parādÄ«Å”anās servisa tÄ«kls kā tāds (atvainojiet, puiÅ”i!). (PiezÄ«me tulk.: Starp citu, Ŕī termina parādÄ«Å”anās rÄ«tausmā, vairāk nekā pirms 2,5 gadiem, mēs jau tulkojām tā paÅ”a autora agrÄ«no materiālu ar nosaukumu "Kas ir pakalpojumu tÄ«kls un kāpēc tas ir vajadzÄ«gs [mākoņa lietojumprogrammai ar mikropakalpojumiem]?".) Es arÄ« vadu PeldoÅ”s ir jaunizveidots uzņēmums, kas veido lieliskus pakalpojumu tÄ«klus, piemēram, Linkerd un Nirt.

DroÅ”i vien nojauÅ”at, ka man Å”ajā jautājumā ir ļoti tendenciozs un subjektÄ«vs viedoklis. Tomēr es centÄ«Å”os samazināt neobjektivitāti lÄ«dz minimumam (izņemot vienu sadaļu: "Kāpēc tik daudz tiek runāts par pakalpojumu tÄ«klu?", - kurā es tomēr dalÄ«Å”os ar savām aizspriedumainām idejām). Es arÄ« darÄ«Å”u visu iespējamo, lai Ŕī rokasgrāmata bÅ«tu pēc iespējas objektÄ«vāka. Konkrētos piemēros es galvenokārt paļauÅ”os uz Linkerd pieredzi, vienlaikus norādot uz atŔķirÄ«bām (ja tādas ir), kas man ir zināmas citu pakalpojumu tÄ«kla veidu ievieÅ”anā.

Labi, ir pienācis laiks pāriet pie gardumiem.

Kas ir servisa tīkls?

Neskatoties uz visu ažiotāžu, pakalpojumu tÄ«kls ir strukturāli diezgan vienkārÅ”s. Tas ir tikai virkne userspace starpniekserveru, kas atrodas "blakus" pakalpojumiem (par "tuvumā" mēs runāsim vēlāk), kā arÄ« kontroles procesu kopums. Starpniekserveri tiek saukti kolektÄ«vi datu plakne, un tiek saukti kontroles procesi vadÄ«bas plakne. Datu plakne pārtver zvanus starp pakalpojumiem un dara ar tiem "visu citu"; vadÄ«bas plakne attiecÄ«gi koordinē starpniekservera darbÄ«bu un nodroÅ”ina piekļuvi jums, t.i. operatoram API, ļaujot manipulēt ar tÄ«klu un izmērÄ«t to kopumā.

Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju

Kas ir Å”is starpniekserveris? Å is ir kategorijas "Layer 7-ware" TCP starpniekserveris (t.i., "ņemot vērā" OSI modeļa 7. slāni) piemēram, HAProxy un NGINX. JÅ«s varat izvēlēties starpniekserveri pēc savas patikas; Linkerd izmanto Rust starpniekserveri, kura nosaukums ir vienkārÅ”s linkerd-starpniekserveris. Mēs to esam apkopojuÅ”i Ä«paÅ”i servisa tÄ«klam. Citas acis dod priekÅ”roku citiem starpniekserveriem (sÅ«tnis ir izplatÄ«ta izvēle). Tomēr starpniekservera izvēle ir tikai ievieÅ”anas jautājums.

Ko dara Å”ie starpniekserveri? AcÄ«mredzot tie starpniekserveri zvanus uz pakalpojumiem un no tiem (stingri sakot, tie darbojas kā starpniekserveri un reversie starpniekserveri, apstrādājot gan ienākoÅ”os, gan izejoÅ”os zvanus). Un viņi ievieÅ” funkciju kopu, kas koncentrējas uz zvaniem starp pakalpojumus. Å Ä« koncentrÄ“Å”anās uz trafiku starp pakalpojumiem ir tas, kas atŔķir pakalpojuma tÄ«kla starpniekserveri no, piemēram, API vārtejām vai ieejas starpniekserveriem (pēdējie koncentrējas uz zvaniem, kas klasterÄ« ienāk no ārpasaules). (PiezÄ«me. tulk.: EsoÅ”o Kubernetes Ingress kontrolleru, no kuriem daudzi izmanto jau minēto Envoy, salÄ«dzinājumu sk. Å is raksts.)

Tātad, mēs izdomājām datu plakni. VadÄ«bas plakne ir vienkārŔāka: tā ir komponenÅ”u kopa, kas nodroÅ”ina visu mehāniku, kas datu plaknei ir nepiecieÅ”ama, lai saskaņoti strādātu, ieskaitot pakalpojumu atklāŔanu, TLS sertifikātu izsniegÅ”anu, metrikas apkopoÅ”anu utt. Datu plakne informē vadÄ«bas plakni par tā uzvedÄ«ba; savukārt vadÄ«bas plakne nodroÅ”ina API, kas ļauj mainÄ«t un izsekot datu plaknes uzvedÄ«bu kopumā.

Zemāk ir Linkerd vadÄ«bas plaknes un datu plaknes diagramma. Kā redzat, vadÄ«bas plaknē ir iekļauti vairāki dažādi komponenti, tostarp Prometheus instance, kas apkopo metriku no starpniekserveriem, kā arÄ« citi komponenti, piemēram, destination (pakalpojuma atklāŔana), identity (sertifikācijas iestāde, CA) un public-api (galapunkti tÄ«meklim un CLI). Turpretim datu plakne ir vienkārÅ”s linkerd starpniekserveris blakus lietojumprogrammas instancei. Å Ä« ir tikai loÄ£iskā diagramma; reālās pasaules izvietoÅ”anā datu plaknē var bÅ«t trÄ«s katra vadÄ«bas plaknes komponenta kopijas un simtiem vai tÅ«kstoÅ”iem starpniekserveru.

(Zilie lodziņi Å”ajā diagrammā attēlo Kubernetes apgabalu apmales. Varat redzēt, ka konteineri ar linkerd-starpniekserveri atrodas tajā paŔā podā kā lietojumprogrammu konteineri. Å Ä« shēma ir pazÄ«stama kā blakusvāģa konteiners.)

Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju

Pakalpojumu tīkla arhitektūrai ir vairākas svarīgas sekas. Pirmkārt, tā kā starpniekservera uzdevums ir pārtvert zvanus starp pakalpojumiem, pakalpojumu tīklam ir jēga tikai tad, ja jūsu lietojumprogramma ir izveidota pakalpojumu kopai. acs viens var izmantot ar monolītiem, taču tas ir acīmredzami lieks viena starpniekservera dēļ, un tā funkcionalitāte, visticamāk, nebūs pieprasīta.

Vēl viena svarÄ«ga konsekvence ir tā, ka pakalpojumu tÄ«klam ir nepiecieÅ”ams milzÄ«gs starpniekserveru skaits. Faktiski Linkerd pieķēdē linkerd starpniekserveri katram pakalpojumam (citām implementācijām tiek pievienots starpniekserveris katram mezglam/resursdatoram/VM. Tas ir daudz). Šāda aktÄ«va starpniekservera izmantoÅ”ana pati par sevi rada vairākas papildu komplikācijas:

  1. Starpniekserveriem datu plaknē jābūt ātri, jo katram zvanam ir pāris zvani uz starpniekserveri: viens klienta pusē, viens servera pusē.
  2. ArÄ« starpniekserveriem jābÅ«t mazs Šø viegls. Katrs patērēs atmiņas un CPU resursus, un Å”is patēriņŔ pieaugs lineāri lÄ«dz ar lietojumprogrammu.
  3. Jums būs nepiecieŔams mehānisms, lai izvietotu un atjauninātu lielu skaitu starpniekserveru. To darīt manuāli nav risinājums.

Kopumā pakalpojumu tÄ«kls izskatās Ŕādi (vismaz no putna lidojuma): jÅ«s izvietojat virkni userspace starpniekserveru, kas "kaut ko dara" ar iekŔējo, starppakalpojumu trafiku, un izmantojat vadÄ«bas plakni, lai tos uzraudzÄ«tu un pārvaldÄ«tu.

Ir pienācis laiks jautājumam "Kāpēc?"

Kam paredzēts servisa tīkls?

Tiem, kas pirmo reizi saskārās ar ideju par servisa sietu, ir piedodami nedaudz satraukti. Pakalpojuma tÄ«kla dizains nozÄ«mē, ka tas ne tikai palielinās lietojumprogrammas latentumu, bet arÄ« palielinās patērē resursi un pievienos virkne jaunu mehānismu infrastruktÅ«rā. Vispirms iestatāt pakalpojumu tÄ«klu un pēc tam pēkŔņi atklājat, ka ir jāapkalpo simtiem (ja ne tÅ«kstoÅ”iem) starpniekserveru. Jautājums ir, kurÅ” bÅ«s brÄ«vprātÄ«gais Å”ajā darbā?

Atbildei uz Å”o jautājumu ir divas daļas. Pirmkārt, darÄ«jumu izmaksas, kas saistÄ«tas ar Å”o starpniekserveru izvietoÅ”anu, var ievērojami samazināt dažu ekosistēmā notiekoÅ”u izmaiņu dēļ (vairāk par to vēlāk).

Otrkārt, Ŕāda ierÄ«ce patiesÄ«bā ir lielisks veids, kā ieviest sistēmā papildu loÄ£iku. Un ne tikai tāpēc, ka, izmantojot pakalpojumu tÄ«klu, var pievienot daudz jaunu funkciju, bet arÄ« tāpēc, ka to var izdarÄ«t, netraucējot ekosistēmu. Faktiski viss pakalpojumu tÄ«kla modelis ir balstÄ«ts uz Å”o postulātu: daudzpakalpojumu sistēmā neatkarÄ«gi no tā padarÄ«t individuālie pakalpojumi, satiksme starp viņiem ir ideāls punkts funkcionalitātes pievienoÅ”anai.

Piemēram, Linkerd (tāpat kā lielākajā daļā tīklu) funkcionalitāte galvenokārt ir vērsta uz HTTP izsaukumiem, tostarp HTTP/2 un gRPC*. Funkcionalitāte ir diezgan bagāta - to var iedalīt trīs klasēs:

  1. SaistÄ«tās funkcijas uzticamÄ«ba. Mēģiniet vēlreiz pieprasÄ«jumus, taimautus, kanāriju pieeju (datplÅ«smas sadalÄ«Å”ana/novirzÄ«Å”ana) utt.
  2. SaistÄ«tās funkcijas uzraudzÄ«bu. Veiksmes rādÄ«tāju, kavējumu un pieprasÄ«jumu apjomu apkopoÅ”ana katram pakalpojumam vai atseviŔķiem galamērÄ·iem; pakalpojumu topoloÄ£isko karÅ”u veidoÅ”ana utt.
  3. SaistÄ«tās funkcijas droŔība. Savstarpēja TLS, piekļuves kontrole utt.

* No Linkerd viedokļa gRPC praktiski neatŔķiras no HTTP/2: tas tikai izmanto protobuf lietderÄ«gajā slodzē. No izstrādātāja viedokļa Ŕīs divas lietas, protams, atŔķiras.

Daudzi no Å”iem mehānismiem darbojas pieprasÄ«juma lÄ«menÄ« (tātad "L7 starpniekserveris"). Piemēram, ja pakalpojums Foo veic HTTP zvanu pakalpojuma joslai, Foo pusē esoÅ”ais linkerd-starpniekserveris var saprātÄ«gi lÄ«dzsvarot slodzi un marÅ”rutēt zvanus no Foo uz Bar gadÄ«jumiem, pamatojoties uz novēroto latentumu; tas var atkārtot pieprasÄ«jumu, ja nepiecieÅ”ams (un ja tas ir idempotens); viņŔ var ierakstÄ«t atbildes kodu un taimautu utt. Tāpat joslas pusē esoÅ”ais linkerd-starpniekserveris var noraidÄ«t pieprasÄ«jumu, ja tas nav atļauts vai ja tiek pārsniegts pieprasÄ«juma limits; var novērst aizkavi no savas puses utt.

Starpniekserveri var ā€œkaut ko darÄ«tā€ arÄ« savienojuma lÄ«menÄ«. Piemēram, Linkerd-starpniekserveris Foo pusē var iniciēt TLS savienojumu, un linkerd-starpniekserveris Bar pusē var to pārtraukt, un abas puses var pārbaudÄ«t viena otras TLS sertifikātus*. Tas nodroÅ”ina ne tikai Å”ifrÄ“Å”anu starp pakalpojumiem, bet arÄ« kriptogrāfiski droÅ”u veidu, kā identificēt pakalpojumus: Foo un Bar var "pierādÄ«t", ka viņi ir tādi, kādi viņi saka.

* "Drauga draugs" nozīmē, ka tiek verificēts arī klienta sertifikāts (savstarpējs TLS). "Klasiskajā" TLS, piemēram, starp pārlūkprogrammu un serveri, parasti tiek pārbaudīts tikai vienas puses (servera) sertifikāts.

NeatkarÄ«gi no tā, vai tie darbojas pieprasÄ«juma vai savienojuma lÄ«menÄ«, ir svarÄ«gi uzsvērt, ka visas pakalpojumu tÄ«kla funkcijas ir operatÄ«vi raksturs. Linkerd nevar pārveidot lietderÄ«gās slodzes semantiku, piemēram, pievienot laukus JSON fragmentam vai veikt izmaiņas protobufā. Par Å”o svarÄ«go funkciju mēs runāsim vēlāk, runājot par ESB un starpprogrammatÅ«ru.

Å is ir pakalpojumu tÄ«kla piedāvāto funkciju kopums. Rodas jautājums: kāpēc gan tos neieviest tieÅ”i aplikācijā? Un kāpēc vispār jājaucas ar starpniekserveri?

Kāpēc servisa tīkls ir laba ideja

Lai gan servisa tÄ«kla iespējas ir valdzinoÅ”as, tā galvenā vērtÄ«ba patiesÄ«bā nav funkcijās. Galu galā mēs Var ieviest tos tieÅ”i lietojumprogrammā (vēlāk mēs redzēsim, ka tas bija pakalpojuma tÄ«kla izcelsme). Vienā teikumā sakot, pakalpojuma tÄ«kla vērtÄ«ba ir: tas nodroÅ”ina funkcionalitāti, kas ir bÅ«tiska mÅ«sdienu serveru programmatÅ«ras darbÄ«bai, konsekventi visā stekā un neatkarÄ«gi no lietojumprogrammas koda..

Analizēsim Å”o priekÅ”likumu.

Ā«Funkcijas, kas ir bÅ«tiskas modernas servera programmatÅ«ras darbināŔanai". Ja veidojat darÄ«jumu servera lietojumprogrammu, kas savienota ar publisko internetu un kas pieņem pieprasÄ«jumus no ārpasaules un atbild uz tiem Ä«sā laikā, piemēram, tÄ«mekļa lietojumprogrammu, API serveri un lielāko daļu citu modernu lietojumprogrammu, un ja jÅ«s to ievieÅ”at kā pakalpojumu kopu, kas sinhroni mijiedarbojas savā starpā, un ja jÅ«s pastāvÄ«gi atjaunināt Å”o programmatÅ«ru, pievienojot jaunas funkcijas, un ja modifikācijas laikā esat spiests uzturēt Å”o sistēmu darba stāvoklÄ« - Å”ajā gadÄ«jumā apsveicam , jÅ«s veidojat modernu servera programmatÅ«ru. Un visas Ŕīs lieliskās funkcijas, kas uzskaitÄ«tas iepriekÅ”, patiesÄ«bā izrādās jums svarÄ«gas. Lietojumprogrammai jābÅ«t uzticamai, droÅ”ai, un jums ir jābÅ«t iespējai redzēt, ko tā dara. TieÅ”i Å”os jautājumus palÄ«dz atrisināt servisa tÄ«kls.

(Labi, mana pārliecÄ«ba, ka Ŕī pieeja ir moderns servera programmatÅ«ras veidoÅ”anas veids, ir iezagusies iepriekŔējā rindkopā. Citi dod priekÅ”roku monolÄ«tu, "reaktÄ«vo mikropakalpojumu" un citu lietu izstrādei, kas neietilpst augstāk minētajā definÄ«cijā. Å iem cilvēkiem, iespējams, ir savs viedoklis. kas atŔķiras no manējā, un, savukārt, es uzskatu, ka tie ir "nepareizi" - lai gan jebkurā gadÄ«jumā servisa tÄ«kls viņiem nav Ä«paÅ”i noderÄ«gs).

Ā«Uniforma visai kaudzei". Pakalpojuma tÄ«kla piedāvātās funkcijas ir ne tikai bÅ«tiskas. Tie attiecas uz visiem lietojumprogrammas pakalpojumiem neatkarÄ«gi no tā, kādā valodā tie ir rakstÄ«ti, kādā ietvarā tie tiek izmantoti, kas tos ir uzrakstÄ«jis, kā tie tika izvietoti, un visiem citiem to izstrādes un lietoÅ”anas smalkumiem.

Ā«Lietojumprogrammas kods ir neatkarÄ«gs". Visbeidzot, pakalpojumu tÄ«kls nodroÅ”ina ne tikai konsekventu funkcionalitāti visā kaudzē, bet arÄ« tādā veidā, kas neprasa lietojumprogrammas rediģēŔanu. Pakalpojuma tÄ«kla funkcionalitātes pamats, tostarp konfigurÄ“Å”anas, atjaunināŔanas, darbÄ«bas, uzturÄ“Å”anas utt. uzdevumi, ir tikai platformas lÄ«menÄ« un nav atkarÄ«gs no lietojumprogrammas. Lietojumprogramma var mainÄ«ties, neietekmējot pakalpojuma tÄ«klu. Savukārt servisa tÄ«kls var mainÄ«ties bez jebkādas lietojumprogrammas iejaukÅ”anās.

ÄŖsāk sakot, pakalpojumu tÄ«kls nodroÅ”ina ne tikai svarÄ«gu funkcionalitāti, bet arÄ« globālā, vienotā un no lietojumprogrammām neatkarÄ«gā veidā. Un tāpēc, lai gan pakalpojuma tÄ«kla funkcionalitāti var ieviest pakalpojuma kodā (piemēram, kā bibliotēku, kas iekļauta katrā pakalpojumā), Ŕī pieeja nenodroÅ”inās vienveidÄ«bu un neatkarÄ«bu, kas ir tik vērtÄ«ga pakalpojuma tÄ«kla gadÄ«jumā. .

Un viss, kas jums jādara, ir pievienot virkni starpniekserveru! Es apsolu, ka pavisam drÄ«z mēs apskatÄ«sim darbÄ«bas izmaksas, kas saistÄ«tas ar Å”o starpniekserveru pievienoÅ”anu. Bet vispirms apstāsimies un aplÅ«kosim Å”o neatkarÄ«bas ideju no dažādu perspektÄ«vu cilvēki.

Kam servisa tīkls palīdz?

Lai cik tas nebÅ«tu neērti, lai tehnoloÄ£ija kļūtu par nozÄ«mÄ«gu ekosistēmas sastāvdaļu, cilvēkiem tā ir jāpieņem. Tātad, kuru interesē servisa tÄ«kls? Kas gÅ«st labumu no tā izmantoÅ”anas?

Ja izstrādājat modernu serveru programmatÅ«ru, varat aptuveni iedomāties savu komandu kā grupu pakalpojumu Ä«paÅ”niekiemkas kopÄ«gi izstrādā un Ä«steno biznesa loÄ£iku, un platformas Ä«paÅ”niekiiesaistÄ«ti iekŔējās platformas izstrādē, kurā darbojas Å”ie pakalpojumi. Mazās organizācijās tie var bÅ«t vieni un tie paÅ”i cilvēki, taču, uzņēmumam augot, Ŕīs lomas mēdz kļūt izteiktākas un pat sadalÄ«tas apakÅ”lomās... (Å eit ir daudz ko teikt par devopu mainÄ«go raksturu, mikropakalpojumu organizatoriskā ietekme utt.). n. Bet pagaidām pieņemsim Å”os aprakstus par paÅ”saprotamiem).

No Ŕī viedokļa nepārprotami labuma guvēji no pakalpojumu tÄ«kla ir platformas Ä«paÅ”nieki. Galu galā platformas komandas galvenais mērÄ·is ir izveidot iekŔējo platformu, kurā pakalpojumu Ä«paÅ”nieki var Ä«stenot biznesa loÄ£iku un darÄ«t to tā, lai garantētu viņu maksimālu neatkarÄ«bu no tās darbÄ«bas drÅ«majām detaļām. Pakalpojumu tÄ«kls ne tikai piedāvā iespējas, kas ir bÅ«tiskas Ŕī mērÄ·a sasniegÅ”anai, bet arÄ« tādā veidā, kas, savukārt, nerada atkarÄ«bu no pakalpojumu Ä«paÅ”niekiem.

Ieguvēji ir arÄ« pakalpojumu Ä«paÅ”nieki, kaut arÄ« netieŔākā veidā. Pakalpojuma Ä«paÅ”nieka mērÄ·is ir pēc iespējas produktÄ«vāk Ä«stenot biznesa procesa loÄ£iku, un jo mazāk viņam jāuztraucas par darbÄ«bas jautājumiem, jo ā€‹ā€‹labāk. Tā vietā, lai ieviestu, teiksim, atkārtoÅ”anas politikas vai TLS, viņi var koncentrēties tikai uz biznesu un cerēt, ka platforma parÅ«pēsies par pārējo. Viņiem tā ir liela priekÅ”rocÄ«ba.

Šāda sadalÄ«juma starp platformu un pakalpojumu Ä«paÅ”niekiem organizatorisko vērtÄ«bu nevar pārvērtēt. Es domāju, ka viņa dod savu ieguldÄ«jumu galvenais ieguldÄ«jumu pakalpojuma tÄ«kla vērtÄ«bā.

Mēs guvām Å”o mācÄ«bu, kad kāds agrÄ«ns Linkerd fans mums pastāstÄ«ja, kāpēc viņi izvēlējās servisa tÄ«klu, jo tas viņiem ļāva ā€œturpināt runāt lÄ«dz minimumamā€. Å eit ir dažas detaļas: puiÅ”i no viena liela uzņēmuma migrēja savu platformu uz Kubernetes. Tā kā lietojumprogramma strādāja ar sensitÄ«vu informāciju, viņi vēlējās Å”ifrēt visus klasteros esoÅ”os sakarus. Tomēr situāciju sarežģīja simtiem pakalpojumu un simtiem izstrādes komandu klātbÅ«tne. Izredzes sazināties ar visiem un pārliecināt viņus iekļaut savos plānos atbalstu TLS viņus nemaz neiepriecināja. Instalējot Linkerd, viņi migrēja atbildÄ«ba no izstrādātājiem (no kuru viedokļa tās bija liekas problēmas) lÄ«dz platformeriem, kuriem tā bija augstākā lÄ«meņa prioritāte. Citiem vārdiem sakot, Linkerds viņiem atrisināja ne tik daudz tehnisku, cik organizatorisku problēmu.

ÄŖsāk sakot, servisa tÄ«kls drÄ«zāk nav tehnisks risinājums, bet gan sociāli tehniskais Problēmas. (Paldies Sindija Å ridharana par Ŕī termina ievieÅ”anu.

Vai servisa tīkls atrisinās visas manas problēmas?

Jā. Es domāju, nē!

AplÅ«kojot trÄ«s iepriekÅ” izklāstÄ«tās funkciju klases ā€“ uzticamÄ«bu, droŔību un novērojamÄ«bu ā€“ kļūst skaidrs, ka servisa tÄ«kls nav pilnÄ«gs risinājums nevienai no Ŕīm problēmām. Lai gan Linkerd var nosÅ«tÄ«t atkārtotus pieprasÄ«jumus (ja tas zina, ka tie ir idempotenti), tas nevar pieņemt lēmumus par to, ko atgriezt lietotājam, ja pakalpojums beidzot ir pazudis ā€” Ŕādi lēmumi ir jāpieņem lietojumprogrammai. Linkerd var uzturēt statistiku par veiksmÄ«giem pieprasÄ«jumiem, taču tas nevar ieskatÄ«ties pakalpojumā un nodroÅ”ināt tā iekŔējos rādÄ«tājus - lietojumprogrammai ir jābÅ«t Ŕādam rÄ«ku komplektam. Un, lai gan Linkerd spēj mitināt mTLS, pilnvērtÄ«giem droŔības risinājumiem ir nepiecieÅ”ams daudz vairāk.

Pakalpojuma tīkla piedāvāto funkciju apakŔkopa Ŕajās jomās ir saistīta ar platformas funkcijas. Ar to es domāju funkcijas, kas:

  1. Neatkarīgi no biznesa loģikas. Veids, kādā tiek veidotas izsaukuma histogrammas starp Foo un Bar, ir pilnīgi neatkarīgs no tā, vai kāpēc Fū zvana Bāram.
  2. GrÅ«ti pareizi ieviest. Programmā Linkerd atkārtoÅ”anas mēģinājumi tiek parametrizēti, izmantojot visu veidu smalkas lietas, piemēram, atkārtoto mēģinājumu budžetus. (mēģināt budžetu vēlreiz), jo vienkārÅ”a pieeja Ŕādu lietu Ä«stenoÅ”anai noteikti novedÄ«s pie tā sauktās "pieprasÄ«jumu lavÄ«nas" raÅ”anās. (mēģināt vēlreiz vētru) un citas problēmas, kas raksturÄ«gas sadalÄ«tajām sistēmām.
  3. Visefektīvākais, ja to lieto konsekventi. TLS mehānismam ir jēga tikai tad, ja to izmanto visur.

Tā kā Ŕīs funkcijas ir ieviestas starpniekservera slānÄ« (nevis lietojumprogrammas slānÄ«), pakalpojumu tÄ«kls tos atklāj platformas, nevis lietojumprogrammas. Tādējādi nav svarÄ«gi, kādā valodā pakalpojumi ir rakstÄ«ti, kādu ietvaru tie izmanto, kas tos ir rakstÄ«jis un kāpēc. Starpniekserveri darbojas tālāk par visām Ŕīm detaļām, un Ŕīs funkcionalitātes pamats, tostarp konfigurÄ“Å”anas, atjaunināŔanas, darbÄ«bas, uzturÄ“Å”anas utt., ir tikai platformas lÄ«menÄ«.

Pakalpojumu tīkla iespēju piemēri

Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju

Rezumējot, pakalpojumu tÄ«kls nav pilnÄ«gs risinājums uzticamÄ«bai, novērojamÄ«bai vai droŔībai. Å o jomu darbÄ«bas joma paredz pakalpojumu Ä«paÅ”nieku, Ops / SRE komandu un citu uzņēmuma ieinteresēto personu obligātu lÄ«dzdalÄ«bu. Servisa tÄ«kls nodroÅ”ina tikai "Ŕķēli" platformas lÄ«menÄ« katrai no Ŕīm jomām.

Kāpēc pakalpojumu tÄ«kls ir kļuvis populārs tieÅ”i tagad?

JÅ«s droÅ”i vien Å”obrÄ«d domājat: labi, ja pakalpojumu tÄ«kls ir tik labs, kāpēc mēs nesākām izvietot miljoniem starpniekserveru stekā pirms desmit gadiem?

Uz Å”o jautājumu ir banāla atbilde: pirms desmit gadiem visi bÅ«vēja monolÄ«tus, un nevienam nebija vajadzÄ«gs servisa tÄ«kls. Tā ir patiesÄ«ba, taču, manuprāt, Ŕī atbilde neietver jēgu. Jau pirms desmit gadiem mikropakalpojumu jēdziens kā daudzsoloÅ”s veids liela mēroga sistēmu izveidei tika plaÅ”i apspriests un pielietots tādos uzņēmumos kā Twitter, Facebook, Google un Netflix. Vispārējais uzskats ā€“ vismaz tajās nozares daļās, ar kurām esmu saskāries ā€“ bija tāds, ka mikropakalpojumi ir ā€œpareizais veidsā€, kā veidot lielas sistēmas, pat ja tas bija sasodÄ«ti grÅ«ti.

Protams, lai gan pirms desmit gadiem bija uzņēmumi, kas izmantoja mikropakalpojumus, tie nelÄ«mēja starpniekserverus visur, kur varēja izveidot pakalpojumu tÄ«klu. Tomēr, ja paskatās uzmanÄ«gi, viņi darÄ«ja kaut ko lÄ«dzÄ«gu: daudzi no Å”iem uzņēmumiem lika izmantot Ä«paÅ”u iekŔējo bibliotēku tÄ«klu veidoÅ”anai (dažreiz sauktu par resno klientu bibliotēku, resnā klienta bibliotēka).

Netflix bija Hysterix, Google bija Stubby, Twitter bija Finagle bibliotēka. Piemēram, Finagle ir bijis obligāts katram jaunam pakalpojumam Twitter. Tas apstrādāja gan savienojumu klienta, gan servera puses, ļāva atkārtot pieprasÄ«jumus, atbalstÄ«ja pieprasÄ«jumu marÅ”rutÄ“Å”anu, slodzes lÄ«dzsvaroÅ”anu un mērÄ«Å”anu. Tas nodroÅ”ināja konsekventu uzticamÄ«bas un novērojamÄ«bas lÄ«meni visā Twitter kaudzē neatkarÄ«gi no tā, ko pakalpojums darÄ«ja. Protams, tas darbojās tikai JVM valodās un bija balstÄ«ts uz programmÄ“Å”anas modeli, kas bija jāizmanto visai lietojumprogrammai. Tomēr tā funkcionalitāte bija gandrÄ«z tāda pati kā servisa tÄ«kla funkcionalitāte. (PatiesÄ«bā pirmā Linkerd versija bija tikai Finagle, kas iesaiņota starpniekservera formā.)

Tādējādi pirms desmit gadiem bija ne tikai mikropakalpojumi, bet arÄ« Ä«paÅ”as proto-service-mesh bibliotēkas, kas atrisināja tās paÅ”as problēmas, kuras Å”odien risina pakalpojumu tÄ«kls. Taču pats servisa tÄ«kls toreiz neeksistēja. Pirms viņa parādÄ«Å”anās vajadzēja bÅ«t vēl vienai maiņai.

Un Å”eit slēpjas dziļākā atbilde, kas slēpjas citās izmaiņās, kas notikuÅ”as pēdējo 10 gadu laikā: ir krasi samazinājuŔās mikropakalpojumu izvietoÅ”anas izmaksas. IepriekÅ” minētie uzņēmumi, kas izmantoja mikropakalpojumus pirms desmit gadiem ā€” Twitter, Netflix, Facebook, Google ā€” bija milzÄ«ga mēroga un milzÄ«gu resursu uzņēmumi. Viņiem bija ne tikai vajadzÄ«ba, bet arÄ« iespēja izveidot, izvietot un darbināt lielas lietojumprogrammas, kuru pamatā ir mikropakalpojumi. EnerÄ£ija un pÅ«les, ko Twitter inženieri ir ieguldÄ«juÅ”i, lai pārietu no monolÄ«ta uz mikropakalpojumu pieeju, ir pārsteidzoÅ”a. (GodÄ«gi sakot, tāpat kā fakts, ka tas strādāja.) Mazākiem uzņēmumiem Ŕāda veida infrastruktÅ«ras manevrÄ“Å”ana nebija iespējama.

Pārejam uz tagadni. MÅ«sdienās ir jaunizveidoti uzņēmumi, kuros mikropakalpojumu attiecÄ«ba pret izstrādātājiem ir 5:1 (vai pat 10:1), un turklāt viņi veiksmÄ«gi tiek ar tiem galā! Ja 5 cilvēku starta uzņēmums bez sasprindzinājuma spēj darbināt 50 mikropakalpojumus, tad kaut kas nepārprotami samazināja to ievieÅ”anas izmaksas.

Pakalpojumu tīkls: kas katram programmatūras inženierim jāzina par karstāko tehnoloģiju
1500 mikropakalpojumi Monco; katra līnija ir noteikta tīkla kārtula, kas pieļauj trafiku

Dramatiskais mikropakalpojumu darbÄ«bas izmaksu samazinājums ir viena procesa rezultāts: pieaug konteineru popularitāte Šø orÄ·estranti. TieÅ”i Ŕī ir dziļa atbilde uz jautājumu par to, kas veicināja servisa tÄ«kla raÅ”anos. Tā pati tehnoloÄ£ija padarÄ«ja pievilcÄ«gu gan pakalpojumu tÄ«klu, gan mikropakalpojumus: Kubernetes un Docker.

Kāpēc? Nu, Docker atrisina vienu lielu problēmu - iepakojuma problēmu. Iesaiņojot lietojumprogrammu un tās (ne tÄ«kla) izpildlaika atkarÄ«bas konteinerā, Docker pārvērÅ” lietojumprogrammu par aizstājamu vienÄ«bu, kuru var mitināt un palaist jebkurā vietā. Tajā paŔā laikā tas ievērojami vienkārÅ”o darbÄ«bu. daudzvalodu kaudze: tā kā konteiners ir izpildes atomu vienÄ«ba, izvietoÅ”anas un darbÄ«bas nolÅ«kos nav nozÄ«mes tam, kas atrodas iekÅ”pusē, neatkarÄ«gi no tā, vai tā ir JVM, Node, Go, Python vai Ruby lietojumprogramma. JÅ«s vienkārÅ”i palaižat to un viss.

Kubernetes visu paceļ nākamajā lÄ«menÄ«. Tagad, kad ir daudz "izpildāmu lietu" un daudzas maŔīnas, ar kurām tās darbināt, ir nepiecieÅ”ams rÄ«ks, kas varētu tās saskaņot. PlaŔā nozÄ«mē jÅ«s pieŔķirat Kubernetes daudz konteineru un daudzas maŔīnas, un tas tos saskaņo savā starpā (protams, tas ir dinamisks un pastāvÄ«gi mainÄ«gs process: sistēmā pārvietojas jauni konteineri, maŔīnas ieslēdzas un apstājas utt. Kubernetes to visu ņem vērā ).

Kad Kubernetes ir iestatÄ«ts, laiks, kas nepiecieÅ”ams viena pakalpojuma izvietoÅ”anai un darbÄ«bai, daudz neatŔķiras no desmit pakalpojumu izvietoÅ”anas un darbÄ«bas izmaksām (faktiski tas ir gandrÄ«z vienāds 100 pakalpojumiem). Pievienojiet Å”iem konteineriem kā iepakoÅ”anas mehānismu, kas veicina daudzvalodu ievieÅ”anu, un jums bÅ«s daudz jaunu lietojumprogrammu, kas ieviestas kā mikropakalpojumi, kas rakstÄ«ti vairākās valodās, tieÅ”i tādā vidē, kurai pakalpojumu tÄ«kls ir tik labi piemērots.

Tātad, mēs nonākam pie atbildes uz jautājumu, kāpēc ideja par servisa tÄ«klu ir kļuvusi populāra tieÅ”i tagad: Kubernetes sniegtā vienveidÄ«ba pakalpojumiem ir tieÅ”i attiecināma uz servisa tÄ«kla darbÄ«bas uzdevumiem. JÅ«s iesaiņojat starpniekserverus konteineros, uzdodiet Kubernetes tos pielÄ«mēt, kur vien iespējams, un voilā! Izvadā jÅ«s saņemat pakalpojuma tÄ«klu, savukārt Kubernetes kontrolē visu tā izvietoÅ”anas mehānismu. (Vismaz no putna lidojuma. Protams, Å”im procesam ir daudz nianÅ”u.)

Rezumējot: iemesls, kāpēc pakalpojumu tÄ«kls kļuva populārs tagad, nevis pirms desmit gadiem, ir tas, ka Kubernetes un Docker ne tikai ievērojami palielinājās nepiecieÅ”ams tajā vienkārÅ”ojot lietojumprogrammu ievieÅ”anu kā daudzvalodu mikropakalpojumu komplektus, bet arÄ« ievērojami samazinot izmaksas tās darbÄ«bai, nodroÅ”inot mehānismus blakusvāģu starpstāvu parku izvietoÅ”anai un uzturÄ“Å”anai.

Kāpēc tik daudz tiek runāts par pakalpojumu tīklu?

UzmanÄ«bu: Å ajā sadaļā es izmantoju visu veidu pieņēmumus, minējumus, izdomājumus un iekŔējo informāciju.

Meklējot ā€œpakalpojumu tÄ«klsā€, tiks parādÄ«ts daudz otrreizēji pārstrādātu, zemu kaloriju satura, dÄ«vainu projektu un atbalss kameras cienÄ«gu kropļojumu kaleidoskopu. Tas ir pieejams jebkurai modernai jaunai tehnoloÄ£ijai, taču servisa tÄ«kla gadÄ«jumā problēma ir Ä«paÅ”i aktuāla. Kāpēc?

Nu, daļēji tā ir mana vaina. Esmu darÄ«jis visu iespējamo, lai katru iespēju reklamētu Linkerd un pakalpojumu tÄ«klu, izmantojot neskaitāmus emuāra ierakstus un rakstus, piemēram, Å”o. Bet es neesmu tik spēcÄ«gs. Lai patiesi atbildētu uz Å”o jautājumu, mums nedaudz jāparunā par vispārējo situāciju. Un par to nav iespējams runāt, nepieminot vienu projektu: Istio ir atvērtā pirmkoda pakalpojumu tÄ«kls, ko kopÄ«gi izstrādājuÅ”i Google, IBM un Lyft.

(Å iem trim uzņēmumiem ir ļoti atŔķirÄ«gas lomas: Ŕķiet, ka Lyft iesaistÄ«Å”anās aprobežojas tikai ar nosaukumu; tie ir sÅ«tņa autors, bet neizmanto vai nav iesaistÄ«ti Istio izstrādē. IBM ir iesaistÄ«ts Istio izstrādē un izmanto to. Google ir ļoti svarÄ«gs iesaistÄ«ts Istio izstrādē, bet, cik es varu pateikt, faktiski to neizmanto.)

Istio projekts ir ievērojams ar divām lietām. Pirmkārt, tas ir milzÄ«gs mārketinga darbs, ko Google jo Ä«paÅ”i iegulda savā reklamÄ“Å”anā. Es lÄ“Å”u, ka lielākā daļa cilvēku, kas paÅ”laik ir informēti par pakalpojumu tÄ«kla koncepciju, pirmo reizi par to uzzināja, pateicoties Istio. Otra iezÄ«me ir tas, cik slikti Istio tika uzņemts. Å ajā jautājumā es, protams, esmu ieinteresētā puse, bet, cenÅ”oties palikt pēc iespējas objektÄ«vāks, es joprojām nevaru palÄ«dzēt AtzÄ«mēt ļoti negatÄ«vs attieksme, ne pārāk specifisks (lai gan ne unikāls: nāk prātā systemd, salÄ«dzinājums tika iznests ārā jau atkārtoti...) atvērtā pirmkoda projektam.

(Praksē Ŕķiet, ka Istio ir problēmas ne tikai ar sarežģītÄ«bu un UX, bet arÄ« ar veiktspēju. Piemēram, laikā Linkerd veiktspējas novērtējumiTreŔās puses veiktajā darbā eksperti konstatēja situācijas, kurās Istio astes latentums bija 100 reizes lielāks nekā Linkerd, kā arÄ« situācijas ar resursu trÅ«kumu, kad Linkerd turpināja veiksmÄ«gi darboties un Istio pilnÄ«bā pārtrauca darboties.)

Atstājot malā manas teorijas par to, kāpēc tas notika, es uzskatu, ka nenozÄ«mÄ«gā ažiotāža ap pakalpojumu tÄ«klu ir saistÄ«ta ar Google iesaistÄ«Å”anos. Proti, Ŕādu trÄ«s faktoru kombinācija:

  1. Google uzmācÄ«ga Istio reklamÄ“Å”ana;
  2. atbilstoŔa noraidoŔa, kritiska attieksme pret projektu;
  3. Kubernetes pēdējā laikā strauji pieaugoŔā popularitāte, par kuru atmiņā joprojām ir svaiga.

Kopā Å”ie faktori saplÅ«st sava veida apreibinoŔā, bezskābekļa vidē, kurā ir vājināta spēja racionāli spriest, un paliek tikai brÄ«niŔķīga dažādÄ«ba. tulpju mānija.

No Linkerda viedokļa tā ir... es to raksturotu kā jauktu svētÄ«bu. Es domāju, tas ir lieliski, ka pakalpojumu tÄ«kls ir ienācis galvenajā straumē ā€” tas tā nebija 2016. gadā, kad Linkerd pirmo reizi parādÄ«jās, un bija patieŔām grÅ«ti pievērst cilvēku uzmanÄ«bu projektam. Tagad tādu problēmu nav! Bet sliktā ziņa ir tā, ka pakalpojumu tÄ«kla situācija mÅ«sdienās ir tik mulsinoÅ”a, ka ir gandrÄ«z neiespējami noskaidrot, kuri projekti patieŔām ietilpst pakalpojumu tÄ«kla kategorijā (nemaz nerunājot par to, kurÅ” no tiem ir vislabākais konkrētajam lietoÅ”anas gadÄ«jumam). Tas noteikti traucē visiem (un noteikti dažos gadÄ«jumos Istio vai kāds cits projekts ir labāks par Linkerd, jo pēdējais nav universāls risinājums).

No Linkerda puses mÅ«su stratēģija ir bijusi ignorēt troksni, turpināt koncentrēties uz reālo problēmu risināŔanu sabiedrÄ«bā un bÅ«tÄ«bā gaidÄ«t, kamēr ažiotāža norims. Galu galā ažiotāža norims un varēsim mierÄ«gi turpināt darbu.

Līdz tam mums visiem būs jābūt pacietīgiem.

Vai servisa tīkls man, pieticīgam programmatūras inženierim, noderēs?

SekojoŔā anketa palÄ«dzēs atbildēt uz Å”o jautājumu:

Vai jÅ«s nodarbojaties tikai ar biznesa loÄ£ikas ievieÅ”anu? Å ajā gadÄ«jumā servisa tÄ«kls jums nebÅ«s noderÄ«gs. Tas, protams, jÅ«s varētu interesēt, taču ideālā gadÄ«jumā pakalpojumu tÄ«klam nevajadzētu tieÅ”i ietekmēt neko jÅ«su vidē. Turpiniet strādāt pie tā, par ko jums maksā.

Vai jÅ«s uzturat platformu uzņēmumā, kas izmanto Kubernetes? Jā, Å”ajā gadÄ«jumā jums ir nepiecieÅ”ams servisa tÄ«kls (protams, ja jÅ«s neizmantojat K8s tikai, lai palaistu monolÄ«tu vai pakeÅ”u apstrādi - bet tad es gribētu jautāt, kāpēc jums ir nepiecieÅ”ams K8s). Visticamāk, jÅ«s nonāksit situācijā ar daudziem mikropakalpojumiem, ko rakstÄ«juÅ”i dažādi cilvēki. Tie visi mijiedarbojas viens ar otru un ir saistÄ«ti ar izpildlaika atkarÄ«bu mudžekli, un jums ir jāatrod veids, kā ar to visu tikt galā. Kubernetes izmantoÅ”ana ļauj izvēlēties servisa sietu "paÅ”am". Lai to izdarÄ«tu, iepazÄ«stieties ar to iespējām un funkcijām un atbildiet uz jautājumu, vai kāds no pieejamajiem projektiem jums vispār ir piemērots (iesaku sākt pētÄ«jumu ar Linkerd).

Vai izmantojat platformu uzņēmumam, kas NEIZMANTO Kubernetes, bet izmanto mikropakalpojumus? Å ajā gadÄ«jumā servisa tÄ«kls jums bÅ«s noderÄ«gs, taču tā izmantoÅ”ana nebÅ«s triviāla. Protams tu vari atdarināt pakalpojumu tÄ«klu, mitinot virkni starpniekserveru, taču svarÄ«ga Kubernetes priekÅ”rocÄ«ba ir tieÅ”i izvietoÅ”anas modelis: Å”o starpniekserveru manuāla uzturÄ“Å”ana prasÄ«s daudz vairāk laika, pūļu un izmaksu.

Vai esat atbildÄ«gs par platformu uzņēmumā, kas strādā ar monolÄ«tiem? Å ajā gadÄ«jumā jums, iespējams, nav nepiecieÅ”ams servisa tÄ«kls. Ja strādājat ar monolÄ«tiem (vai pat monolÄ«tu kolekcijām), kuriem ir labi definēti un reti mainÄ«gi mijiedarbÄ«bas modeļi, pakalpojumu tÄ«klam jums ir maz ko piedāvāt. Tātad jÅ«s varat to ignorēt un cerēt, ka tas pazÅ«d kā slikts sapnis...

Secinājums

Iespējams, servisa tÄ«klu joprojām nevajadzētu saukt par ā€œvisvairāk izskanējuÅ”o tehnoloÄ£iju pasaulēā€ - Å”is apÅ”aubāmais gods, iespējams, pieder bitcoin vai AI. VarbÅ«t viņa ir pirmajā pieciniekā. Bet, izlaužoties cauri trokŔņa un trokŔņa slāņiem, kļūst skaidrs, ka pakalpojumu tÄ«kls sniedz reālus ieguvumus tiem, kas veido lietojumprogrammas Kubernetes.

Es vēlētos, lai jÅ«s izmēģinātu Linkerd ā€” instalējot to Kubernetes klasterÄ« (vai pat Minikube klēpjdatorā) aizņem apmēram 60 sekundesun jÅ«s paÅ”i redzat, par ko es runāju.

FAQ

- Ja es ignorēŔu servisa tīklu, vai tas pazudīs?
- Man jums ir jāpieviļ: servisa tīkls ir pie mums ilgu laiku.

ā€” Bet es NEGRIBAS izmantot servisa sietu!
ā€“ Nu nevajag! VienkārÅ”i izlasiet manu iepriekÅ” sniegto anketu, lai redzētu, vai jums vajadzētu vismaz iepazÄ«ties ar tās pamatiem.

ā€” Vai tas nav vecais labais ESB/middleware ar jaunu mērci?
- Pakalpojumu tÄ«kls attiecas uz darbÄ«bas loÄ£iku, nevis semantisku. Tas bija galvenais trÅ«kums uzņēmuma apkalpoÅ”anas autobuss (ESB). Å Ä«s atdalÄ«Å”anas saglabāŔana palÄ«dz pakalpojumu tÄ«klam izvairÄ«ties no tāda paÅ”a likteņa.

- Kā pakalpojumu tīkls atŔķiras no API vārtejām?
Par Å”o tēmu ir miljons rakstu. VienkārÅ”i google.

Vai sūtnis ir dienesta tīkls?
- Nē, Envoy nav pakalpojumu tÄ«kls, tas ir starpniekserveris. To var izmantot, lai organizētu pakalpojumu tÄ«klu (un daudz ko citu ā€” tas ir vispārējas nozÄ«mes starpniekserveris). Bet pats par sevi tas nav servisa tÄ«kls.

- Network Service Mesh ā€” vai tas ir pakalpojumu tÄ«kls?
- Nē. Neskatoties uz nosaukumu, tas nav pakalpojumu tīkls (kā jums patīk mārketinga brīnumi?).

- Vai pakalpojumu tīkls palīdzēs manai reaktīvai asinhronajai sistēmai, kuras pamatā ir ziņojumu rinda?
- Nē, servisa tīkls jums nepalīdzēs.

- Kuru pakalpojumu tīklu man vajadzētu izmantot?
Sākot no Linkerd, bez prāta.

- Raksts sūdīgs! / Autors - uz ziepēm!
ā€” LÅ«dzu, padalieties ar saiti uz to ar visiem draugiem, lai viņi par to pārliecinātos!

Pateicības

Kā jÅ«s varētu nojaust pēc nosaukuma, Å”is raksts ir iedvesmots no Džeja Krepsa fantastiskā traktāta "Žurnāls: kas katram programmatÅ«ras inženierim bÅ«tu jāzina par reāllaika datu vienojoÅ”o abstrakciju". Es satiku Džeju pirms desmit gadiem, sniedzot interviju vietnē Linked In, un kopÅ” tā laika viņŔ mani ir iedvesmojis.

Lai gan man patÄ«k sevi dēvēt par "Linkerd izstrādātāju", realitāte ir tāda, ka es vairāk esmu README.md faila uzturētājs projektā. Å odien strādājam pie Linkerd ļoti, ļoti, ļoti Š¼Š½Š¾Š³Š¾ cilvēku, un Å”is projekts nebÅ«tu iespējams bez apbrÄ«nojamās lÄ«dzstrādnieku un lietotāju kopienas.

Un visbeidzot, Ä«paÅ”s paldies Linkerd izveidotājam, Olivers GÅ«lds (primus inter pares), kurÅ” kopā ar mani pirms daudziem gadiem ienira visā Å”ajā kņadā ar servisa tÄ«klu.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com