🥇Mga kaso ng paggamit ng mesh ng serbisyo

Tandaan. transl.: Ang may-akda ng artikulong ito (Luc Perkins) ay isang tagapagtaguyod ng developer sa organisasyon ng CNCF, na tahanan ng mga Open Source na proyekto tulad ng Linkerd, SMI (Service Mesh Interface) at Kuma (nga pala, naisip mo rin ba kung bakit si Istio ay wala sa listahang ito? Muli, sinusubukang dalhin ang komunidad ng DevOps ng mas mahusay na pag-unawa sa usong hype na tinatawag na "service mesh", naglista siya ng 16 na katangiang kakayahan na ibinibigay ng mga naturang solusyon.

Ngayon mesh ng serbisyo ― isa sa pinakamainit na paksa sa larangan ng software engineering (at nararapat lang!). Sa tingin ko ang teknolohiyang ito ay hindi kapani-paniwalang promising at gustong makita itong malawak na pinagtibay (kapag ito ay makatuwiran, siyempre). Gayunpaman, napapalibutan pa rin ito ng isang aura ng misteryo para sa karamihan ng mga tao. At the same time, kahit yung mga kilalang kilala kasama nito, madalas na mahirap bumalangkas ng mga pakinabang nito at kung ano talaga ito (kabilang ang sa iyo talaga). Sa artikulong ito susubukan kong itama ang sitwasyon sa pamamagitan ng paglista ng iba't ibang mga kaso ng paggamit "mga meshes ng serbisyo"*.

* Tandaan transl.: dito at higit pa sa artikulo nang eksakto ang pagsasaling ito (“service mesh”) ay gagamitin para sa bagong terminong service mesh.

Ngunit gusto ko munang gumawa ng ilang mga komento:

Hindi ako kailanman nagtrabaho sa mga mesh ng serbisyo o ginamit ang mga ito sa labas ng mga proyektong sinimulan para sa sarili kong edukasyon. Sa kabilang banda, ako ang nagsulat ng isang bungkos ng dokumentasyon para sa panloob na service mesh ng Twitter noong 2015 (hindi man lang ito tinawag na "service mesh" noon) at lumahok sa pagbuo ng website at dokumentasyon para sa Linkerd, kaya may ibig sabihin iyon.
Ang aking listahan ay tinatayang at hindi kumpleto. Maaaring may mga kaso ng paggamit na hindi ko alam, at ang mga bagong opsyon ay malamang na lumitaw sa paglipas ng panahon habang ang teknolohiya ay umuunlad at ang katanyagan nito.
Kasabay nito, hindi lahat ng umiiral na pagpapatupad ng mesh ng serbisyo ay sumusuporta sa lahat ng nakalistang kaso ng paggamit. Samakatuwid, ang aking mga pahayag tulad ng "service mesh can..." ay dapat basahin bilang "indibidwal, at marahil lahat ng sikat na service mesh na pagpapatupad ay maaaring...".
Ang pagkakasunud-sunod ng mga halimbawa ay walang anumang pagkakaiba.

Maikling listahan:

pagtuklas ng serbisyo;
pag-encrypt;
pagpapatunay at awtorisasyon;
pagbabalanse ng load;
pagsira ng circuit;
autoscaling;
paglalagay ng kanaryo;
asul-berdeng pag-deploy;
pagsusuri sa kalusugan;
pagpapadanak ng load;
pag-mirror ng trapiko;
pagkakabukod;
paghiling ng paglilimita sa rate, muling pagsubok at pag-timeout;
telemetry;
audit;
visualization.

1. Pagtuklas ng serbisyo

TL;DR: Kumonekta sa ibang mga serbisyo sa network gamit ang mga simpleng pangalan.

Ang mga serbisyo ay dapat na awtomatikong "mahanap" ang isa't isa gamit ang mga sapat na pangalan - halimbawa, service.api.production, pets/staging o cassandra. Ang mga cloud environment ay elastic, at ang isang pangalan ay maaaring magtago ng maraming pagkakataon ng isang serbisyo. Malinaw na sa ganoong sitwasyon ay pisikal na imposibleng i-hardcode ang lahat ng mga IP address.

Dagdag pa, kapag nakahanap ang isang serbisyo ng isa pa, dapat itong makapagpadala ng mga kahilingan sa serbisyong iyon nang walang takot na mauwi ang mga ito sa input ng sirang instance nito. Sa madaling salita, dapat subaybayan ng service mesh ang kalusugan ng lahat ng mga pagkakataon ng serbisyo at panatilihing napapanahon ang listahan ng mga host hangga't maaari.

Ang bawat mesh ng serbisyo ay nagpapatupad ng mekanismo ng pagtuklas ng serbisyo nang iba. Sa ngayon, ang pinakakaraniwang paraan ay ang magtalaga sa mga panlabas na proseso tulad ng Kubernetes DNS. Noong nakaraan sa Twitter gumamit kami ng isang sistema ng pagbibigay ng pangalan para sa layuning ito Finalle. Bilang karagdagan, ginagawang posible ng teknolohiya ng service mesh na lumabas ang mga custom na mekanismo ng pagbibigay ng pangalan (bagama't wala pa akong nakikitang pagpapatupad ng SM na may ganoong functionality).

2. Pag-encrypt

TL;DR: Alisin ang hindi naka-encrypt na trapiko sa pagitan ng mga serbisyo at gawing awtomatiko at nasusukat ang prosesong ito.

Nakatutuwang malaman na ang mga umaatake ay hindi maaaring tumagos sa iyong panloob na network. Ang mga firewall ay gumagawa ng isang mahusay na trabaho nito. Ngunit ano ang mangyayari kung nakapasok ang isang hacker? Magagawa ba niya ang anumang gusto niya sa intra-service traffic? Sana hindi na ito mangyari pagkatapos ng lahat. Upang maiwasan ang sitwasyong ito, dapat kang magpatupad ng network na walang tiwala kung saan naka-encrypt ang lahat ng trapiko sa pagitan ng mga serbisyo. Karamihan sa mga modernong service meshes ay nakakamit ito sa pamamagitan ng mutual TLS (mutual TLS, mTLS). Sa ilang mga kaso, gumagana ang mTLS sa buong ulap at mga kumpol (sa palagay ko, ang mga komunikasyon sa pagitan ng planeta ay magiging katulad din balang araw).

Siyempre, para sa mTLS service mesh opsyonal. Maaaring pangalagaan ng bawat serbisyo ang sarili nitong TLS, ngunit nangangahulugan ito na kakailanganin mong humanap ng paraan para makabuo ng mga certificate, ipamahagi ang mga ito sa mga host ng serbisyo, at isama ang code sa application na maglo-load ng mga certificate na ito mula sa mga file. Oo, huwag kalimutang i-renew ang mga certificate na ito sa mga regular na pagitan. I-automate ng mga service meshes ang mTLS gamit ang mga system tulad ng SPIFFE, na, sa turn, ay awtomatiko ang proseso ng pag-isyu at pag-ikot ng mga sertipiko.

3. Pagpapatunay at Awtorisasyon

TL;DR: Itatag kung sino ang humihiling at tukuyin kung ano ang pinapayagan nilang gawin bago pa man makarating sa serbisyo ang kahilingan.

Madalas gustong malaman ng mga serbisyo sino gumaganap ng kahilingan (authentication), at gamit ang impormasyong ito, nagpapasya na pinahihintulutan ang isang naibigay na entity na gawin (awtorisasyon). Sa kasong ito, ang panghalip na "sino" ay maaaring itago:

Iba pang mga serbisyo. Ito ay tinatawag na "authentication" kapantay" Halimbawa, serbisyo web gustong ma-access ang serbisyo db. Karaniwang nilulutas ng mga service meshes ang mga ganitong problema gamit ang mTLS: ang mga certificate sa kasong ito ay nagsisilbing kinakailangang identifier.
Ilang tao na gumagamit. Ito ay tinatawag na "authentication" hiling" Halimbawa, gumagamit haxor69 gustong bumili ng bagong lampara. Nagbibigay ang mga service mesh ng iba't ibang mekanismo, hal. JSON Web Token.
Marami sa atin ang nakagawa nito sa application code. Pumasok ang isang kahilingan, tumingin kami sa mesa users, hanapin ang user at ihambing ang password, pagkatapos ay suriin ang column permissions atbp. Sa kaso ng isang service mesh, nangyayari ito bago pa man maabot ng kahilingan ang serbisyo.

Kapag natukoy na natin kung kanino nanggaling ang kahilingan, kailangan nating tukuyin kung ano ang pinapayagang gawin ng entity na ito. Binibigyang-daan ka ng ilang mga service meshes na magtakda ng mga pangunahing patakaran (tungkol sa kung sino ang maaaring gumawa ng ano) bilang mga YAML file o sa command line, habang ang iba ay nag-aalok ng pagsasama sa mga frameworks tulad ng Buksan ang Ahente ng Patakaran. Ang pinakalayunin ay para sa iyong mga serbisyo na tanggapin ang anumang kahilingan, ligtas na ipagpalagay na nagmumula ito sa isang pinagkakatiwalaang pinagmulan и pinahihintulutan ang pagkilos na ito.

4. Pagbalanse ng load

TL;DR: Ipamahagi ang load sa mga instance ng serbisyo ayon sa isang partikular na pattern.

Ang isang "Serbisyo" sa loob ng isang seksyon ng serbisyo ay kadalasang binubuo ng maraming magkakaparehong pagkakataon. Halimbawa, ngayon ang serbisyo cache ay binubuo ng 5 kopya, at bukas ang kanilang bilang ay maaaring tumaas sa 11. Ang mga kahilingan ay ipinadala sa cache, ay dapat ipamahagi alinsunod sa isang tiyak na layunin. Halimbawa, bawasan ang latency o i-maximize ang posibilidad na makarating sa isang gumaganang instance. Ang pinakakaraniwang ginagamit na algorithm ay Round-robin, ngunit marami pang iba - halimbawa, ang weighted na paraan (timbang) mga query (maaari kang pumili ng ginustong mga target), ring (singsing) pag-hash (gamit ang pare-parehong pag-hash sa mga upstream na host) o hindi bababa sa paraan ng kahilingan (ibinibigay ang kagustuhan sa instance na may kakaunting kahilingan).

Ang mga classic balancer ay may iba pang mga function, gaya ng HTTP caching at proteksyon ng DDoS, ngunit hindi masyadong nauugnay ang mga ito para sa silangan-kanlurang trapiko (iyon ay, para sa trapikong dumadaloy sa loob ng isang data center - humigit-kumulang transl.) (karaniwang saklaw ng service mesh). Siyempre, hindi kinakailangang gumamit ng mesh ng serbisyo para sa pagbabalanse ng pag-load, ngunit pinapayagan ka nitong itakda at kontrolin ang mga patakaran sa pagbabalanse para sa bawat serbisyo mula sa isang sentralisadong control layer, at sa gayon ay inaalis ang pangangailangang magpatakbo at mag-configure ng hiwalay na mga balanse ng pagkarga sa network stack .

5. Circuit breaking

TL;DR: Ihinto ang trapiko sa may problemang serbisyo at kontrolin ang pinsala sa mga pinakamasamang sitwasyon.

Kung sa ilang kadahilanan ay hindi makayanan ng serbisyo ang trapiko, ang service mesh ay nagbibigay ng ilang mga opsyon para sa paglutas ng problemang ito (ang iba ay tatalakayin sa naaangkop na mga seksyon). Ang circuit breaking ay ang pinakamatinding opsyon para sa pagdiskonekta ng isang serbisyo mula sa trapiko. Gayunpaman, sa sarili nitong hindi makatuwiran - kailangan ang isang backup na plano. Maaaring magbigay ng back pressure (backpressure) sa mga serbisyong gumagawa ng mga kahilingan (huwag kalimutang i-configure ang iyong service mesh para dito!), o, halimbawa, pagkulay ng pula sa pahina ng katayuan at pag-redirect ng mga user sa isa pang bersyon ng pahina na may "falling whale" ("Ang Twitter ay pababa”).

Ang mga service meshes ay hindi lamang nagbibigay-daan sa iyo na tukuyin saan susundan ng shutdown at na ito ang susunod. Sa kasong ito, ang "kailan" ay maaaring magsama ng anumang kumbinasyon ng mga tinukoy na parameter: ang kabuuang bilang ng mga kahilingan para sa isang partikular na panahon, ang bilang ng mga parallel na koneksyon, mga nakabinbing kahilingan, aktibong muling pagsubok, atbp.

Malamang na ayaw mong abusuhin ang circuit breaking, ngunit nakakatuwang malaman na mayroon kang backup na plano kung sakaling may emergency.

6. Autoscaling

TL;DR: Dagdagan o bawasan ang bilang ng mga instance ng serbisyo depende sa tinukoy na pamantayan.

Ang mga service mesh ay hindi mga scheduler, kaya hindi isagawa scaling ang iyong sarili. Gayunpaman, maaari silang magbigay ng impormasyon kung aling mga tagaplano ang ibabatay sa kanilang mga desisyon. Dahil may access ang mga service mesh sa lahat ng trapiko sa pagitan ng mga serbisyo, mayroon silang malawak na impormasyon tungkol sa kung ano ang nangyayari: kung aling mga serbisyo ang nakakaranas ng mga problema, kung aling mga serbisyo ang napakagaan ng pagkarga (ang kapasidad na inilalaan sa kanila ay nasasayang), atbp.

Halimbawa, sinusuri ng Kubernetes ang mga serbisyo batay sa paggamit ng CPU at memory ng mga pod (tingnan ang aming ulat "Autoscaling at pamamahala ng mapagkukunan sa Kubernetes"- humigit-kumulang. transl.), ngunit kung magpasya kang sukatin batay sa anumang iba pang sukatan (sa aming kaso, nauugnay sa trapiko), kakailanganin mo ng isang espesyal na sukatan. Pamamahala ganito nagpapakita kung paano ito gagawin sa Sugo, Istio и Promiteyus, ngunit ang proseso mismo ay medyo kumplikado. Gusto naming pasimplehin ito ng service mesh sa pamamagitan ng pagpayag sa amin na magtakda lang ng mga kundisyon tulad ng "dagdagan ang bilang ng mga pagkakataon ng serbisyo auth, kung ang bilang ng mga nakabinbing kahilingan ay lumampas sa threshold sa loob ng isang minuto."

7. Mga deployment ng Canary

TL;DR: Subukan ang mga bagong feature o bersyon ng serbisyo sa isang subset ng mga user.

Sabihin nating gumagawa ka ng isang produkto ng SaaS at nilayon mong ilunsad ang isang cool na bagong bersyon nito. Sinubukan mo ito sa pagtatanghal ng dula at ito ay gumana nang mahusay. Ngunit mayroon pa ring ilang mga alalahanin tungkol sa kanyang pag-uugali sa totoong mga kondisyon. Sa madaling salita, kailangan mong subukan ang bagong bersyon sa mga totoong problema nang hindi nalalagay sa panganib ang tiwala ng user. Ang mga pag-deploy ng Canary ay mahusay para dito. Nagbibigay-daan sa iyo ang mga ito na magpakita ng bagong feature sa isang subset ng mga user. Ang subset na ito ay maaaring binubuo ng mga pinakamatapat na user o mga taong nagtatrabaho sa libreng bersyon ng produkto, o mga user na nagpahayag ng pagnanais na maging "mga guinea pig".

Ipinapatupad ito ng mga service meshes sa pamamagitan ng pagbibigay-daan sa iyong tukuyin ang pamantayan na tumutukoy kung sino ang makakakita kung aling bersyon ng application, at pagruruta ng trapiko nang naaayon. Gayunpaman, walang nagbabago para sa mga serbisyo mismo. Ang bersyon 1.0 ng serbisyo ay naniniwala na ang lahat ng mga kahilingan ay nagmumula sa mga user na dapat makakita nito, at ang bersyon 1.1 ay naniniwala na pareho para sa mga gumagamit nito. Samantala, maaari mong baguhin ang porsyento ng trapiko sa pagitan ng luma at bagong mga bersyon, na nagre-redirect ng dumaraming bilang ng mga user sa bago kung ito ay gumagana nang matatag at ang iyong "mga guinea pig" ay magbibigay ng go-ahead.

8. Asul-berde na mga deployment

TL;DR: Maglunsad ng isang cool na bagong feature, ngunit maging handa na agad na bawiin ang lahat.

Ibig sabihin asul-berdeng pag-deploy ay maglunsad ng bagong "asul" na serbisyo, na ilulunsad ito kasabay ng luma, "berde" na serbisyo. Kung maayos ang lahat at gumaganap nang maayos ang bagong serbisyo, maaaring unti-unting i-disable ang luma. (Naku, balang araw, uulitin ng bagong "asul" na serbisyong ito ang kapalaran ng "berde" at mawawala...) Ang mga deployment ng asul-berde ay naiiba sa mga canary dahil saklaw ng bagong function. lahat nang sabay-sabay mga gumagamit (hindi bahagi); Ang punto dito ay ang pagkakaroon ng “safe harbor” na handa kung sakaling may magkamali.

Nag-aalok ang mga mesh ng serbisyo ng isang napaka-maginhawang paraan upang subukan ang isang "asul" na serbisyo at agad na lumipat sa isang gumaganang "berde" kung sakaling magkaroon ng mga problema. Hindi sa banggitin ang katotohanan na sa kahabaan ng paraan ay nagbibigay sila ng maraming impormasyon (tingnan ang "Telemetry" sa ibaba) tungkol sa gawain ng "asul", na tumutulong upang maunawaan kung ito ay handa na para sa buong operasyon.

Tandaan. transl.: Maaari kang magbasa nang higit pa tungkol sa iba't ibang mga diskarte sa pag-deploy sa Kubernetes (kabilang ang nabanggit na canary, asul/berde at iba pa) sa artikulong ito.

9. Pagsusuri sa kalusugan

TL;DR: Subaybayan kung aling mga instance ng serbisyo ang gumagana at tumugon sa mga hindi na gumagana.

Pagsusuri sa kalusugan (check ng kalusugan) tumutulong na magpasya kung ang mga instance ng serbisyo ay handa nang tanggapin at iproseso ang trapiko. Halimbawa, sa kaso ng mga serbisyo ng HTTP, ang isang pagsusuri sa kalusugan ay maaaring magmukhang isang kahilingan sa GET sa endpoint /health. Sagot 200 OK ay nangangahulugan na ang instance ay malusog, anumang iba pa - na hindi ito handang tumanggap ng trapiko. Nagbibigay-daan sa iyo ang mga service meshes na tukuyin ang parehong paraan kung saan susuriin ang functionality at ang dalas kung saan isasagawa ang pagsusuring ito. Ang impormasyong ito ay maaaring gamitin para sa iba pang mga layunin - halimbawa, para sa pagbabalanse ng load at pagsira ng circuit.

Kaya, ang pagsusuri sa kalusugan ay hindi isang stand-alone na kaso ng paggamit, ngunit kadalasang ginagamit upang makamit ang iba pang mga layunin. Gayundin, depende sa mga resulta ng mga pagsusuri sa kalusugan, maaaring kailanganin ang mga pagkilos na panlabas sa iba pang mga target ng mesh ng serbisyo: halimbawa, pag-update sa page ng status, paggawa ng isyu sa GitHub, o pagpuno ng JIRA ticket. At nag-aalok ang mesh ng serbisyo ng isang maginhawang mekanismo upang i-automate ang lahat ng ito.

10. Pag-load ng pagpapadanak

TL;DR: I-redirect ang trapiko bilang tugon sa isang pansamantalang pagtaas sa paggamit.

Kung ang isang partikular na serbisyo ay na-overload ng trapiko, maaari mong pansamantalang i-redirect ang ilan sa trapikong ito sa ibang lokasyon (iyon ay, "dump", "transfer" (malaglag) siya doon). Halimbawa, sa isang backup na serbisyo o data center, o sa isang permanenteng Pindutin paksa. Bilang resulta, patuloy na ipoproseso ng serbisyo ang ilang kahilingan sa halip na mag-crash at ihinto ang pagpoproseso ng lahat. Ang load shedding ay mas mainam kaysa sa pagsira sa circuit, ngunit hindi pa rin ipinapayong abusuhin ito. Nakakatulong ito na maiwasan ang mga cascading failure na nagiging sanhi ng pag-crash ng mga downstream na serbisyo.

11. Parallelization/mirroring ng trapiko

TL;DR: Magpadala ng isang kahilingan sa ilang lugar nang sabay-sabay.

Minsan may pangangailangang magpadala ng kahilingan (o isang tiyak na seleksyon ng mga kahilingan) sa ilang serbisyo nang sabay-sabay. Ang isang karaniwang halimbawa ay ang pagpapadala ng bahagi ng trapiko ng produksyon sa isang serbisyo sa pagtatanghal. Ang pangunahing production web server ay nagpapadala ng kahilingan sa downstream na serbisyo products.production at sa kanya lamang. At matalinong kinokopya ng service mesh ang kahilingang ito at ipinapadala ito sa products.staging, na hindi alam ng web server.

Ang isa pang nauugnay na kaso ng paggamit ng mesh ng serbisyo na maaaring ipatupad sa ibabaw ng parallelization ng trapiko ay pagsubok ng regression. Kabilang dito ang pagpapadala ng parehong mga kahilingan sa iba't ibang bersyon ng serbisyo at pagsuri kung pareho ang pagkilos ng lahat ng bersyon. Hindi pa ako nakakatagpo ng isang pagpapatupad ng mesh ng serbisyo na may pinagsamang sistema ng pagsubok ng regression tulad ng Diffy, ngunit ang ideya mismo ay tila promising.

12. Pagkakabukod

TL;DR: Hatiin ang iyong service mesh sa mga mini-network.

Kilala din sa segmentasyonAng paghihiwalay ay ang sining ng paghahati ng isang service mesh sa lohikal na natatanging mga segment na walang alam tungkol sa isa't isa. Ang paghihiwalay ay medyo katulad ng paglikha ng mga virtual na pribadong network. Ang pangunahing pagkakaiba ay maaari mo pa ring matamasa ang lahat ng mga benepisyo ng isang service mesh (tulad ng pagtuklas ng serbisyo), ngunit may karagdagang seguridad. Halimbawa, kung ang isang umaatake ay nakapasok sa isang serbisyo sa isang subnet, hindi niya makikita kung anong mga serbisyo ang tumatakbo sa ibang mga subnet o maharang ang kanilang trapiko.

Bilang karagdagan, ang mga benepisyo ay maaari ding pang-organisasyon. Maaaring gusto mong i-subnet ang iyong mga serbisyo batay sa istraktura ng iyong kumpanya at mapawi ang mga developer ng cognitive load na kailangang panatilihin sa isip ang buong service mesh.

13. Paglilimita sa rate ng kahilingan, muling pagsubok at timeout

TL;DR: Hindi mo na kailangang isama ang mga nitty-gritty request management tasks sa iyong codebase.

Ang lahat ng mga bagay na ito ay maaaring ituring na magkahiwalay na mga kaso ng paggamit, ngunit nagpasya akong pagsamahin ang mga ito dahil sa isang karaniwang feature: sila ang pumalit sa kahilingan sa mga gawain sa pamamahala ng lifecycle na karaniwang pinangangasiwaan ng mga library ng application. Kung bubuo ka ng isang web server sa Ruby on Rails (hindi isinama sa isang service mesh) na gumagawa ng mga kahilingan upang mag-backend ng mga serbisyo sa pamamagitan ng gRPC, kailangang magpasya ang application kung ano ang gagawin kung nabigo ang N kahilingan. Kakailanganin mo ring malaman kung gaano karaming trapiko ang magagawa ng mga serbisyong ito na iproseso at i-hardcode ang mga parameter na ito gamit ang isang espesyal na library. Dagdag pa, ang application ay kailangang magpasya kung oras na para sumuko at hayaang masira ang kahilingan (batay sa timeout). At upang mabago ang alinman sa mga parameter sa itaas, ang web server ay kailangang ihinto, muling i-configure at magsimulang muli.

Ang pag-offload ng mga gawaing ito sa isang service mesh ay hindi lamang nangangahulugan na hindi na kailangang isipin ng mga developer ng serbisyo ang tungkol sa mga ito, ngunit maaari ding tingnan ang mga ito sa isang mas pandaigdigang paraan. Kung ang isang kumplikadong hanay ng mga serbisyo ay ginamit, sabihin ang A -> B -> C -> D -> E, ang buong lifecycle ng kahilingan ay dapat isaalang-alang. Kung ang gawain ay palawigin ang mga timeout sa serbisyo C, makatuwirang gawin ito nang sabay-sabay, at hindi sa mga bahagi: sa pamamagitan ng pag-update ng code ng serbisyo at paghihintay hanggang matanggap ang kahilingan sa pag-pull at i-deploy ng CI system ang na-update na serbisyo.

14. Telemetry

TL;DR: Kolektahin ang lahat ng kinakailangang (at hindi masyadong) impormasyon mula sa mga serbisyo.

Ang Telemetry ay isang pangkalahatang termino na kinabibilangan ng mga sukatan, distributed tracing, at mga log. Nag-aalok ang mga service meshes ng mga mekanismo para sa pagkolekta at pagproseso ng lahat ng tatlong uri ng data. Dito nagiging medyo malabo ang mga bagay dahil masyadong malaki ang bilang ng mga posibleng opsyon. Upang mangolekta ng mga sukatan ay mayroon Promiteyus at iba pang mga tool na maaaring magamit upang mangolekta ng mga log matatas, Loki, Vector at iba pa (halimbawa ClickHouse kasama ang aming bahay na kahoy para sa K8s - tinatayang. transl.), para sa distributed tracing meron Snayper at iba pa. Maaaring suportahan ng bawat service mesh ang ilang tool at hindi ang iba. Magiging kawili-wiling makita kung magagawa ng proyekto Buksan ang Telemetry magbigay ng ilang convergence.

Sa kasong ito, ang bentahe ng teknolohiya ng mesh ng serbisyo ay ang mga sidecar container, sa prinsipyo, ay maaaring mangolekta ng lahat ng data sa itaas mula sa kanilang mga serbisyo. Sa madaling salita, mayroon kang isang sistema ng koleksyon ng telemetry na magagamit mo, at maaaring iproseso ng service mesh ang lahat ng impormasyong ito sa iba't ibang paraan. Halimbawa:

tail logs mula sa isang partikular na serbisyo sa CLI;
subaybayan ang dami ng mga kahilingan mula sa dashboard ng mesh ng serbisyo;
mangolekta ng mga ipinamahagi na bakas at ipasa ang mga ito sa isang sistema tulad ng Jaeger.

Pansin, pansariling paghatol: Sa pangkalahatan, ang telemetry ay isang lugar kung saan ang malakas na interference mula sa service mesh ay hindi kanais-nais. Ang pagkolekta ng pangunahing impormasyon at pagsubaybay on-the-fly ng ilang ginintuang sukatan tulad ng rate ng tagumpay ng kahilingan at latency ay ayos lang, ngunit sana ay hindi natin makitang lumilitaw ang mga stack ng Frankenstein na sumusubok na palitan ang mga dalubhasang system, ang ilan sa mga ito ay napatunayan na at pinag-aralan nang mabuti. .

15. Pag-audit

TL;DR: Ang mga nakakalimot sa mga aral ng kasaysayan ay tiyak na mauulit.

Ang pag-audit ay ang sining ng pagmamasid sa mahahalagang kaganapan sa isang sistema. Sa kaso ng isang service mesh, maaaring mangahulugan ito ng pagsubaybay kung sino ang gumawa ng mga kahilingan sa mga partikular na endpoint para sa mga partikular na serbisyo, o kung gaano karaming beses naganap ang ilang kaganapang nauugnay sa seguridad noong nakaraang buwan.

Malinaw na ang pag-audit ay napakalapit na nauugnay sa telemetry. Ang pagkakaiba ay ang telemetry ay karaniwang nauugnay sa mga bagay tulad ng pagiging produktibo at teknikal na integridad, habang ang pag-audit ay maaaring nauugnay sa legal at iba pang mga isyu na higit pa sa mahigpit na teknikal na larangan (halimbawa, pagsunod sa GDPR - ang Pangkalahatang Regulasyon ng EU sa proteksyon ng data).

16. Pagpapakita

TL;DR: Mabuhay ang React.js - isang hindi mauubos na mapagkukunan ng mga magagarang interface.

Maaaring may mas magandang termino, ngunit hindi ko alam ito. Ang ibig kong sabihin ay isang graphical na representasyon ng isang service mesh o ilan sa mga bahagi nito. Maaaring kabilang sa mga visualization na ito ang mga indicator tulad ng mga average na latency, impormasyon sa configuration ng sidecar, mga resulta ng pagsusuri sa kalusugan, at mga alerto.

Ang pagtatrabaho sa isang environment na nakatuon sa serbisyo ay nagsasangkot ng mas mataas na cognitive load kumpara sa His Majesty the Monolith. Samakatuwid, ang cognitive pressure ay dapat bawasan sa lahat ng mga gastos. Ang isang simpleng graphical na interface para sa isang service mesh na may kakayahang mag-click sa isang pindutan at makuha ang nais na resulta ay maaaring maging mapagpasyahan para sa paglago ng katanyagan ng teknolohiyang ito.

Hindi kasama sa listahan

Orihinal kong nilayon na isama ang ilang higit pang mga kaso ng paggamit sa listahan, ngunit pagkatapos ay nagpasya na huwag. Narito sila, kasama ang mga dahilan ng aking desisyon:

Multi-data center. Sa aking opinyon, ito ay hindi masyadong isang kaso ng paggamit bilang isang makitid at partikular na lugar ng paglalapat ng mga mesh ng serbisyo o ilang hanay ng mga function tulad ng pagtuklas ng serbisyo.
Pagpasok at paglabas. Ito ay isang kaugnay na lugar, ngunit nilimitahan ko ang aking sarili (marahil artipisyal) sa kaso ng paggamit ng "silangan-kanlurang trapiko." Ang pagpasok at paglabas ay nararapat sa isang hiwalay na artikulo.

Konklusyon

Yun lang muna! Muli, ang listahang ito ay napaka-arbitrary at malamang na hindi kumpleto. Kung sa tingin mo ay may napalampas ako o nagkamali, mangyaring makipag-ugnayan sa akin sa Twitter (@luckerkins). Mangyaring igalang ang mga tuntunin ng kagandahang-asal.

PS mula sa tagasalin

Ang paglalarawan ng pamagat para sa artikulo ay batay sa isang larawan mula sa artikulong "Ano ang isang Service Mesh (at kailan gagamit ng isa)?"(ni Gregory MacKinnon). Ipinapakita nito kung paano lumipat ang ilang functionality mula sa mga application (sa berde) sa isang service mesh na nagbibigay ng mga interconnection sa pagitan ng mga ito (sa asul).

Basahin din sa aming blog:

Pinagmulan: www.habr.com