🥇Teenusevõrgu kasutusjuhud

Märge. tõlgeSelle artikli autor (Luc Perkins) on arendajate eestkõneleja CNCF-is, kus tegutsevad avatud lähtekoodiga projektid nagu Linkerd, SMI (Service Mesh Interface) ja Kuma (muide, kas olete kunagi mõelnud, miks Istio selles nimekirjas pole?). Veel ühe katsena DevOps-kogukonnale paremini mõista trendikat "service mesh" hype'i, loetleb ta 16 peamist võimekust, mida sellised lahendused pakuvad.

Täna teenindusvõrk – on tarkvaratehnika üks kuumimaid teemasid (ja õigustatult!). Minu arvates on see tehnoloogia uskumatult paljutõotav ja unistan selle laialdasest kasutuselevõtust (muidugi siis, kui see on mõistlik). Siiski jääb see enamiku inimeste jaoks saladuseks. Isegi need, kes Ma tean sind hästi sellega on sageli raske sõnastada selle eeliseid ja seda, mis see täpselt on (kaasa arvatud teie oma). Selles artiklis püüan olukorda parandada, loetledes erinevaid kasutusjuhud "teenindusvõrgud"*.

* Tõlkija märkus: edaspidi kasutatakse selles artiklis seda tõlget ("service mesh") ikka veel uue termini "service mesh" kohta.

Aga kõigepealt tahaksin teha paar kommentaari:

Ma pole kunagi teenindusvõrkudega töötanud ega neid väljaspool oma haridusprojekte kasutanud. Teisest küljest kirjutasin 2015. aastal hulga dokumentatsiooni Twitteri sisemise teenindusvõrgu jaoks (seda ei nimetatud tol ajal isegi "teenindusvõrguks") ning panustasin veebisaidi ja dokumentatsiooni loomisesse. Linkerd, seega tähendab see midagi.
Minu nimekiri on esialgne ja mittetäielik. Kindlasti on kasutusjuhtumeid, millest ma teadlik ei ole, ja aja jooksul tekib tõenäoliselt uusi, kui tehnoloogia areneb ja populaarsemaks muutub.
Samal ajal ei toeta iga olemasolev teenusevõrgu implementatsioon kõiki ülaltoodud kasutusjuhtumeid. Seetõttu tuleks selliseid väiteid nagu "teenusevõrk saab..." lugeda kui "teatud ja võib-olla isegi kõik populaarsed teenusevõrgu implementatsioonid saavad...".
Näidete järjekord ei ole oluline.

Lühike nimekiri:

teenuste avastamine;
krüpteerimine;
autentimine ja autoriseerimine;
koormuse tasakaalustamine;
vooluahela katkestamine;
automaatne skaleerimine;
kanaarilähetused;
sinakasrohelised juurutused;
tervisekontroll;
koormuse vähendamine;
liikluse peegeldamine;
isolatsioon;
päringute kiiruse piiramine, uuesti proovimised ja ajalõpud;
telemeetria;
audit;
visualiseerimine.

1. Teenuse avastamine

TL;DR: Loo ühendus teiste võrgus olevate teenustega lihtsate nimede abil.

Teenused peaksid suutma üksteist automaatselt sobivate nimede abil "leida", näiteks service.api.production, pets/staging või cassandraPilvekeskkondi iseloomustab elastsus ja üks nimi võib peita mitu teenuse eksemplari. Sellises olukorras on füüsiliselt võimatu kõiki IP-aadresse kõvakodeerida.

Lisaks peaks üks teenus, kui see avastab teise, saama sellele teenusele päringuid saata kartmata, et need satuvad rikkis instantsi sisendisse. Teisisõnu, teenusevõrk peab jälgima kõigi teenuseinstantside tervist ja hoidma hostinimekirja võimalikult ajakohasena.

Iga teenusevõrk rakendab teenuste avastamist erinevalt. Praegu on kõige levinum meetod delegeerimine välistele protsessidele, näiteks Kubernetes'i DNS-ile. Varem kasutasime Twitteris selleks otstarbeks nimesüsteemi. FinagleLisaks võimaldab teenindusvõrgu tehnoloogia luua kohandatud nimetamismehhanisme (kuigi ma pole veel ühtegi sellise funktsionaalsusega SM-i rakendust kohanud).

2. Krüpteerimine

TL;DR: Kõrvaldage teenustevaheline krüpteerimata liiklus ning muutke see protsess automatiseeritud ja skaleeritavaks.

On lohutav teada, et ründajad ei pääse teie sisevõrku. Tulemüürid teevad selle ärahoidmisel suurepärast tööd. Aga mis juhtub, kui häkker sisse pääseb? Kas nad saavad teie sisemise teenuseliiklusega teha, mida tahavad? Loodetavasti seda ei juhtu. Sellise stsenaariumi vältimiseks peaksite rakendama nullusaldusvõrgu, kus kogu teenustevaheline liiklus on krüpteeritud. Enamik tänapäevaseid teenusevõrke saavutab selle vastastikuse autentimise abil. TLS (vastastikune TLS, mTLS). Mõnel juhul töötab mTLS tervete pilvede ja klastrite ulatuses (ma arvan, et planeetidevaheline kommunikatsioon on kunagi sarnaselt üles ehitatud).

Muidugi, mTLS-i teenusevõrgu jaoks valikulineIga teenus saab hakkama oma TLS-iga, aga see tähendab sertifikaatide genereerimise viisi leidmist, nende levitamist teenuse hostide vahel ja rakendusse koodi lisamist nende sertifikaatide failidest laadimiseks. Ja ärge unustage neid sertifikaate regulaarselt uuendada. Teenusevõrgud automatiseerivad mTLS-i, kasutades selliseid süsteeme nagu SPIFFE, mis omakorda automatiseerivad sertifikaatide väljastamise ja roteerimise protsessi.

3. Autentimine ja autoriseerimine

TL;DR: Enne teenuseni jõudmist tehke kindlaks, kes päringu algatab ja mida neil on lubatud teha.

Teenused tahavad sageli teada, kes esitab päringu (autentimise) ja selle teabe põhjal otsustab, et See subjekt on volitatud tegema (volitus). Sel juhul võib asesõna "kes" viidata:

Muud teenused. Seda nimetatakse autentimiseks. peer'a"Näiteks teenindus web soovib teenusele ligi pääseda dbTeenusevõrgud lahendavad seda tüüpi probleeme tavaliselt mTLS-i abil, kus sertifikaadid toimivad vajaliku identifikaatorina.
Mõned inimesed. Seda nimetatakse autentimiseks. taotlused"Näiteks kasutaja haxor69 soovib osta uue lambi. Teenindusvõrgud pakuvad mitmesuguseid mehhanisme, näiteks JSON-i veebimärgid.
Paljud meist on seda oma rakenduse koodis teinud. Kui päring tuleb, vaatame läbi tabeli. users, leiame kasutaja ja võrdleme parooli, seejärel kontrollime veergu permissions jne. Teenusevõrgu puhul toimub see juba enne, kui päring teenuseni jõuab.

Kui oleme kindlaks teinud, kellelt päring tuli, peame kindlaks määrama, mida see subjekt teha tohib. Mõned teenusevõrgud võimaldavad teil määratleda põhipoliitikad (seoses sellega, kes mida teha saab) YAML-failide kujul või käsurealt, teised aga pakuvad integratsiooni raamistikega nagu Avatud poliitikaagentLõppeesmärk on, et teie teenused võtaksid vastu kõik päringud kindlustundega, et need pärinevad usaldusväärsest allikast. и See toiming on lubatud.

4. Koormuse tasakaalustamine

TL;DR: Jaotage koormus teenuse eksemplaride vahel vastavalt kindlale mustrile.

Teenuseosas olev „teenus” koosneb sageli mitmest identsest eksemplarist. Näiteks tänane teenus cache koosneb 5 eksemplarist ja homme võib nende arv tõusta 11-ni. Taotlused saadetakse aadressile cache, tuleb jaotada vastavalt kindlale eesmärgile. Näiteks latentsuse minimeerimiseks või terve eksemplari saavutamise tõenäosuse maksimeerimiseks. Kõige sagedamini kasutatakse ringjärjestuse algoritmi, kuid on ka palju teisi, näiteks kaalutud järjekorra meetod. (kaalutud) päringud (saate valida eelistatud sihtmärgid), helistage (rõngas) räsimine (kasutades ülesvoolu hostide jaoks järjepidevat räsimist) või vähimpäringute meetod (eelistatakse instantsi, millel on kõige vähem päringuid).

Klassikalised koormuse tasakaalustajad pakuvad ka muid funktsioone, näiteks HTTP vahemällu salvestamist ja DDoS-kaitset, kuid need pole eriti olulised ida-lääne suunalise liikluse (st andmekeskuses liikuva liikluse – tõlkija märkus) jaoks (teenusvõrgu tüüpiline rakendus). Kuigi koormuse tasakaalustamiseks pole teenindusvõrku vaja, võimaldab see teil määratleda ja juhtida iga teenuse koormuse tasakaalustamise poliitikaid tsentraliseeritud juhtimistasandilt, välistades seeläbi vajaduse juurutada ja konfigureerida eraldi koormuse tasakaalustajaid võrgupinus.

5. Kaitselüliti

TL;DR: Peatage liiklus probleemsele teenusele ja kontrollige kahju halvimal juhul.

Kui teenus mingil põhjusel liiklust hallata ei suuda, pakub teenusevõrk selle probleemi lahendamiseks mitu võimalust (teistest räägitakse vastavates osades). Teenuse liiklusest lahtiühendamise kõige tõsisem variant on vooluringi katkestamine. See on aga iseenesest kasutu – vajalik on varuplaan. Võib olla kaasas ka vastusurve. (vasturõhk) teenustele, mis täidavad päringuid (ärge unustage lihtsalt oma teenusevõrku selleks seadistada!) või näiteks olekulehe punaseks muutmine ja kasutajate suunamine lehe teisele versioonile, kus on "langev vaal" ("Twitter on maas").

Teenindusvõrgud võimaldavad teil mitte ainult kindlaks teha, kui järgneb sulgemine ja et järgneb. Sellisel juhul võib "millal" sisaldada mis tahes kombinatsiooni määratud parameetritest: päringute koguarv teatud aja jooksul, samaaegsete ühenduste arv, ootel päringud, aktiivsed uuestikatsed jne.

Sa ilmselt ei taha vooluahela katkestamist üle kasutada, aga on tore teada, et sul on hädaolukordadeks varuplaan.

6. Automaatne skaleerimine

TL;DR: Suurendage või vähendage teenuse eksemplaride arvu vastavalt määratud kriteeriumidele.

Teenusevõrgud ei ole ajastajad, seega nad ei tee seda. teostama Skaleeruvad iseseisvalt. Siiski saavad nad anda teavet, mida planeerijad saavad otsuste langetamiseks kasutada. Kuna teenusevõrkudel on juurdepääs kogu teenustevahelisele liiklusele, on neil ulatuslik teave toimuva kohta: millistel teenustel on probleeme, millised on alakasutatud (nende eraldatud võimsust raisatakse) jne.

Näiteks Kubernetes skaleerib teenuseid podide protsessori ja mälu kasutuse põhjal. (Vaata meie aruannet "Automaatne skaleerimine ja ressursside haldamine Kubernetesis"- ca. tõlge.), aga kui otsustate skaleerida mõne muu mõõdiku põhjal (meie puhul liiklusega seotud), vajate spetsiaalset mõõdikut. midagi sellist näitab, kuidas seda teha, kasutades saadik, Istio и Prometheus, aga protsess ise on üsna keeruline. Me sooviksime, et teenusevõrk seda lihtsustaks, võimaldades meil lihtsalt seada tingimusi, näiteks "suurendada teenuse eksemplaride arvu". auth, kui täitmist ootavate päringute arv ületab minuti piirmäära."

7. Kanaari saarte lähetused

TL;DR: Testi teenuse uusi funktsioone või versioone kasutajate alamhulgal.

Oletame, et arendate SaaS-toodet ja kavatsete välja anda uue laheda versiooni. Olete seda testimise käigus testinud ja see töötab laitmatult. Kuid teid ikka veel muretseb, kuidas see reaalsetes tingimustes toimib. Teisisõnu, peate uut versiooni reaalsetes stsenaariumides testima, ilma et peaksite kasutajate usaldust ohtu seadma. Canary juurutused sobivad selleks ideaalselt. Need võimaldavad teil uut funktsiooni demonstreerida väikesele hulgale kasutajatele. See alamhulk võib koosneda teie kõige lojaalsematest kasutajatest, toote tasuta versiooni kasutajatest või kasutajatest, kes on nõus katsejänesteks olema.

Teenusevõrgud saavutavad selle, võimaldades teil määrata kriteeriumid, mis määravad, kes teie rakenduse millist versiooni näeb, ja seejärel liiklust vastavalt suunata. Teenuste endi jaoks see aga midagi ei muuda. Teenuse versioon 1.0 eeldab, et kõik päringud tulevad kasutajatelt, kes peaksid seda nägema, ja versioon 1.1 eeldab sama oma kasutajate jaoks. Samal ajal saate vana ja uue versiooni vahelist liikluse protsenti varieerida, suunates üha suurema hulga kasutajaid uude versiooni, kui see on stabiilne ja teie "testisubjektid" selle heaks kiidavad.

8. Sinirohelised lähetused

TL;DR: Laadige välja lahe uus funktsioon, aga olge valmis see kohe tagasi võtma.

Tähendus sinirohelised juurutused Idee on käivitada uus "sinine" teenus, töötades paralleelselt vana, "rohelise" teenusega. Kui kõik läheb sujuvalt ja uus teenus toimib hästi, saab vana teenuse järk-järgult sulgeda. (Kahjuks tabab ka seda uut "sinist" teenust kunagi sama saatus kui "rohelist" ja see kaob...) Sinirohelised juurutused erinevad nn. "canary" juurutustest selle poolest, et uus funktsioon hõlmab kõik korraga kasutajad (mitte osa); mõte on siin selles, et oleks olemas "varu sadam" juhuks, kui midagi valesti läheb.

Teenusevõrgud pakuvad väga mugavat viisi "sinise" teenuse testimiseks ja probleemi korral koheselt toimivale "rohelisele" teenusele lülitumiseks. Lisaks pakuvad need ka rohkelt teavet (vt allpool jaotist "Telemeetria") "sinise" teenuse jõudluse kohta, aidates kindlaks teha, kas see on täielikuks tootmiseks valmis.

Märge. tõlgeKubernetes'i erinevate juurutusstrateegiate (sh mainitud Canary, Blue/Green ja teised) kohta saate lugeda lähemalt siit. see artikkel.

9. Tervisekontroll

TL;DR: Jälgige, millised teenuseeksemplarid on terved, ja reageerige neile, mis muutuvad ebatervislikuks.

Tervise kontroll (tervisekontroll) aitab otsustada, kas teenuse eksemplarid on liikluse vastuvõtmiseks ja töötlemiseks valmis. Näiteks HTTP-teenuste puhul võib tervisekontroll välja näha nagu GET-päring lõpp-punktile. /healthVastus 200 OK tähendab, et eksemplar on terve, samas kui iga muu tähendab, et see pole liikluse vastuvõtmiseks valmis. Teenusevõrgud võimaldavad teil määrata nii tervisekontrolli meetodi kui ka selle teostamise sageduse. Seda teavet saab seejärel kasutada muudel eesmärkidel, näiteks koormuse tasakaalustamiseks ja vooluringi katkestamiseks.

Seega ei ole tervisekontrollid iseseisev kasutusjuhtum, vaid neid kasutatakse tavaliselt muude eesmärkide saavutamiseks. Samuti võivad tervisekontrollide tulemustest olenevalt olla vajalikud toimingud väljaspool teisi teenusevõrgu eesmärke: näiteks olekulehe värskendamine, GitHubi probleemi loomine või JIRA-pileti esitamine. Ja teenusevõrk pakub mugavat mehhanismi kõige selle automatiseerimiseks.

10. Koormuse vähendamine

TL;DR: Liikluse ümbersuunamine vastusena ajutisele kasutuse suurenemisele.

Kui teenus on liiklusega ülekoormatud, saate osa sellest liiklusest ajutiselt teise kohta suunata (nt selle „maha visata“ või „välja valada“). (kuur) (näiteks varundusteenusesse või andmekeskusesse või püsivasse press teema. Selle tulemusel jätkab teenus mõne päringu töötlemist, selle asemel et krahhida ja kõigi päringute töötlemine peatada. Koormuse vähendamine on eelistatavam kui ahela katkestamine, kuid selle ülekasutamine on siiski ebasoovitav. See aitab vältida kaskaadseid tõrkeid, mis võivad viia allavoolu teenuste kokkuvarisemiseni.

11. Liikluse paralleelsus/peegeldamine

TL;DR: Saada üks päring korraga mitmesse kohta.

Mõnikord on vaja saata päring (või valik päringuid) samaaegselt mitmele teenusele. Tüüpiline näide on osa tootmisliikluse saatmine testimisteenusele. Peamine tootmisveebiserver saadab päringu allavooluteenusele. products.production ja ainult temale. Ja teenindusvõrk kopeerib selle päringu intelligentselt ning saadab selle aadressile products.staging, millest veebiserver isegi ei tea.

Teine seotud teenindusvõrgu kasutusjuhtum, mida saab rakendada liikluse paralleelsusele lisaks, on regressioontestimineSee hõlmab samade päringute saatmist teenuse erinevatele versioonidele ja kontrollimist, kas kõik versioonid käituvad identselt. Ma pole veel näinud teenusevõrgu rakendust integreeritud regressioontestimise süsteemiga, näiteks Diffy, aga idee ise tundub paljulubav.

12. Isolatsioon

TL;DR: Jaga oma teenindusvõrk minivõrkudeks.

Tuntud ka kui segmenteerimineIsoleerimine on kunst, kus teenusevõrk jagatakse loogiliselt eraldi segmentideks, mis pole üksteisest teadlikud. Isoleerimine sarnaneb mõnevõrra virtuaalsete privaatvõrkude loomisega. Peamine erinevus seisneb selles, et saate endiselt nautida kõiki teenusevõrgu eeliseid (näiteks teenuste avastamist), kuid lisaturvalisusega. Näiteks kui ründajal õnnestub tungida teenusesse ühes alamvõrgus, ei näe ta, millised teenused teistes alamvõrkudes töötavad, ega saa nende liiklust pealt kuulata.

Samuti võib olla organisatsioonilisi eeliseid. Võib-olla soovite jagada teenused alamvõrkudeks vastavalt oma ettevõtte struktuurile ja vabastada arendajad kognitiivsest koormast, mis kaasneb kogu teenusevõrgu jälgimisega.

13. Taotluste kiiruse piiramine, uuesti proovimine ja ajalõpud

TL;DR: Koodibaasi pole enam vaja lisada aeganõudvaid päringute haldamise ülesandeid.

Kõiki neid asju võiks pidada eraldi kasutusjuhtudeks, kuid otsustasin need ühendada ühe ühise omaduse tõttu: need vabastavad päringute elutsükli haldusülesannetest, mida tavaliselt täidavad rakendusteegid. Kui arendate Ruby on Rails veebiserverit (mis pole teenusevõrguga integreeritud), mis teeb päringuid taustteenustele läbi gRPC, peab rakendus ise otsustama, mida teha, kui N päringut ebaõnnestub. Samuti peab see määrama, kui palju liiklust need teenused suudavad käsitleda, ja need parameetrid spetsiaalse teeki abil kõvakodeerima. Lisaks peab rakendus otsustama, millal loobuda ja lasta päringul aeguda (kasutades ajalõpu). Ja mis tahes ülaltoodud parameetri muutmiseks tuleb veebiserver peatada, uuesti konfigureerida ja taaskäivitada.

Nende ülesannete delegeerimine teenusevõrgule mitte ainult ei välista teenusearendajate vajadust nende üle järele mõelda, vaid võimaldab neid ka terviklikumalt käsitleda. Kui tegemist on keeruka teenuste ahelaga, näiteks A –> B –> C –> D –> E, tuleb arvesse võtta kogu päringu elutsüklit. Kui ülesandeks on teenuse C ajalõpude pikendamine, on mõistlik teha seda kõike korraga, mitte osade kaupa: värskendada teenuse koodi ja oodata, kuni pull-päring aktsepteeritakse ja CI-süsteem värskendatud teenuse juurutab.

14. Telemeetria

TL;DR: Koguge teenustelt kogu vajalik (ja mitte päris vajalik) teave.

Telemeetria on üldmõiste, mis hõlmab mõõdikuid, hajutatud jälgimist ja logimist. Teenusevõrgud pakuvad mehhanisme kõigi kolme andmetüübi kogumiseks ja töötlemiseks. Siin läheb asi veidi segaseks, kuna võimalike valikute arv on tohutu. Mõõdikute kogumiseks on olemas Prometheus ja muud tööriistad, mida saab logide kogumiseks kasutada ladusalt, Loki, vektor jne (näiteks ClickHouse meie palkmaja K8-de puhul — tõlkija märkus), hajutatud jälgimise jaoks on olemas Jaeger jne. Iga teenindusvõrk võib toetada mõnda tööriista ja teisi mitte. Huvitav on näha, kas projekt suudab Avatud telemeetria pakkuda teatavat lähenemist.

Sellisel juhul on teenindusvõrgu tehnoloogia eeliseks see, et külgkorviga konteinerid saavad põhimõtteliselt koguda kõiki ülaltoodud andmeid oma teenustest. Teisisõnu, teie käsutuses on ühtne telemeetria kogumissüsteem ja teenindusvõrk saab kogu seda teavet mitmel viisil töödelda. Näiteks:

CLI teatud teenuse sabalogid;
Jälgige päringute mahtu teenusevõrgu armatuurlaual;
koguda hajutatud jälgi ja edastada need süsteemile nagu Jaeger.

Tähelepanu, subjektiivne hinnang: Üldiselt on telemeetria valdkond, kus ulatuslik võrgusilma sekkumine on ebasoovitav. Põhiandmete kogumine ja mõnede "kuldsete mõõdikute" (nt edukuse määrad ja latentsus) jälgimine on okei, kuid loodame, et me ei näe Frankensteini süsteemide tekkimist, mis üritavad asendada spetsialiseeritud süsteeme, millest mõned on juba tõestatud ja hästi uuritud.

15. Audit

TL;DR: Need, kes unustavad ajaloo õppetunnid, on määratud neid kordama.

Auditeerimine on süsteemi oluliste sündmuste jälgimise kunst. Teenusevõrgu puhul võib see tähendada selle jälgimist, kes esitas päringuid konkreetsete teenuste konkreetsetele lõpp-punktidele või mitu korda viimase kuu jooksul toimus teatud turvalisusega seotud sündmus.

On selge, et auditeerimine on tihedalt seotud telemeetriaga. Erinevus seisneb selles, et telemeetriat seostatakse tavaliselt selliste asjadega nagu jõudlus ja tehniline terviklikkus, samas kui auditeerimine võib olla seotud juriidiliste ja muude küsimustega, mis ulatuvad kaugemale rangelt tehnilisest valdkonnast (näiteks vastavus ELi isikuandmete kaitse üldmäärusele ehk GDPR).

16. Visualiseerimine

TL;DR: Elagu React.js, veidrate liideste allikas.

Võib-olla on olemas sobivam termin, aga ma ei tea seda. Ma pean silmas lihtsalt teenusevõrgu või mõne selle komponendi graafilist esitust. Need visualiseeringud võivad sisaldada indikaatoreid nagu keskmine latentsusaeg, kõrvalkonteineri konfiguratsiooniteave, tervisekontrolli tulemused ja hoiatused.

Teenusele orienteeritud keskkonnas töötamine on seotud palju suurema kognitiivse koormusega kui Tema Majesteedi Monoliidis. Seetõttu tuleks kognitiivset survet iga hinna eest vähendada. Lihtne graafiline liides teenindusvõrgu jaoks, mis võimaldab kasutajatel nupule klõpsata ja soovitud tulemuse saada, võib olla selle tehnoloogia kasvu jaoks ülioluline.

Ei olnud nimekirja kantud

Algselt kavatsesin nimekirja lisada veel mõned kasutusjuhud, aga otsustasin siis selle vastu. Siin on need koos minu otsuse põhjustega:

Mitme andmekeskuseMinu arvates pole see niivõrd kasutusjuhtum, kuivõrd kitsas ja spetsiifiline teenusevõrkude või teatud funktsioonide komplekti, näiteks teenuste avastamise, rakendusala.
Sisse- ja väljapääsSee on seotud valdkond, aga olen piirdunud (võib-olla kunstlikult) "ida-lääne suunalise liikluse" kasutusjuhtumiga. Sisse- ja väljapääs väärivad eraldi artiklit.

Järeldus

See on praegu kõik! Jällegi, see nimekiri on väga üldine ja tõenäoliselt mittetäielik. Kui arvate, et olen midagi kahe silma vahele jätnud või vea teinud, võtke minuga ühendust Twitteris (@lucperkins). Palun järgige sündsuse reegleid.

PS tõlkijalt

Artikli peamine illustratsioon põhineb artiklist pärit pildil "Mis on teenindusvõrk (ja millal seda kasutada)?"(Gregory MacKinnoni poolt). See näitab, kuidas osa rakenduste (roheline) funktsionaalsusest on migreerunud teenindusvõrku, mis pakub nendevahelisi ühendusi (sinine).

Loe ka meie blogist:

Allikas: www.habr.com