🥇 Service meshi kasutusjuhtumid

Märk. tõlge.: Artikli autor on (Luc Perkins) — arenduse advokaat organisatsioonis CNCF, mis on kodu selliste avatud lähdekoodiga projektide nagu Linkerd, SMI (Service Mesh Interface) ja Kuma (kas olete muide kas mõelnud, miks selle nimekirja ei ole Istio?). Ta üritab taas tuua DevOps kogukonda paremat arusaamist moderaarsest kõnest nimega 'service mesh', tuues välja 16 iseloomulikku võimalust, mida sellised lahendused pakuvad.

Täna teenuse võrk ― üks kuumimaid teemasid tarkvaraarenduse valdkonnas (ja põhjusega!). Pean seda tehnoloogiat uskumatult perspektiivikaks ja unistan, et olen tunnistajaks selle laiale levikule (muidugi, kui see on mõistlik). Sellegipoolest on see endiselt enamus inimeste jaoks salapärane. Isegi need, kes on sellega hästi tuttavad vaevavad sageli selle eeliste vormistamist ja seda, mis see tegelikult on (sealhulgas ka teie alandlik teenija). Artiklis püüan olukorda parandada, loetledes erinevaid kasutussfääre 'teenuse võrke'*.

* Märk. tõlk.: selles ja järgnevates artikli lõikudes kasutatakse sõna 'teenuse võrk' selle veel uue 'service mesh' termini tõlkena.

Aga kõigepealt tahan teha mõned märkused:

Ma ei ole kunagi töötanud teenuste võrkudega ega kasutanud neid projektides, mis on algatatud ainult minu hariduse huvides. Teisest küljest kirjutasin ma 2015. aastal Twitteri ettevõtte sisemise teenuste võrgu jaoks palju dokumentatsiooni (sel ajal ei kutsutud seda isegi «teenuste võrguks») ning osalesin veebisaidi ja dokumentatsiooni arendamises. Linkerd, seega on see midagi.
Minu nimekiri on näitlik ja mittetäielik. Võivad olla minu teadmata kasutusstsenaariumid, ja aja jooksul tekivad kindlasti uued variandid, kui tehnoloogia areneb ja muutub populaarsemaks.
Samas ei toeta sugugi iga olemasolev teenuste võrgu rakendus kõiki loetletud kasutusjuhte. Seetõttu tuleks minu väljendeid nagu «teenuste võrk võib...» lugeda kui «erilised ja võib-olla kõik populaarsed teenuste võrgu rakendused võivad...».
Näidete järjekord ei oma mingit tähtsust.

Lühike nimekiri:

teenuste avastamine;
krüpteerimine;
autentimine ja autoriseerimine;
koormuse tasakaalustamine;
circuit breaking;
automaatne skaleerimine;
kanarollid;
sinine-roheline juurutamine;
tervise kontrollimine;
koormuse vähendamine;
liikluse peegeldamine;
isoleerimine;
päringute sageduse piiramine, uued katsed ja ajutised katkestused;
telemeetrielamu;
audiit;
visualiseerimine.

1. Teenuste avastamine

TL;DR: Ühendage võrgu teiste teenustega lihtsate nimede kaudu.

Teenused peavad olema suutelised automaatselt „leidma“ üksteist adekvaatsete nimede kaudu — näiteks, service.api.production, pets/staging või cassandra. Pilvekeskkonnad on tuntud oma elastsete omaduste poolest ning ühe nime all võib peituda hulgaliselt teenuse eksemplare. On selge, et sellises olukorras on füüsiliselt võimatu kõiki IP-aadresse hardcode'ida.

Lisaks peab, kui üks teenus leiab teise, olema sellel võimalus saata päringuid sellele teenusele, kartmata, et need jõuavad tema mitte töötava eksemplarini. Teisisõnu, teenuste mesh peab jälgima kõigi teenuste eksemplaride töökõlblikkust ja hoidma hostide nimekirja maksimaalselt ajakohasena.

Iga teenusevaheline võrgustik rakendab teenuste avastamise mehhanismi omal moel. Praegu on kõige levinum viis järgida välistes protsessides nagu DNS Kubernetes. Minevikus kasutasime Twitteris selleks nimelt nimed süsteemi. Finagle. Lisaks võimaldab teenusevaheline tehnoloogia kasutajate nimede mehhanismide loomist (kuigi ma pole veel kohanud ühtegi SM-i teostust, millel oleks see funktsionaalsus).

2. Krüpteerimine

TL;DR: Vabanege krüpteerimata liiklusest teenuste vahel ja laske sellel protsessil olla automatiseeritud ja skaalautuv.

On hea tunne, et kurjategijad ei saa teie sisevõrku tungida. Tulega töötavad tulemüürid teevad sellega head tööd. Kuid mis juhtuks, kui häkker siiski siseneb? Kas ta võib teha kõike, mida soovib, sise-teenuse liiklusega? Lootkem, et seda siiski ei juhtu. Selliste stsenaariumide vältimiseks tuleks rakendada null usalduse võrgustikku, kus kogu liiklus teenuste vahel on krüpteeritud. Enamik kaasaegseid teenusevõrke saavutab seda vastastikuse TLS (mutual TLS, mTLS). Mõnes olukorras töötab mTLS kogu pilve- ja klastrikeskkondades (ma arvan, et ühel päeval on ka planeetidevahelised suhtlused sarnased).

Muidugi, mTLS teenuse võrgu jaoks ei ole kohustuslik. Iga teenus saab ise hoolitseda oma TLS-i eest, kuid see tähendab, et tuleb leida viis sertifikaatide genereerimiseks, nende jaotamiseks teenuse hostidele ning rakendusse koodi kaasamiseks, mis laadib need sertifikaadid failidest. Ja ärge unustage ka sertifikaatide uuendamist kindlate ajavahemike järel. Teenuste võrgud automatiseerivad mTLS-i süsteemide, nagu SPIFFE, abil, mis omakorda automatiseerivad sertifikaatide väljastamise ja ründamise protsessi.

3. Autentimine ja autoriseerimine

TL;DR: Määrake, kes on päringu algataja, ja määrake, mida on lubatud teha, enne kui päring jõuab teenuseni.

Teenused soovivad tihti teada, kes kes teeb päringu (autentimine), ja kasutades seda teavet, otsustavad, mida kas antud subjektile on lubatud tegutseda (autoriseerimine). Selles kontekstis võib mõiste 'kes' hõlmata:

Teised teenused. Seda nimetatakse 'peer' autentimiseks. peer'а». Näiteks, teenus web soovib pääseda teenusele db. Teenusvõrgud lahendavad tavaliselt selliseid probleeme mTLS abil: sertifikaadid toimivad antud juhul vajaliku identifikaatorina.
Mõned kasutajad-inimesed. Seda nimetatakse "autentimiseks päringu». Näiteks, kasutaja haxor69 soovib osta uut lampi. Teenusvõrgud pakuvad erinevaid mehhanisme, näiteks JSON Web Tokens.
Paljude meist on olnud selle tegemine rakenduskoodis. Tuleb päring, vaatame tabelit users, leiame kasutaja ja võrdleme parooli, seejärel kontrollime välja permissions jne. Teenusvõrgu puhul toimub see juba enne, kui päring jõuab teenuseni.

Pärast seda, kui oleme kindlaks teinud, kellega päring tulnud on, tuleb välja selgitada, mida sellele subjektile teha lubatakse. Mõned teenusvõrgud võimaldavad määrata põhipoliitikaid (kes ja mida võib teha) YAML-failide või käsurea vormis, samas kui teised pakuvad integreerimist nagu Open Policy Agent. Lõppeesmärgiks on saavutada, et teie teenused aktsepteeriksid iga päringu, julgelt eeldades, et need pärinevad usaldusväärsest allikast. ja see tegevus on lubatud.

4. Koormuse tasakaalustamine

TL;DR: Jagage koormust teenuse eksemplaride vahel kindla mustri alusel.

„Teenuse“ koosseisus on teenuse grupis väga sageli palju identseid eksemplare. Näiteks täna koosneb teenus cache 5 eksemplarist, samas kui homseks võib nende arv tõusta 11-ni. Taotlused, mis suunatakse cache, tuleks jaotada vastavalt kindlale eesmärgile. Näiteks vähendada latentsust või maksimeerida tõenäosust, et jõuate toimiva eksemplari juurde. Kõige sagedamini kasutatakse tsüklilist teenindusmeetodit (Round-robin), kuid on olemas ka palju teisi — näiteks kaalutud (weighted) taotlused (võite valida eelistatud eesmärgid), rõngas (ring) hashimine (kasutades kooskõlastatud hashimist upstream-hostide jaoks) või väheseima taotluste arvu meetod (eelistatakse eksemplari, millel on kõige vähem taotlusi).

Klassikalised koormuse jaoturid omavad ka muid funktsioone, nagu HTTP va cache ja DDoS kaitse, kuid need ei ole eriti relevantsed idalääne liikluse (st liikluse, mis toimub andmekeskuses – tõlke märkus) jaoks (tüüpiline rakenduskoht teenusevõrgus). Loomulikult pole koormuse jaotamiseks võimalik kasutada teenusevõrku, kuid see võimaldab määrata ja hallata jaotuste poliitikaid iga teenuse jaoks tsentraliseeritud halduskihtidega, eemaldades seeläbi vajaduse käitada ja konfigureerida eraldi jaotureid võrgusteemis.

5. Ahela katkestamine (circuit breaking)

TL;DR: Peatage liiklus probleemse teenuse juurde ja kontrollige kahjustusi halvimates stsenaariumides.

Kui mingil põhjusel teenus ei suuda liiklust taluda, siis teenusevõrk pakub mitmeid võimalusi selle probleemi lahendamiseks (teistest räägitakse vastavates jaotistes). Ahela katkestamine on kõige rangem variant teenuse liiklusest väljalülitamiseks. Kuid sellel endal pole mõtet – vajalik on varuplaan. See võib sisaldada tagasivoolu. (tagasivool) teenuste jaoks, mis täidavad päringute, (kuid ärge unustage oma teenuseteed selle jaoks konfigureerida!), või näiteks staatuse lehe punaseks värvimine ja kasutajate suunamine uuesti lehe versioonile koos «langemise kits» («Twitter on maas»).

Teenusevõrgud võimaldavad mitte ainult määrata, millal tuleb katkestamine ja mida mida see järgneb. Selles kontekstis «millal» võib hõlmata mis tahes määratud parameetrite kombinatsiooni: üldine päringute arv teatud ajavahemikus, samadedikat ühendused, ootel päringud, aktiivsed uuesti proovimise katsetused jne.

Te tõenäoliselt ei soovi circiit breaking’ut kuritarvitada, kuid on hea teada, et äärmuslike olukordade jaoks on olemas varuplaan.

6. Automaatne skaalaimine

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

Teenusevõrgud ei ole planeerijad, seega nad ei täida skaalate ise. Kuid nad saavad edastada teavet, mille alusel planeerijad otsuseid teevad. Kuna service mesh'id saavad ligi kogu teenustevahelisele liiklusele, omavad nad ulatuslikku teavet selle kohta, mis toimub: millised teenused kogevad probleeme, millised on minimaalselt koormatud (neile määratud ressursid raisatakse) jne.

Näiteks Kubernetes skaala teenuseid vastavalt pod'ide CPU ja mälu kasutusele. (vt meie ettekannet „Automaatne skaala ja ressursside haldamine Kuberneteses» — tõlk. märkus), kuid kui otsustate teostada skaalatamise mõne muu näitaja alusel (meie puhul - liiklusega seotud), on vajalik eriline mõõdik. Juhend taolise näitab, kuidas seda teha kasutades Envoy, Istio ja Prometheus, kuid kogu protsess on üsna keeruline. Me tahaksime, et service mesh lihtsustaks seda, lubades lihtsalt seada tingimused nagu „suurenda teenuse eksemplaride arvu, auth, kui ootejärjekorras olevate päringute arv ületab ülempiiri minuti jooksul.”

7. Kanaride juurutused

TL;DR: Katsetage uusi funktsioone või teenuse versioone teatud kasutajate alagruppide peal.

Oletame, et arendate uut SaaS-toodet ja kavatsete selle uue versiooni välja tuua. Olete selle testinud staging keskkonnas ja see töötab suurepäraselt. Siiski on teil mured selle tõhususe üle reaalses keskkonnas. Teisisõnu, peate kontrollima uut versiooni päris ülesannete peal, riskimata samal ajal kasutajate usaldusega. Kanaride juurutamised sobivad selleks suurepäraselt. Need võimaldavad tutvustada uut funktsiooni teatud valitud kasutajatele. See valik võib koosneda kõige lojaalsetest kasutajatest, tasuta versiooniga töötavatest kasutajatest või neist, kes on väljendanud soovi olla 'katsealuseks'.

Teenusmesh'id rakendavad seda, võimaldades määrata kriteeriumid, mis määravad, kes ja millist rakenduse versiooni näeb, ning suunavad liiklust vastavalt. Teenuste jaoks ei muutu midagi. Teenuse versioon 1.0 arvab, et kõik päringud tulevad kasutajatelt, kes just selle versiooni peavad nägema, ja versioon 1.1 arvab sama oma kasutajate kohta. Samal ajal saate muuta liikluse protsenti vana ja uue versiooni vahel, suunates kasvavat arvu kasutajaid uuele, kui see töötab stabiilselt ja teie “katsealused” annavad heakskiidu.

8. Sinise-rohelised juurutused

TL;DR: Laske välja uus suur funktsioon, kuid olge valmis see kohe tagasi võtma.

Mõte sinise-roheliste juurutuste on see, et käivitatakse uus „sinine” teenus, käivitades selle paralleelselt vana, „rohelise” teenusega. Kui kõik läheb sujuvalt ja uus teenus tõestab end hästi, saab vana järk-järgult välja lülitada. (Kahjuks kordab ka see uus „sinine” teenus kunagi „rohelist” saatust ja kaob…) Sinise-rohelised juurutused erinevad kanarakkudest selle poolest, et uus funktsioon katab kõik korraga kasutajad (mitte osa); mõte on olla valmis "varupordiks", kui midagi peaks valesti minema.

Teenuste vmessid pakuvad väga mugavat viisi "sinise" teenuse testimiseks ja koheseks üleminekuks töötavale "rohelisele" teenusele, kui probleeme tekib. Rääkimata sellest, et nad annavad palju teavet (vt punkt "Telemeetria" allpool) "sinise" töö kohta, mis aitab mõista, kas see on täielikuks kasutamiseks valmis.

Märk. tõlge.: Erinevatest käitamisstrateegiatest Kuberneteses (sealhulgas mainitud kanarid, sinine/roheline jne) saab lugeda selles artiklis.

9. Tervise kontrollimine

TL;DR: Jälgige, millised teenuse eksemplarid on töökorras, ja reageerige nendele, mis enam ei ole.

Tervise kontrollimine (health check) aitab otsustada, kas teenuse eksemplarid on valmis vastu võtma ja töötlema liiklust. Näiteks HTTP-teenuste puhul võib tervise kontrollimine välja näha kui GET-päring teenuse lõpp-punktile /health. Vastus 200 OK tähendab, et eksemplar on tervislik, kõik muu - et see ei ole valmis liiklust vastu võtma. Teenuse mesh’id võimaldavad määrata, kuidas ja kui tihti visatakse töövõimekust kontrollitakse. Seda teavet saab seejärel kasutada ka teiste eesmärkide täitmiseks - näiteks koormuse tasakaalustamiseks ja circuit breaking'uks.

Seega on tervise kontroll mitte iseseisev kasutusstsenaarium, vaid seda kasutatakse tavaliselt teiste eesmärkide saavutamiseks. Samuti võivad vastavalt tervisekontrollide tulemustele osutuda vajalikuks välised tegevused (seoses teiste teenuse võrkude eesmärkidega): näiteks oleku lehe värskendamine, probleemide loomine GitHubis või JIRA pileti täitmine. Ja teenuse mesh pakub mugavat mehhanismi selle kõikide automatiseerimiseks.

10. Koormuse suunamine (load shedding)

TL;DR: Suunake liiklus vastusena ajutisele kasutamise tõusule.

Kui mõni teenus osutub liiklusega üle koormatud, saate ajutiselt suunata osa sellest liiklusest teise kohta (st 'süttida', 'valada' (shed) seda sinna). Näiteks varukoopie teenusesse või andmekeskusesse, või pidevalt Pulsar teema. Seega jätkab teenus osade päringute töötlemist, selle asemel, et täielikult kokku kukkuda ja töötlemise lõpetada. Koormuse vähendamine on eelistatum kui ahelate katkestamine, kuid siiski ei tohiks seda kuritarvitada. See aitab vältida kaskaadtoimingute ebaõnnestumisi, mis viivad alla downstream-teenuseid.

11. Liikluse paralleelseks jagamiseks/peegeldamiseks

TL;DR: Saatke üks päring kohe mitmesse kohta.

Mõnikord tekib vajadus saata päring (või teatud valik päringuid) kohe mitmesse teenusesse. Iseloomulik näide on osa tootmisliiklusest saatmine stseeniteenusesse. Peamine veebiserver tootmises saadab päringu allolevale teenusele products.production ja ainult sellele. Samal ajal kopeerib teenuse mesh intelligentselt selle päringu ja saadab selle products.staging, millest veebiserver isegi ei tea.

Veel üks seotud teenusemesh'i kasutusstsenaarium, mille võib rakendada liikluse paralleelse jagamise kohal, on regressiooni testimine. See võimaldab saata samaaegseid päringuid erinevatele teenuse versioonidele ja kontrollida, kas kõik versioonid käituvad ühtemoodi. Mul pole veel kohanud teenusetehase rakendust integreeritud tagasiregresseerimise testimise süsteemiga nagu Diffy, kuid idee ise tundub paljutõotav.

12. Isolatsioon

TL;DR: Jagage oma teenusetehas mini-võrkudeks.

Tuntud ka kui segmenteerimine, isolatsioon on kunst jagada teenusetehast loogiliselt eraldatud segmentideks, mis ei tea üksteisest midagi. Isolatsioon sarnaneb virtuaalsete privaatvõrkude loomisega. Peamine erinevus on see, et saate silti kasutada teenusetehase kõiki eeliseid (näiteks teenuste avastamine), kuid lisatud turvalisusega. Näiteks kui kurjategija suudab tungida teenusesse ühes alamvõrgus, ei näe ta, millised teenused on käimas teistes alamvõrkudes, ega saa nende liiklust katkestada.

Samuti võivad eelised olla ka organisatsioonilised. Võib-olla soovite teenuseid jagada alamvõrkudesse vastavalt ettevõtte struktuurile ja vabastada arendajad kognitiivsest koormast, mis tuleneb vajadusest meeles pidada kogu service mesh'i.

13. Päringute sageduse piiramine, uuesti proovima ja ajaoutsid

TL;DR: Ei ole enam vaja lisada koodibaasi hädavajalikke päringute haldamise ülesandeid.

Kõiki neid asju võiks käsitleda eraldi kasutusjuhtumitena, kuid otsustasin need ühendada, kuna neil on üks ühine joon: need võtavad enda kanda päringute elutsükli haldamise ülesanded, mida tavaliselt töötavad välja rakenduste raamatukogud. Kui arendate Ruby on Rails'il põhinevat veebiserverit (mis ei ole integreeritud service mesh'iga), mis teostab päringuid backend-teenustele läbi gRPC, rakendus peab ise otsustama, mida teha, kui N päringut ebaõnnestub. Samuti tuleb välja selgitada, kui palju liiklust saavad need teenused töödelda ja need parameetrid 'hardcode' õigete teekide abil. Lisaks peab rakendus otsustama, millal on aeg loobuda ja lasta päringul aeguda (timeout). Ja et muuta mõnda ülaltoodud parameetrit, tuleb veebiserver peatada, ümber konfigureerida ja uuesti käivitada.

Nende ülesannete edastamine teenuste võrgule tähendab mitte ainult seda, et teenuste arendajad ei pea nende üle mõtlema, vaid ka seda, et neid saab vaadelda laiemalt. Kui kasutatakse keerulist teenuste ahelat, nagu A –> B –> C –> D –> E, tuleb arvesse võtta kogu päringu elutsüklit. Kui on eesmärk pikendada teenuse C ajalimiite, on mõistlik see kõikühel teha, mitte osa kaupa: uuendades teenuse koodi ja oodates, kuni pull request on vastu võetud ja CI-süsteem uue teenuse üles seab.

14. Telemeetria

TL;DR: Koguge kogu vajalik (ja mitte ainult) teave teenustelt.

Telemeetriat on üldtermin, mis hõlmab metrikat, jaotatud jälgimist ja logisid. Teenuse võrgud pakuvad mehhanisme nende kolme andmetüübi kogumiseks ja töötlemiseks. Siin hakkab asi veidi ähmaseks minema, kuna võimaluste hulk on liiga suur. Metriika kogumiseks on olemas Prometheus ja teised tööriistad, logide kogumiseks võib kasutada fluentd, Loki, Vector jne. (näiteks ClickHouse koos meiega loghouse K8s jaoks — tõlkija märkus), jaotatud jälgimise jaoks on olemas Jaeger jne. Iga teenuse võrk võib toetada mõndade tööriistu ja mitte toetada teisi. On huvitav näha, kas projekt Open Telemetry suudab pakkuda mingit konvergentsi.

Antud juhul on teenuse võrgu tehnoloogia eelis selles, et sidecar konteinerid võivad põhimõtteliselt koguda kõiki eespool loetletud andmeid oma teenustelt. Teisisõnu, teil on käsutuses ühtne telemeetriakogumissüsteem ja teenuse võrk suudab muuta kogu selle teabe töötlemise erinevateks viisideks. Näiteks:

logide jälgimine mõnelt teenuselt CLI-s;
taotluste mahu jälgimine teenuse võrgu jälgimisnavigatsioonil;
koguda ja suunata hajutatud jälgimiskuud süsteemi, nagu Jaeger.

Tähelepanu, subjektiivne arvamus: Üldiselt on telemeetriaga selline olukord, kus teenuste võrgu tugev sekkumine on soovimatu. Alusinfo kogumine ja mõningate „kuldsete mõõdikute” reaalajas jälgimine, nagu näiteks edukaid päringute protsent ja latentsus, on normaalne, kuid loodame, et me ei ole tunnistajaks mõnede Frankenstein-stekide sündimisele, mis üritavad asendada spetsialiseeritud süsteeme, millest mõned on juba hästi tõestatud ja hästi uuritud.

15. Audit

TL;DR: Kes unustab ajaloo õppetunnid, on määratud neid kordama.

Audit on kunst jälgida olulisi sündmuseid süsteemis. Teenuste võrgu puhul võib see tähendada jälgimist, kes tegi päringuid teatud teenuste spetsiifiliste lõpp-punktide juurde või kui tihti on viimase kuu jooksul toimunud mingi sündmus, mis on seotud turvalisusega.

On selge, et audite on tihedalt seotud telemeetria. Erinevus seisneb aga selles, et telemeetria seondub tavaliselt sellistele asjadele nagu jõudlus ja tehniline tõhusus, samas kui audit võib puudutada õiguslikke ja muid küsimusi, mis ulatuvad kaugemale rangest tehnilisest sfäärist (näiteks GDPR-i nõuete järgimine — Euroopa Liidu isikuandmete kaitse üldmäärus).

16. Visualiseerimine

TL;DR: Elagu React.js — väsimatu allikas veidratele liidesele.

Võib-olla on olemas sobivam termin, aga ma ei tea seda. Pean lihtsalt silmas service mesh'i või selle komponentide graafilist esitamist. Need visualiseerimised võivad sisaldada näitajaid nagu keskmised viivitused, teavet sidecar konteinerite konfiguratsiooni, tervisekontrolli tulemusi ja teateid.

Töö teenusele suunatud keskkonnas eeldab palju suuremat kognitiivset koormust võrreldes Kõrge Üksuse Monoliidiga. Seetõttu tuleks kognitiivset koormust igal võimalusel vähendada. Lihtne graafiline liides teenuste võrgustiku jaoks, kus saab nuppu vajutada ja soovitud tulemus kätte saada, võib olla selle tehnoloogia populaarsuse kasvu jaoks ülioluline.

Mitte kõik ei olnud nimekirjas

Alguses kavatsesin lisada nimekirja veel mõned kasutusjuhtumid, kuid otsustasin seda mitte teha. Siin nad koos minu otsuse põhjendustega:

Mitmed andmekesksed keskustest. Minu arvates ei ole see niivõrd kasutusjuhtum kui pigem kitsas ja spetsiifiline valdkond, kus teenuste võrgud või mõne funktsiooni nagu teenuste avastamine, rakenduvad.
Sisse- ja väljaminek. See on seotud valdkond, kuid piirdusin (võimalikult kunstlikult) kasutusjuhtumiga „ida-lääne liiklus“. Sisse- ja väljaminek väärivad eraldi artiklit.

Kokkuvõte

Sellega on kõik! Jällegi, see nimekiri on üsna tinglik ja tõenäoliselt puudulik. Kui arvad, et ma midagi unustasin või olen kuskil eksinud, võta minuga Twitteris ühendust (@lucperkins). Palun järgige käitumisreegleid.

P.S. tõlkija märkused

Artikli peanäidisena on kasutatud pilti artiklist „Mis on service mesh (ja millal seda kasutada)?“ (autor — Gregory MacKinnon). Sellel on kujutatud, kuidas osa rakenduste funktsionaalsusest (roheline) on liikunud service mesh'i, tagades nende vahelise ühenduse (sinine).

Lugege ka meie blogist:

Allikas: habr.com