Tandaan. transl.: Ang mesh ng serbisyo ay isang kababalaghan na wala pang matatag na pagsasalin sa Russian (mahigit 2 taon na ang nakalilipas iminungkahi namin ang opsyon na "mesh para sa mga serbisyo", at ilang sandali ang ilang mga kasamahan ay nagsimulang aktibong isulong ang kumbinasyong "service sieve"). Ang patuloy na pag-uusap tungkol sa teknolohiyang ito ay humantong sa isang sitwasyon kung saan ang mga bahagi ng marketing at teknikal ay masyadong malapit na magkakaugnay. Ang kahanga-hangang materyal na ito mula sa isa sa mga may-akda ng orihinal na termino ay inilaan upang magbigay ng kalinawan para sa mga inhinyero at iba pa.
Komiks mula sa
Pagpapakilala
Kung ikaw ay isang software engineer na nagtatrabaho sa isang lugar sa backend system space, ang terminong "service mesh" ay malamang na naging matatag na sa iyong isipan sa nakalipas na ilang taon. Dahil sa isang kakaibang pagkakataon, ang pariralang ito ay higit na humahawak sa industriya, at ang hype at mga alok na pang-promosyon na nauugnay dito ay lumalaki tulad ng isang snowball na lumilipad pababa at hindi nagpapakita ng mga palatandaan ng pagbagal.
Ang service mesh ay isinilang sa malabo, biased na tubig ng cloud native ecosystem. Sa kasamaang-palad, nangangahulugan ito na ang karamihan sa mga kontrobersyang nakapalibot dito ay mula sa "mababang-calorie na usapan" hanggang sa—upang gumamit ng teknikal na termino—tuwirang kalokohan. Ngunit kung pinutol mo ang lahat ng ingay, makikita mo na ang mesh ng serbisyo ay may isang tunay, tinukoy at mahalagang function.
Sa post na ito, susubukan kong gawin iyon: magbigay ng isang tapat, malalim, gabay na nakatuon sa engineer sa service mesh. Hindi ko lang sasagutin ang tanong: "Ano ito?", - ngunit din "Bakit?"At "Bakit ngayon?". Sa wakas, susubukan kong balangkasin kung bakit (sa aking opinyon) ang partikular na teknolohiyang ito ay nagdulot ng isang nakakabaliw na kaguluhan, na isang kawili-wiling kuwento mismo.
Kto я?
Kamusta kayong lahat! Ang pangalan ko ay . Isa ako sa mga lumikha — ang pinakaunang service mesh project at ang proyektong dapat sisihin sa paglitaw ng termino mesh ng serbisyo ganyan (sorry guys!). (Tandaan transl.: Sa pamamagitan ng paraan, sa bukang-liwayway ng paglitaw ng terminong ito, higit sa 2,5 taon na ang nakalilipas, naisalin na namin ang unang bahagi ng materyal ng parehong may-akda na pinamagatang "".) ulo ko din ay isang startup na gumagawa ng mga cool na service mesh na bagay tulad ng Linkerd at .
Maaari mong hulaan na mayroon akong isang napaka-kinikiling at subjective na opinyon sa isyung ito. Gayunpaman, susubukan kong panatilihing mababa ang bias (maliban sa isang seksyon: "Bakit napakaraming usapan tungkol sa service mesh?", - kung saan ibabahagi ko pa rin ang aking mga naisip na ideya). Gagawin ko rin ang aking makakaya upang gawing layunin ang gabay na ito hangga't maaari. Para sa mga partikular na halimbawa, pangunahing aasa ako sa karanasan ni Linkerd, habang itinuturo ang mga pagkakaiba (kung mayroon man) na alam ko sa pagpapatupad ng iba pang mga uri ng mesh ng serbisyo.
Okay, oras na para magpatuloy sa mga goodies.
Ano ang service mesh?
Sa kabila ng lahat ng hype, ang istraktura ng mesh ng serbisyo ay medyo simple. Isa lang itong grupo ng mga userspace proxy na matatagpuan "sa tabi" ng mga serbisyo (mag-uusap tayo nang kaunti tungkol sa kung ano ang "susunod" sa ibang pagkakataon), kasama ang isang hanay ng mga proseso ng kontrol. Ang mga proxy ay sama-samang tinatawag data plan, at ang mga proseso ng kontrol ay tinatawag control eroplano. Hinaharang ng data plane ang mga tawag sa pagitan ng mga serbisyo at ginagawa ang "lahat ng uri ng iba't ibang bagay" sa kanila; Ang control plane, nang naaayon, ay nag-coordinate sa gawi ng proxy at nagbibigay ng access para sa iyo, i.e. operator, sa API, na nagpapahintulot sa network na manipulahin at masukat sa kabuuan.
Anong klaseng proxy ito? Ito ay isang Layer 7-aware na TCP proxy (ibig sabihin, "isinasaalang-alang" ang layer 7 ng modelo ng OSI) tulad ng HAProxy at NGINX. Maaari kang pumili ng proxy ayon sa gusto mo; Gumagamit ang Linkerd ng Rust proxy, pinangalanan lang . Pinagsama namin ito partikular para sa service mesh. Mas gusto ng ibang mga meshes ang iba pang mga proxy (Ang Envoy ay isang karaniwang pagpipilian). Gayunpaman, ang pagpili ng isang proxy ay isang bagay lamang ng pagpapatupad.
Ano ang ginagawa ng mga proxy server na ito? Malinaw, nag-proxy sila ng mga tawag papunta at mula sa mga serbisyo (mahigpit na nagsasalita, kumikilos sila bilang mga proxy at reverse proxy, na humahawak sa parehong mga papasok at papalabas na tawag). At nagpapatupad sila ng feature set na nakatutok sa mga tawag sa pagitan ng serbisyo. Ang pagtutok na ito sa trapiko sa pagitan ng mga serbisyo ay ang nagpapakilala sa isang service mesh proxy mula sa, halimbawa, mga API gateway o ingress proxies (ang huli ay nakatuon sa mga tawag na dumarating sa cluster mula sa labas ng mundo). (Tandaan. transl.: Para sa paghahambing ng mga umiiral nang Ingress controller para sa Kubernetes, marami sa mga ito ay gumagamit ng nabanggit na Envoy, tingnan .)
Kaya, inayos namin ang data plane. Ang control plane ay mas simple: ito ay isang set ng mga bahagi na nagbibigay ng lahat ng mekanika na kailangan ng data plane para gumana sa isang coordinated na paraan, kabilang ang pagtuklas ng serbisyo, pagbibigay ng mga TLS certificate, metric aggregation, atbp. Ang data plane ay nagpapaalam sa control plane ng pag-uugali nito; sa turn, ang control plane ay nagbibigay ng API na nagbibigay-daan sa iyong baguhin at subaybayan ang gawi ng data plane sa kabuuan.
Nasa ibaba ang isang diagram ng control plane at data plane sa Linkerd. Gaya ng nakikita mo, ang control plane ay may kasamang ilang iba't ibang bahagi, kabilang ang isang Prometheus instance na nangongolekta ng mga sukatan mula sa mga proxy server, pati na rin ang iba pang mga bahagi tulad ng destination (pagtuklas ng serbisyo), identity (awtoridad ng sertipiko, CA) at public-api (mga endpoint para sa web at CLI). Sa kaibahan, ang data plane ay isang simpleng linkerd-proxy sa tabi ng application instance. Ito ay isang logic diagram lamang; Sa isang real-world na deployment, maaaring mayroon kang tatlong replika ng bawat bahagi ng control plane at daan-daan o libu-libong proxy sa data plane.
(Ang mga asul na parihaba sa diagram na ito ay sumasagisag sa mga hangganan ng mga Kubernetes pod. Makikita mo na ang mga container na may linkerd-proxy ay nasa parehong pod ng mga application container. Ang scheme na ito ay kilala bilang lalagyan ng sidecar.)
Ang arkitektura ng mesh ng serbisyo ay may ilang mahahalagang implikasyon. Una, dahil ang gawain ng isang proxy ay humarang ng mga tawag sa pagitan ng mga serbisyo, ang isang service mesh ay may katuturan lamang kung ang iyong aplikasyon ay ginawa para sa isang partikular na hanay ng mga serbisyo. Mesh maaari gamitin sa mga monolith, ngunit ito ay malinaw na kalabisan para sa kapakanan ng isang solong proxy, at ang pag-andar nito ay malamang na hindi hinihiling.
Ang isa pang mahalagang kahihinatnan ay ang kinakailangan ng mesh ng serbisyo napakalaki bilang ng mga proxy. Sa katunayan, ang Linkerd ay nag-attach ng linkerd-proxy sa bawat pagkakataon ng bawat serbisyo (ang iba pang mga pagpapatupad ay nagdaragdag ng proxy sa bawat node/host/virtual machine. Marami pa rin iyon). Ang ganitong aktibong paggamit ng mga proxy sa sarili nito ay nagdadala ng ilang karagdagang mga komplikasyon:
- Ang mga proxy sa data plane ay dapat na mabilis, dahil para sa bawat tawag mayroong dalawang tawag sa proxy: isa sa panig ng kliyente, isa sa panig ng server.
- Gayundin ang mga proxy ay dapat na maliit и magaan ang timbang. Ang bawat isa ay kumonsumo ng memorya at mga mapagkukunan ng CPU, at ang pagkonsumo na ito ay lalago nang linear sa application.
- Kakailanganin mo ang isang mekanismo upang i-deploy at i-update ang isang malaking bilang ng mga proxy. Ang paggawa nito nang manu-mano ay hindi isang opsyon.
Sa pangkalahatan, ganito ang hitsura ng isang service mesh (kahit man lang mula sa isang bird's eye view): nag-deploy ka ng isang grupo ng mga userspace proxy na "gumawa ng isang bagay" sa panloob, inter-service na trapiko, at gumagamit ng control plane upang subaybayan at pamahalaan ang mga ito.
Ngayon ay oras na para itanong ang tanong na "Bakit?"
Para saan ang service mesh?
Ang mga unang nakatagpo ng ideya ng isang service mesh ay maaaring patawarin para sa pakiramdam ng kaunting takot. Ang disenyo ng mesh ng serbisyo ay nangangahulugan na ito ay hindi lamang magpapataas ng latency sa application, ngunit ito rin ubusin mapagkukunan at magdadagdag isang grupo ng mga bagong mekanismo sa imprastraktura. Una ay nag-set up ka ng isang service mesh, at pagkatapos ay bigla mong makikita ang iyong sarili na nangangailangan ng serbisyo ng daan-daang (kung hindi libu-libo) ng mga proxy. Ang tanong, sino ang kusang gagawa nito?
Ang sagot sa tanong na ito ay may dalawang bahagi. Una, ang mga gastos sa transaksyon na nauugnay sa pag-deploy ng mga proxy na ito ay maaaring makabuluhang bawasan dahil sa ilang pagbabagong nangyayari sa ecosystem (higit pa tungkol dito sa ibang pagkakataon).
Pangalawa, ang isang aparato na tulad nito ay talagang isang mahusay na paraan upang ipakilala ang karagdagang lohika sa system. Hindi lamang dahil ang isang service mesh ay maaaring magdagdag ng maraming bagong pag-andar, ngunit dahil din ito ay magagawa nang hindi nakakasagabal sa ecosystem. Sa katunayan, ang buong modelo ng mesh ng serbisyo ay batay sa premise na ito: sa isang multiservice system, kahit na ano gumawa mga indibidwal na serbisyo, trapiko sa pagitan nila ay ang perpektong punto upang magdagdag ng pag-andar.
Halimbawa, sa Linkerd (tulad ng karamihan sa mga mesh) ang functionality ay pangunahing nakatuon sa mga HTTP na tawag, kabilang ang HTTP/2 at gRPC*. Ang pag-andar ay medyo mayaman - maaari itong nahahati sa tatlong klase:
- Mga tampok na nauugnay sa pagiging maaasahan. Mga paulit-ulit na kahilingan, timeout, canary approach (traffic splitting/redirection), atbp.
- Mga tampok na nauugnay sa pagsubaybay. Pagsasama-sama ng mga rate ng tagumpay, pagkaantala at dami ng kahilingan para sa bawat serbisyo o indibidwal na direksyon; pagtatayo ng mga topological na mapa ng mga serbisyo, atbp.
- Mga tampok na nauugnay sa seguridad. Mutual TLS, access control, atbp.
* Mula sa pananaw ng Linkerd, ang gRPC ay halos hindi naiiba sa HTTP/2: gumagamit lang ito ng protobuf sa payload. Mula sa pananaw ng isang developer, siyempre, magkaiba ang dalawang bagay.
Marami sa mga mekanismong ito ay gumagana sa antas ng kahilingan (kaya ang "L7 proxy"). Halimbawa, kung ang serbisyo ng Foo ay gagawa ng HTTP na tawag sa serbisyo ng Bar, ang linkerd-proxy sa gilid ng Foo ay maaaring magsagawa ng matalinong pagbalanse ng pag-load at ruta ng mga tawag mula sa Foo hanggang Bar na mga instance batay sa naobserbahang latency; maaari nitong ulitin ang kahilingan kung kinakailangan (at kung ito ay idempotent); maaari nitong i-record ang response code at timeout, atbp. Katulad nito, maaaring tanggihan ng linkerd-proxy sa gilid ng Bar ang isang kahilingan kung hindi ito pinapayagan o lumampas ang limitasyon sa kahilingan; maaaring magtala ng pagkaantala sa bahagi nito, atbp.
Ang mga proxy ay maaaring "gumawa ng isang bagay" sa antas ng koneksyon din. Halimbawa, ang linkerd-proxy sa gilid ng Foo ay maaaring magpasimula ng isang koneksyon sa TLS, at ang linkerd-proxy sa gilid ng Bar ay maaaring wakasan ito, at ang magkabilang panig ay maaaring mag-verify ng mga TLS certificate ng isa't isa*. Nagbibigay ito hindi lamang ng pag-encrypt sa pagitan ng mga serbisyo, kundi pati na rin ng isang cryptographically secure na paraan upang matukoy ang mga serbisyo: Maaaring "patunayan" ng Foo at Bar na sila ang sinasabi nilang sila.
* Ang ibig sabihin ng "Mutual of a friend" ay na-verify din ang certificate ng kliyente (mutual TLS). Sa "classic" na TLS, halimbawa sa pagitan ng isang browser at isang server, ang sertipiko ng isang bahagi lamang (ang server) ay karaniwang nabe-verify.
Hindi alintana kung gumagana ang mga ito sa antas ng kahilingan o koneksyon, mahalagang bigyang-diin na ang lahat ng mga function ng service mesh ay pagpapatakbo karakter. Hindi nababago ng Linkerd ang semantics ng payload - halimbawa, pagdaragdag ng mga field sa isang fragment ng JSON o paggawa ng mga pagbabago sa protobuf. Pag-uusapan natin ang mahalagang feature na ito mamaya kapag pinag-uusapan natin ang tungkol sa ESB at middleware.
Ito ang hanay ng mga feature na inaalok ng isang service mesh. Ang tanong ay lumitaw: bakit hindi ipatupad ang mga ito nang direkta sa application? At bakit mag-abala sa isang proxy sa lahat?
Bakit magandang ideya ang service mesh
Bagama't kapana-panabik ang mga kakayahan ng isang service mesh, ang pangunahing halaga nito ay hindi talaga nasa mga tampok nito. Sa huli tayo Maaari ipatupad ang mga ito nang direkta sa application (makikita natin mamaya na ito ang pinagmulan ng mesh ng serbisyo). Upang subukan at buuin ito sa isang pangungusap, ang halaga ng isang service mesh ay: nagbibigay ito ng mga tampok na kritikal sa pagpapatakbo ng modernong server software sa isang pare-parehong paraan sa buong stack at independiyente sa application code.
Suriin natin ang panukalang ito.
«Mga tampok na kritikal sa pagpapatakbo ng modernong server software" Kung gumagawa ka ng transactional server application na nakakonekta sa pampublikong Internet, tumatanggap ng mga kahilingan mula sa labas ng mundo at tumutugon sa mga ito sa loob ng maikling panahon - halimbawa, isang web application, isang API server, at ang karamihan sa iba pang modernong application - at kung ipapatupad mo ito bilang isang hanay ng mga serbisyo na sabay-sabay na nakikipag-ugnayan sa isa't isa, at kung patuloy mong ina-upgrade ang software na ito, nagdaragdag ng mga bagong feature, at kung napipilitan kang panatilihin ang system na ito sa maayos na gumagana sa panahon ng proseso ng pagbabago - dito kaso, binabati kita, lumilikha ka ng modernong server software . At lahat ng magagandang feature na nakalista sa itaas ay talagang nagiging kritikal para sa iyo. Ang application ay dapat na maaasahan, secure, at dapat mong obserbahan kung ano ang ginagawa nito. Ito mismo ang mga tanong na tinutulungan ng service mesh na malutas.
(OK, kasama pa rin sa nakaraang talata ang aking paniniwala na ang diskarteng ito ay ang modernong paraan upang lumikha ng software ng server. Mas gusto ng iba na bumuo ng mga monolith, "reactive microservices" at iba pang mga bagay na hindi nasa ilalim ng kahulugang ibinigay sa itaas. Ang mga taong ito ay malamang na may kanilang iba ang opinyon sa akin. Sa kabilang banda, sa tingin ko sila ay "mali" - kahit na sa anumang kaso ang service mesh ay hindi masyadong kapaki-pakinabang para sa kanila).
«Uniform para sa buong stack" Ang functionality na ibinigay ng isang service mesh ay hindi lamang kritikal sa misyon. Nalalapat ang mga ito sa lahat ng serbisyo sa application, anuman ang wika kung saan nakasulat ang mga ito, anong framework ang ginagamit nila, sino ang sumulat sa kanila, kung paano sila na-deploy, at anumang iba pang subtleties ng kanilang pag-unlad at paggamit.
«Independiyente sa code ng aplikasyon" Sa wakas, ang isang service mesh ay hindi lamang nagbibigay ng pare-parehong pagpapagana sa buong stack, ginagawa nito ito sa paraang hindi nangangailangan ng pag-edit ng application. Ang pangunahing batayan ng paggana ng mesh ng serbisyo, kabilang ang mga gawain para sa pagsasaayos, pag-update, pagpapatakbo, pagpapanatili, atbp., ay ganap na namamalagi sa antas ng platform at independyente sa application. Maaaring magbago ang application nang hindi naaapektuhan ang mesh ng serbisyo. Sa turn, ang service mesh ay maaaring magbago nang walang anumang partisipasyon mula sa application.
Sa madaling salita, ang isang service mesh ay hindi lamang nagbibigay ng mahahalagang functionality, ngunit ginagawa rin ito sa isang pandaigdigan, uniporme, at application-independent na paraan. At kaya, bagama't ang functionality ng service mesh ay maaaring ipatupad sa service code (halimbawa, bilang isang library na kasama sa bawat serbisyo), ang diskarteng ito ay hindi magbibigay ng pagkakapareho at kalayaan na napakahalaga sa kaso ng isang service mesh.
At ang kailangan mo lang gawin ay magdagdag ng isang grupo ng mga proxy! Nangangako ako na titingnan natin ang mga gastos sa pagpapatakbo na nauugnay sa pagdaragdag ng mga proxy na ito sa lalong madaling panahon. Ngunit huminto muna tayo at tingnan ang ideyang ito ng kalayaan mula sa iba't ibang mga pananaw. mga tao.
Sino ang tumutulong sa service mesh?
Kahit na hindi maginhawa, para ang isang teknolohiya ay maging isang mahalagang bahagi ng ecosystem, dapat itong tanggapin ng mga tao. Kaya sino ang interesado sa service mesh? Sino ang nakikinabang sa paggamit nito?
Kung gumagawa ka ng modernong software ng server, halos maiisip mo ang iyong koponan bilang isang grupo mga may-ari ng serbisyona magkasamang bumuo at nagpapatupad ng lohika ng negosyo, at mga may-ari ng platform, pagbuo ng panloob na platform kung saan gumagana ang mga serbisyong ito. Sa maliliit na organisasyon, maaaring pareho silang mga tao, ngunit habang lumalaki ang kumpanya, ang mga tungkuling ito ay may posibilidad na maging mas malinaw at nahahati pa sa mga sub-role... (Maraming masasabi dito tungkol sa pagbabago ng kalikasan ng mga devops, ang epekto ng organisasyon ng mga microservice, atbp.) n. Ngunit sa ngayon, kunin natin ang mga paglalarawang ito bilang ibinigay).
Mula sa puntong ito, ang malinaw na makikinabang ng mesh ng serbisyo ay ang mga may-ari ng platform. Pagkatapos ng lahat, sa huli, ang layunin ng pangkat ng platform ay lumikha ng panloob na platform kung saan maaaring ipatupad ng mga may-ari ng serbisyo ang lohika ng negosyo at gawin ito sa paraang tinitiyak na sila ay independyente hangga't maaari mula sa madilim na mga detalye ng operasyon nito. Hindi lamang nag-aalok ang isang service mesh ng mga kakayahan na mahalaga sa pagkamit ng layuning ito, ginagawa nito ito sa paraang hindi naman nagpapataw ng mga dependency sa mga may-ari ng serbisyo.
Nakikinabang din ang mga may-ari ng serbisyo, bagama't sa mas hindi direktang paraan. Ang layunin ng may-ari ng serbisyo ay maging produktibo hangga't maaari sa pagpapatupad ng lohika ng proseso ng negosyo, at kung gaano siya dapat mag-alala tungkol sa mga isyu sa pagpapatakbo, mas mabuti. Sa halip na harapin ang pagpapatupad, halimbawa, subukang muli ang mga patakaran o TLS, maaari silang tumuon lamang sa mga layunin ng negosyo at umaasa na ang platform ang bahala sa iba. Malaking bentahe ito para sa kanila.
Ang halaga ng organisasyon ng naturang dibisyon sa pagitan ng mga may-ari ng mga platform at serbisyo ay hindi maaaring labis na tantiyahin. Sa tingin ko siya ay nag-aambag ang pangunahing kontribusyon sa halaga ng mesh ng serbisyo.
Natutunan namin ang aral na ito nang sabihin sa amin ng isang naunang tagahanga ng Linkerd kung bakit pinili nila ang service mesh: dahil pinahintulutan silang "panatilihin ang pinakamaliit na pakikipag-usap." Narito ang ilang detalye: inilipat ng mga lalaki mula sa isang malaking kumpanya ang kanilang platform sa Kubernetes. Dahil pinangangasiwaan ng application ang sensitibong impormasyon, gusto nilang i-encrypt ang lahat ng komunikasyon sa mga cluster. Gayunpaman, ang sitwasyon ay kumplikado sa pagkakaroon ng daan-daang mga serbisyo at daan-daang mga development team. Ang pag-asang makipag-ugnayan sa lahat at kumbinsihin silang isama ang suporta ng TLS sa kanilang mga plano ay hindi nakapagpasaya sa kanila. Pagkatapos i-install ang Linkerd, lumipat sila pananagutan mula sa mga developer (mula sa punto ng view kung saan ito ay hindi kinakailangang problema) hanggang sa mga platformer, kung kanino ito ay isang top-level na priyoridad. Sa madaling salita, nalutas ng Linkerd para sa kanila ang hindi gaanong teknikal na problema bilang isang pang-organisasyon.
Sa madaling salita, ang isang service mesh ay higit pa sa isang solusyon, hindi isang teknikal, ngunit sosyo-teknikal Mga problema. (Salamat para sa pagpapakilala ng terminong ito.)
Malulutas ba ng service mesh ang lahat ng problema ko?
Oo. Ang ibig kong sabihin ay hindi!
Kung titingnan mo ang tatlong klase ng mga feature na nakabalangkas sa itaas—pagkakatiwalaan, seguridad, at obserbasyon—ay nagiging malinaw na ang isang service mesh ay hindi isang kumpletong solusyon sa alinman sa mga problemang ito. Bagama't maaaring mag-isyu muli ang Linkerd ng mga kahilingan (kung alam nitong idempotent ang mga ito), hindi ito makakagawa ng mga desisyon tungkol sa kung ano ang ibabalik sa user kung permanenteng nabigo ang serbisyo—dapat gawin ng application ang mga desisyong iyon. Maaaring panatilihin ng Linkerd ang mga istatistika ng mga matagumpay na kahilingan, ngunit hindi nito nagagawang tingnan ang serbisyo at ibigay ang mga panloob na sukatan nito - ang application ay dapat mayroong mga ganoong tool. At bagama't ang Linkerd ay may kakayahang mag-organisa ng mTLS, ang mga ganap na solusyon sa seguridad ay nangangailangan ng higit pa.
Ang isang subset ng mga tampok sa mga lugar na ito na inaalok ng mesh ng serbisyo ay nauugnay sa mga tampok ng platform. Ang ibig kong sabihin ay mga function na:
- Independyente sa lohika ng negosyo. Ang paraan ng pagbuo ng mga histogram ng tawag sa pagitan ng Foo at Bar ay ganap na independyente bakit Tumawag si Foo kay Bar.
- Mahirap ipatupad ng tama. Sa Linkerd, ang mga muling pagsubok ay na-parameter sa lahat ng uri ng magagarang bagay tulad ng mga badyet na muling subukan (subukang muli ang mga badyet), dahil ang isang hindi sopistikado, direktang diskarte sa pagpapatupad ng mga naturang bagay ay tiyak na hahantong sa paglitaw ng isang tinatawag na "avalanche ng mga kahilingan" (subukang muli ang bagyo) at iba pang mga problemang katangian ng mga distributed system.
- Pinakamabisa kapag inilapat nang pantay. Ang mekanismo ng TLS ay may katuturan lamang kung ito ay inilalapat sa lahat ng dako.
Dahil ang mga function na ito ay ipinatupad sa antas ng proxy (at hindi sa antas ng aplikasyon), ang service mesh ay nagbibigay ng mga ito sa mga platform, hindi mga application. Kaya, hindi mahalaga kung anong wika ang nakasulat sa mga serbisyo, anong balangkas ang ginagamit nila, sino ang sumulat nito at bakit. Gumagana ang mga proxy sa labas ng lahat ng mga detalyeng ito, at ang pangunahing batayan ng functionality na ito, kabilang ang mga gawain para sa pagsasaayos, pag-update, pagpapatakbo, pagpapanatili, atbp., ay nakasalalay lamang sa antas ng platform.
Mga halimbawa ng mga kakayahan ng mesh ng serbisyo
Upang buod, ang isang service mesh ay hindi isang kumpletong solusyon para sa pagiging maaasahan, pagmamasid, o seguridad. Ang saklaw ng mga lugar na ito ay nangangailangan ng partisipasyon ng mga may-ari ng serbisyo, Ops/SRE team at iba pang entity ng kumpanya. Nagbibigay lang ang service mesh ng "slice" sa antas ng platform para sa bawat isa sa mga lugar na ito.
Bakit naging sikat ang service mesh ngayon?
Sa ngayon ay malamang na nagtataka ka: ok, kung ang service mesh ay napakahusay, bakit hindi namin sinimulan ang pag-deploy ng milyun-milyong proxy sa stack sampung taon na ang nakakaraan?
Mayroong isang banal na sagot sa tanong na ito: sampung taon na ang nakalipas lahat ay nagtayo ng mga monolith, at walang nangangailangan ng isang service mesh. Ito ay totoo, ngunit sa aking opinyon ang sagot na ito ay nakakaligtaan sa punto. Kahit sampung taon na ang nakalilipas, ang konsepto ng mga microservice bilang isang promising na paraan upang bumuo ng mga malalaking sistema ay malawakang tinalakay at inilapat sa mga kumpanya tulad ng Twitter, Facebook, Google at Netflix. Ang pangkalahatang pananaw—kahit sa mga bahagi ng industriyang nakipag-ugnayan ako—ay ang mga microservice ang "tamang paraan" upang bumuo ng malalaking sistema, kahit na ito ay napakahirap.
Siyempre, bagama't sampung taon na ang nakalilipas may mga kumpanyang nagpapatakbo ng mga microservice, hindi sila naglalagay ng mga proxy saanman nila magagawa upang bumuo ng isang service mesh. Gayunpaman, kung titingnang mabuti, may ginawa silang katulad: marami sa mga kumpanyang ito ay nangangailangan ng paggamit ng isang espesyal na panloob na aklatan para sa komunikasyon sa network (minsan ay tinatawag na isang makapal na library ng kliyente, matabang library ng kliyente).
Ang Netflix ay mayroong Hysterix, ang Google ay may Stubby, ang Twitter ay mayroong Finagle library. Ang Finagle, halimbawa, ay ipinag-uutos para sa bawat bagong serbisyo sa Twitter. Pinangangasiwaan nito ang panig ng kliyente at server ng mga koneksyon, pinapayagan para sa mga paulit-ulit na kahilingan, suportadong pagruruta ng kahilingan, pagbabalanse ng pag-load at pagsukat. Nagbigay ito ng pare-parehong layer ng pagiging maaasahan at pagmamasid sa buong Twitter stack, anuman ang ginagawa ng serbisyo. Siyempre, ito ay nagtrabaho lamang para sa mga wika ng JVM at batay sa isang modelo ng programming na kailangang gamitin para sa buong aplikasyon. Gayunpaman, ang pag-andar nito ay halos kapareho ng sa mesh ng serbisyo. (Sa katunayan, ang unang bersyon ng Linkerd ay Finagle na nakabalot lamang sa proxy form.)
Kaya, sampung taon na ang nakalilipas ay mayroong hindi lamang mga microservice, kundi pati na rin ang mga espesyal na proto-service-mesh na aklatan na nilutas ang parehong mga problema na nilulutas ng service mesh ngayon. Gayunpaman, ang mesh ng serbisyo mismo ay hindi umiiral noon. Kailangang magkaroon ng isang shift bago siya lumitaw.
At dito nakasalalay ang mas malalim na sagot, na nakatago sa isa pang pagbabago na nangyari sa nakalipas na 10 taon: ang halaga ng pag-deploy ng mga microservice ay kapansin-pansing bumaba. Ang mga kumpanyang nabanggit sa itaas na gumamit ng mga microservice sampung taon na ang nakararaan—Twitter, Netflix, Facebook, Google—ay mga kumpanyang may napakalaking sukat at napakalaking mapagkukunan. Hindi lamang sila nagkaroon ng pangangailangan, kundi pati na rin ang kakayahang bumuo, mag-deploy, at magpatakbo ng malalaking microservice-based na mga application. Ang lakas at pagsisikap na inilagay ng mga inhinyero ng Twitter sa paglipat mula sa isang monolitik patungo sa isang diskarte sa microservice ay kamangha-mangha. (Upang maging patas, gayundin ang katotohanang nagtagumpay ito.) Imposible noon ang mga ganitong uri ng infrastructural maniobra para sa maliliit na kumpanya.
Fast forward sa kasalukuyan. May mga startup ngayon kung saan ang ratio ng mga microservice sa mga developer ay 5:1 (o kahit na ), at higit pa, matagumpay nilang nakayanan ang mga ito! Kung ang isang 5-taong startup ay madaling makapagpatakbo ng 50 microservice, kung gayon ay may malinaw na nakabawas sa gastos ng kanilang pagpapatupad.
1500 microservices sa Monzo; ang bawat linya ay isang iniresetang panuntunan sa network na nagbibigay-daan sa trapiko
Ang kapansin-pansing pagbawas sa gastos ng pagpapatakbo ng mga microservice ay resulta ng isang proseso: lumalagong katanyagan ng mga lalagyan и mga orkestra. Ito ay tiyak na malalim na sagot sa tanong kung ano ang nag-ambag sa paglitaw ng mesh ng serbisyo. Ginawang kaakit-akit ng parehong teknolohiya ang mga service meshes at microservice: Kubernetes at Docker.
Bakit? Well, nilulutas ng Docker ang isang malaking problema - ang problema sa packaging. Sa pamamagitan ng pag-iimpake ng isang application at ang mga (hindi network) na mga dependency ng runtime nito sa isang lalagyan, ginagawa ng Docker ang application sa isang mapagpapalit na unit na maaaring i-host at patakbuhin kahit saan. Kasabay nito, lubos nitong pinapadali ang operasyon multilinggwal Stack: Dahil ang container ay isang atomic unit of execution, para sa deployment at operational purposes, hindi mahalaga kung ano ang nasa loob, ito man ay JVM, Node, Go, Python, o Ruby application. Ilunsad mo lang ito at iyon na.
Dinadala ng Kubernetes ang lahat sa susunod na antas. Ngayon na may mga toneladang "mga bagay na tatakbo" at tonelada ng mga makina upang patakbuhin ang mga ito, mayroong pangangailangan para sa isang tool na maaaring mag-ugnay sa mga ito sa isa't isa. Sa isang malawak na kahulugan, binibigyan mo ang Kubernetes ng maraming lalagyan at maraming makina, at ito ay nagmamapa sa kanila laban sa isa't isa (siyempre, ito ay isang pabago-bago at pabago-bagong proseso: gumagalaw ang mga bagong lalagyan sa buong system, nagsisimula at humihinto ang mga makina. , atbp. Gayunpaman, isinasaalang-alang ng Kubernetes ang lahat ng ito ).
Kapag na-configure na ang Kubernetes, ang halaga ng oras para i-deploy at patakbuhin ang isang serbisyo ay kaunti na lang naiiba sa gastos sa pag-deploy at pagpapatakbo ng sampung serbisyo (sa katunayan, ito ay halos pareho para sa 100 serbisyo). Idagdag sa mga lalagyan na ito bilang isang mekanismo ng packaging na naghihikayat sa pagpapatupad ng maraming wika, at mayroon kang maraming bagong application na ipinatupad sa anyo ng mga microservice na nakasulat sa iba't ibang wika - eksakto ang uri ng kapaligiran kung saan ang isang service mesh ay angkop na angkop para sa.
Kaya, dumating tayo sa sagot sa tanong kung bakit naging popular ngayon ang ideya ng isang service mesh: ang homogeneity na ibinibigay ng Kubernetes para sa mga serbisyo ay direktang naaangkop sa mga hamon sa pagpapatakbo na kinakaharap ng isang service mesh. Ibinalot mo ang mga proxy sa mga lalagyan, binibigyan mo ang Kubernetes ng gawain na ilagay ang mga ito saanman ito magagawa, at voila! Bilang resulta, makakakuha ka ng isang service mesh, habang ang lahat ng mekanika ng pag-deploy nito ay pinamamahalaan ng Kubernetes. (Hindi bababa sa isang view ng mata ng ibon. Siyempre, maraming mga nuances sa prosesong ito.)
Sa kabuuan: ang dahilan kung bakit naging tanyag ang mga service meshes ngayon, at hindi sampung taon na ang nakalipas, ay ang Kubernetes at Docker ay hindi lamang tumaas nang malaki. kailangan sa loob nito, na pinasimple ang pagpapatupad ng mga aplikasyon bilang mga hanay ng mga multilinggwal na microservice, ngunit makabuluhang nabawasan din gastos para sa operasyon nito, na nagbibigay ng mga mekanismo para sa pag-deploy at pagsuporta sa sidecar proxy fleets.
Bakit napakaraming usapan tungkol sa service mesh?
Babala: Sa seksyong ito, ginagamit ko ang lahat ng uri ng mga pagpapalagay, haka-haka, katha at panloob na impormasyon.
Magsagawa ng paghahanap para sa "service mesh" at makakatagpo ka ng isang toneladang recycled na nilalamang mababa ang calorie, mga kakaibang proyekto, at isang kaleidoscope ng distortion na karapat-dapat sa isang echo chamber. Ginagawa ito ng anumang magarbong bagong teknolohiya, ngunit sa kaso ng isang service mesh ang problema ay lalo na talamak. Bakit?
Well, bahagi nito ay kasalanan ko. Nagsumikap ako nang husto upang i-promote ang Linkerd at ang serbisyo sa bawat pagkakataon na nakukuha ko sa hindi mabilang na mga post sa blog at artikulong tulad nito. Pero hindi ako ganoon kalakas. Upang talagang masagot ang tanong na ito, kailangan nating pag-usapan nang kaunti ang tungkol sa pangkalahatang sitwasyon. At imposibleng pag-usapan ito nang hindi binabanggit ang isang proyekto: ay isang open source service mesh na binuo ng Google, IBM at Lyft.
(Ang tatlong kumpanya ay may iba't ibang tungkulin: Lumilitaw na ang paglahok ng Lyft ay nasa pangalan lamang; sila ang mga may-akda ng Envoy, ngunit hindi gumagamit o nakikilahok sa pag-unlad ni Istio. Ang IBM ay kasangkot at gumagamit ng pag-unlad ni Istio. Ang Google ay aktibong kasangkot sa Istio's development , ngunit hindi talaga ito ginagamit sa abot ng aking masasabi.)
Ang proyekto ng Istio ay kapansin-pansin para sa dalawang bagay. Una, mayroong napakalaking pagsusumikap sa marketing na ang Google, sa partikular, ay inilalagay sa pag-promote nito. Itatantya ko na ang karamihan sa mga taong nakakaalam ng konsepto ng service mesh ngayon ay unang natutunan ang tungkol dito sa pamamagitan ng Istio. Ang pangalawang bagay ay kung gaano kahirap ang pagtanggap kay Istio. Sa bagay na ito, maliwanag na interesado akong partido, ngunit sinusubukan kong manatiling layunin hangga't maaari, hindi pa rin ako makakatulong , hindi masyadong natatangi (bagaman hindi natatangi: systemd ang nasa isip, ...) para sa isang Open Source na proyekto.
(Sa pagsasagawa, si Istio ay tila may mga problema hindi lamang sa pagiging kumplikado at UX, kundi pati na rin sa pagganap. Halimbawa, sa panahon ng Sa isang third-party na pag-aaral, nakita ng mga mananaliksik ang mga sitwasyon kung saan ang latency ng buntot ni Istio ay 100 beses na mas mataas kaysa sa Linkerd, pati na rin ang mga sitwasyong nagugutom sa mapagkukunan kung saan patuloy na gumana ang Linkerd habang si Istio ay ganap na tumigil sa pagtatrabaho.)
Isinasantabi ang aking mga teorya tungkol sa kung bakit nangyari ito, naniniwala ako na ang labis na kasabikan sa paligid ng service mesh ay ipinaliwanag ng pakikilahok ng Google. Ibig sabihin, isang kumbinasyon ng sumusunod na tatlong mga kadahilanan:
- Ang mapanghimasok na promosyon ng Google sa Istio;
- isang kaukulang hindi pagsang-ayon, kritikal na saloobin sa proyekto;
- ang kamakailang meteoric na pagtaas sa katanyagan ng Kubernetes, ang mga alaala na sariwa pa rin.
Magkasama ang mga salik na ito ay nagsasama-sama upang lumikha ng isang nakakabigla, walang oxygen na kapaligiran kung saan ang kapasidad para sa makatwirang paghatol ay humihina, at tanging ang kakaibang uri na lang ang natitira. .
Mula sa pananaw ni Linkerd, ito ay...ang ilalarawan ko bilang isang halo-halong pagpapala. Ibig kong sabihin, napakaganda na ang service mesh ay pumasok sa mainstream sa paraang hindi noong 2016 noong unang nagsimula ang Linkerd at talagang mahirap na bigyan ng pansin ng mga tao ang proyekto. Ngayon walang ganoong problema! Ngunit ang masamang balita ay ang landscape ng service mesh ay napakalito ngayon na halos imposibleng maunawaan kung aling mga proyekto ang aktwal na nabibilang sa kategorya ng mesh ng serbisyo (pabayaan lamang na maunawaan kung alin ang pinakaangkop para sa isang partikular na kaso ng paggamit). Ito ay talagang isang dealbreaker para sa lahat (at tiyak na may ilang mga kaso kung saan ang Istio o isa pang proyekto ay mas angkop kaysa sa Linkerd, dahil ang huli ay hindi pa rin isang unibersal na solusyon).
Sa panig ng Linkerd, ang aming diskarte ay ang huwag pansinin ang ingay, patuloy na tumuon sa paglutas ng mga tunay na problema sa komunidad, at mahalagang maghintay na mawala ang hype. Sa huli, humupa ang hype at maaari tayong magpatuloy sa trabaho nang mahinahon.
Samantala, kailangan nating lahat na maging mapagpasensya nang kaunti.
Magiging kapaki-pakinabang ba sa akin ang isang service mesh, isang hamak na software engineer?
Ang sumusunod na talatanungan ay tutulong sa iyo na sagutin ang tanong na ito:
Ikaw ba ay kasangkot lamang sa pagpapatupad ng lohika ng negosyo? Sa kasong ito, ang mesh ng serbisyo ay hindi magiging kapaki-pakinabang sa iyo. Iyon ay, siyempre, maaari kang maging interesado dito, ngunit ang perpektong mesh ng serbisyo ay hindi dapat direktang makakaapekto sa anumang bagay sa iyong kapaligiran. Patuloy na magtrabaho sa kung ano ang binabayaran sa iyo na gawin.
Sinusuportahan mo ba ang platform sa isang kumpanyang gumagamit ng Kubernetes? Oo, sa kasong ito kailangan mo ng isang mesh ng serbisyo (maliban kung, siyempre, gumagamit ka ng mga K8 para lamang magpatakbo ng isang monolith o pagproseso ng batch - ngunit pagkatapos ay nais kong itanong kung bakit kailangan mo ng mga K8). Malamang na magkakaroon ka ng maraming microservice na isinulat ng iba't ibang tao. Nakikipag-ugnayan silang lahat sa isa't isa at nakatali sa isang gusot ng runtime dependencies, at kailangan mong humanap ng paraan para harapin ang lahat ng ito. Ang paggamit ng Kubernetes ay nagbibigay-daan sa iyong pumili ng mesh ng serbisyo “para sa iyong sarili.” Upang gawin ito, gawing pamilyar ang iyong sarili sa kanilang mga kakayahan at tampok at sagutin ang tanong kung ang alinman sa mga magagamit na proyekto ay angkop para sa iyo (Inirerekumenda kong simulan ang iyong pananaliksik sa Linkerd).
Ikaw ba ay isang kumpanya ng platform sa isang kumpanya na HINDI gumagamit ng Kubernetes ngunit gumagamit ng mga microservice? Sa kasong ito, ang isang service mesh ay magiging kapaki-pakinabang sa iyo, ngunit ang paggamit nito ay hindi mahalaga. Syempre kaya mo gayahin work service mesh sa pamamagitan ng paglalagay ng grupo ng mga proxy, ngunit ang isang mahalagang bentahe ng Kubernetes ay ang deployment model: mangangailangan ng mas maraming oras, pagsisikap at gastos ang manu-manong pagpapanatili ng mga proxy na ito.
Responsable ka ba para sa platform sa isang kumpanyang gumagana sa mga monolith? Sa kasong ito, malamang na hindi mo kailangan ng service mesh. Kung nagtatrabaho ka sa mga monolith (o kahit na mga koleksyon ng mga monolith) na may mahusay na tinukoy at bihirang nagbabago ng mga pattern ng pakikipag-ugnayan, kung gayon ang isang service mesh ay may kaunting maiaalok sa iyo. Kaya't maaari mo na lang itong balewalain at umasa na ito ay maglaho na parang isang masamang panaginip...
Konklusyon
Malamang, ang service mesh ay hindi pa rin dapat tawaging "pinaka-hyped na teknolohiya sa mundo" - ang kahina-hinalang karangalan na ito ay malamang na pag-aari ng Bitcoin o AI. Malamang nasa top five siya. Ngunit kung pumutol ka sa mga layer ng ingay, magiging malinaw na ang service mesh ay nagdudulot ng mga tunay na benepisyo sa mga gumagawa ng mga application sa Kubernetes.
Gusto kong subukan mo ang Linkerd - i-install ito sa isang Kubernetes cluster (o kahit Minikube sa isang laptop) , at makikita mo mismo kung ano ang sinasabi ko.
FAQ
— Kung papansinin ko ang service mesh, mawawala ba ito?
— Dapat kitang biguin: ang service mesh ay nasa amin sa mahabang panahon.
- Ngunit AYAW kong gumamit ng mesh ng serbisyo!
- Well, ito ay hindi kinakailangan! Basahin lamang ang aking talatanungan sa itaas upang maunawaan kung dapat mong maging pamilyar sa mga pangunahing kaalaman nito.
— Hindi ba ito magandang lumang ESB/middleware na may bagong sarsa?
— Ang service mesh ay tumatalakay sa operational logic, hindi semantiko. enterprise service bus (). Ang pagpapanatili sa paghihiwalay na ito ay nakakatulong sa service mesh na maiwasan ang parehong kapalaran.
— Paano naiiba ang isang service mesh sa mga gateway ng API?
— Mayroong isang milyong mga artikulo sa paksang ito. I-google mo na lang.
— Ang sugo ay isang service mesh?
- Hindi, ang Envoy ay hindi isang service mesh, ito ay isang proxy server. Maaari itong magamit upang ayusin ang isang mesh ng serbisyo (at higit pa - ito ay isang proxy na pangkalahatang layunin). Ngunit sa sarili nito ay hindi ito isang service mesh.
— Ang Network Service Mesh ay isang service mesh?
- Hindi. Sa kabila ng pangalan, hindi ito isang service mesh (paano mo gusto ang mga milagro sa marketing?).
— Makakatulong ba ang isang service mesh sa aking message queue-based reactive asynchronous system?
- Hindi, hindi makakatulong sa iyo ang service mesh.
— Aling service mesh ang dapat kong gamitin?
- , walang utak.
- Ang artikulo ay nakakainis! / Ang may-akda ay malugod na tinatanggap!
— Pakibahagi ang link dito sa lahat ng iyong mga kaibigan para makita nila ito!
Mga Pasasalamat
Tulad ng maaaring nahulaan mo mula sa pamagat, ang artikulong ito ay inspirasyon ng kamangha-manghang treatise ni Jay Kreps "" Nakilala ko si Jay sampung taon na ang nakalilipas nang makapanayam ko siya sa Linked In at naging inspirasyon ko siya noon pa man.
Bagama't gusto kong tawagan ang aking sarili na "Linkerd developer", ang katotohanan ay higit pa akong taga-maintain ng README.md file sa isang proyekto. Ang Linkerd ay ginagawa ngayon , , tao, at hindi mangyayari ang proyektong ito kung wala ang pakikilahok ng isang napakagandang komunidad ng mga nag-aambag at gumagamit.
At sa wakas, isang espesyal na pasasalamat sa lumikha ng Linkerd, (primus inter pares), na, kasama ko maraming taon na ang nakalilipas, sumabak sa lahat ng kaguluhang ito sa service mesh.
PS mula sa tagasalin
Basahin din sa aming blog:
- «";
- «";
- «";
- «";
- «'.
Pinagmulan: www.habr.com