Kumbuka. tafsiri.: Matundu ya huduma ni jambo ambalo bado halina tafsiri thabiti kwa Kirusi (zaidi ya miaka 2 iliyopita tulitoa chaguo "mesh kwa huduma", na baadaye kidogo, wenzake wengine walianza kukuza mchanganyiko wa "huduma ungo"). . Majadiliano ya mara kwa mara kuhusu teknolojia hii yamesababisha hali ambayo vipengele vya uuzaji na kiufundi vinaunganishwa kwa karibu sana. Nyenzo hii nzuri kutoka kwa mmoja wa waandishi wa neno la asili imekusudiwa kuleta uwazi kwa wahandisi na sio tu.
Vichekesho kutoka
Utangulizi
Ikiwa wewe ni mhandisi wa programu unafanya kazi mahali fulani katika eneo la mifumo ya nyuma, neno "mesh ya huduma" labda tayari limewekwa katika akili yako katika miaka michache iliyopita. Shukrani kwa sadfa ya kushangaza, msemo huu unatawala sekta hii zaidi na zaidi, na shamrashamra na ofa zinazohusiana na matangazo zinakua kama mpira wa theluji, zikiruka mlimani na hazionyeshi dalili za kupungua.
Matundu ya huduma yalizaliwa katika hali tulivu, ya maji ya mfumo ikolojia asilia wa mawingu. Kwa bahati mbaya, hii ina maana kwamba mengi ya utata unaoizunguka ni kati ya "mazungumzo ya kalori ya chini" hadi-kutumia neno la kiufundi-uzushi mtupu. Lakini ukichuja kelele zote, unaweza kupata kwamba mesh ya huduma ina kazi halisi, ya uhakika na muhimu.
Katika chapisho hili, nitajaribu kufanya hivyo tu: kutoa mwongozo wa uaminifu, wa kina, unaoelekezwa kwa mhandisi kwa mesh ya huduma. Nitajibu zaidi ya swali tu: "Ni nini?", - lakini pia "Kwa nini?"Na "Kwanini sasa?". Hatimaye, nitajaribu kuelezea kwa nini (kwa maoni yangu) teknolojia hii imesababisha hype ya mambo, ambayo yenyewe ni hadithi ya kuvutia.
Mimi ni nani?
Salaam wote! Jina langu ni . Mimi ni mmoja wa waumbaji - mradi wa kwanza wa matundu ya huduma na mradi ambao unalaumiwa kwa kuonekana kwa muda matundu ya huduma kama vile (samahani watu!). (Kumbuka transl.: Kwa njia, mwanzoni mwa kuonekana kwa neno hili, zaidi ya miaka 2,5 iliyopita, tayari tulitafsiri nyenzo za mapema za mwandishi huyo anayeitwa "".) Mimi pia naongoza ni mwanzo ambao huunda vitu vya mesh vya huduma nzuri kama Linkerd na .
Labda unaweza kudhani kuwa nina maoni ya upendeleo na ya kibinafsi juu ya suala hili. Walakini, nitajaribu kuweka upendeleo kwa kiwango cha chini (isipokuwa sehemu moja: "Kwa nini kuna mazungumzo mengi juu ya mesh ya huduma?", - ambayo hata hivyo nitashiriki mawazo yangu ya awali). Pia nitafanya kila niwezalo kuufanya mwongozo huu kuwa lengo kadiri niwezavyo. Katika mifano maalum, nitategemea sana uzoefu wa Linkerd, huku nikionyesha tofauti (ikiwa zipo) ambazo najua katika utekelezaji wa aina zingine za matundu ya huduma.
Sawa, ni wakati wa kuendelea na chipsi.
Mesh ya huduma ni nini?
Licha ya hype yote, mesh ya huduma ni rahisi sana kimuundo. Ni rundo tu la seva mbadala za nafasi ya mtumiaji ziko "karibu na" huduma (tutazungumza kidogo kuhusu "karibu" baadaye), pamoja na seti ya michakato ya udhibiti. Wakala huitwa kwa pamoja ndege ya data, na michakato ya udhibiti inaitwa ndege ya kudhibiti. Ndege ya data inakata simu kati ya huduma na hufanya "chochote tofauti" nao; ndege ya udhibiti, kwa mtiririko huo, inaratibu tabia ya wakala na hutoa ufikiaji kwako, i.e. opereta, kwa API, kuruhusu mtandao kudanganywa na kupimwa kwa ujumla.
Wakala huu ni nini? Hii ni proksi ya TCP ya kitengo cha "Layer 7-aware". (yaani "kwa kuzingatia" safu ya 7 ya mfano wa OSI) kama HAProxy na NGINX. Unaweza kuchagua wakala kwa kupenda kwako; Linkerd hutumia proksi ya Rust, iliyopewa jina kwa urahisi . Tumeikusanya mahsusi kwa matundu ya huduma. Matundu mengine yanapendelea washirika wengine (Mjumbe ni chaguo la kawaida). Hata hivyo, kuchagua wakala ni suala la utekelezaji tu.
Je, seva hizi za wakala hufanya nini? Ni wazi, wao hupiga simu za proksi kwenda na kutoka kwa huduma (kwa kweli, hufanya kama washirika na wakala wa nyuma, wakishughulikia simu zinazoingia na zinazotoka). Na wao hutekeleza seti ya kipengele inayozingatia simu kati ya huduma. Kuzingatia huku kwa trafiki kati ya huduma ndiko kunakotofautisha proksi ya matundu ya huduma kutoka, tuseme, lango la API au seva mbadala za ingress (mwisho ikilenga simu zinazoingia kwenye kundi kutoka kwa ulimwengu wa nje). (Kumbuka. tafsiri.: Kwa ulinganisho wa vidhibiti vilivyopo vya Kubernetes Ingress, ambavyo vingi vinatumia Mjumbe aliyetajwa tayari, ona. .)
Kwa hivyo, tuligundua ndege ya data. Ndege ya udhibiti ni rahisi zaidi: ni seti ya vipengele vinavyotoa mbinu zote ambazo ndege ya data inahitaji kufanya kazi kwa njia iliyoratibiwa, ikiwa ni pamoja na ugunduzi wa huduma, utoaji wa cheti cha TLS, ujumlishaji wa vipimo, n.k. Ndege ya data hufahamisha ndege ya udhibiti kuhusu tabia yake; kwa upande mwingine, ndege ya udhibiti hutoa API ambayo inakuwezesha kubadilisha na kufuatilia tabia ya ndege ya data kwa ujumla.
Chini ni mchoro wa ndege ya kudhibiti na ndege ya data huko Linkerd. Kama unavyoona, ndege ya udhibiti inajumuisha vipengele kadhaa tofauti, ikiwa ni pamoja na mfano wa Prometheus ambao hukusanya metriki kutoka kwa seva za wakala, pamoja na vipengele vingine kama vile. destination (ugunduzi wa huduma), identity (mamlaka ya cheti, CA) na public-api (mwisho kwa wavuti na CLI). Kinyume chake, ndege ya data ni wakala rahisi wa kiunganishi karibu na mfano wa programu. Huu ni mchoro wa mantiki tu; katika matumizi ya ulimwengu halisi, unaweza kuwa na nakala tatu za kila sehemu ya ndege inayodhibiti na mamia au maelfu ya proksi kwenye ndege ya data.
(Sanduku za buluu kwenye mchoro huu zinawakilisha mipaka ya maganda ya Kubernetes. Unaweza kuona kwamba vyombo vilivyo na kiungo-badala viko kwenye ganda sawa na vyombo vya maombi. Mpango huu unajulikana kama chombo cha kando.)
Usanifu wa matundu ya huduma una athari kadhaa muhimu. Kwanza, kwa kuwa kazi ya wakala ni kukata simu kati ya huduma, mesh ya huduma inaeleweka ikiwa programu yako iliundwa kwa seti ya huduma. matundu mtu anaweza tumia na monoliths, lakini hii ni wazi kuwa haina maana kwa ajili ya wakala mmoja, na utendaji wake hauwezekani kuwa katika mahitaji.
Matokeo mengine muhimu ni kwamba matundu ya huduma yanahitaji kubwa idadi ya wakala. Kwa kweli, Linkerd hufunga seva mbadala ya kiunganishi kwa kila mfano wa kila huduma (utekelezaji mwingine huongeza proksi kwa kila mwenyeji/mwenyeji/VM. Hiyo ni nyingi hata hivyo). Matumizi kama haya ya proksi yenyewe hubeba shida kadhaa za ziada:
- Wakala katika ndege ya data wanapaswa kuwa haraka, kwa sababu kwa kila simu kuna simu kadhaa kwa wakala: moja kwa upande wa mteja, moja kwa upande wa seva.
- Pia, wakala lazima wawe ndogo ΠΈ nyepesi. Kila moja itatumia kumbukumbu na rasilimali za CPU, na matumizi haya yatakua sawia na programu.
- Utahitaji utaratibu wa kupeleka na kusasisha idadi kubwa ya proksi. Kufanya kwa mikono sio chaguo.
Kwa ujumla, matundu ya huduma yanaonekana kama hii (angalau kwa mtazamo wa jicho la ndege): unatumia rundo la seva mbadala za nafasi ya mtumiaji ambazo "hufanya kitu" na trafiki ya ndani, ya huduma baina ya huduma, na unatumia ndege ya udhibiti kuzifuatilia na kuzidhibiti.
Ni wakati wa swali "Kwa nini?"
Mesh ya huduma ni ya nini?
Kwa wale ambao walipata wazo la kwanza la mesh ya huduma, inaweza kusamehewa kuwa na mshangao kidogo. Ubunifu wa matundu ya huduma inamaanisha kuwa sio tu itaongeza latency ya programu, lakini pia itaongeza tumia rasilimali na itaongeza rundo la taratibu mpya katika miundombinu. Kwanza unasanidi matundu ya huduma, na kisha ghafla unajikuta unahitaji kutumikia mamia (ikiwa sio maelfu) ya proksi. Swali ni je, nani atajitolea kwa hili?
Jibu la swali hili lina sehemu mbili. Kwanza, gharama za muamala zinazohusiana na kupeleka proksi hizi zinaweza kupunguzwa kwa kiasi kikubwa kutokana na baadhi ya mabadiliko yanayotokea katika mfumo ikolojia (zaidi kuhusu hili baadaye).
Pili, kifaa kama hicho ni njia nzuri ya kuanzisha mantiki ya ziada kwenye mfumo. Na si tu kwa sababu vipengele vingi vipya vinaweza kuongezwa kwa kutumia mesh ya huduma, lakini pia kwa sababu inaweza kufanyika bila kuingilia kati na mazingira. Kwa kweli, mtindo mzima wa mesh wa huduma unategemea postulate hii: katika mfumo wa huduma nyingi, bila kujali fanya huduma za kibinafsi, trafiki kati yao ni hatua bora ya kuongeza utendaji.
Kwa mfano, katika Linkerd (kama vile meshes nyingi) utendakazi unalenga hasa simu za HTTP, ikiwa ni pamoja na HTTP/2 na gRPC*. Utendaji ni tajiri sana - inaweza kugawanywa katika madarasa matatu:
- Kazi zinazohusiana na kutegemewa. Jaribu tena maombi, muda umeisha, mbinu ya canary (mgawanyiko/elekeza upya trafiki), n.k.
- Kazi zinazohusiana na ufuatiliaji. Kujumlisha viwango vya mafanikio, ucheleweshaji na idadi ya maombi kwa kila huduma au maeneo ya mtu binafsi; kujenga ramani za topolojia za huduma, nk.
- Kazi zinazohusiana na usalama. TLS ya pamoja, udhibiti wa ufikiaji, n.k.
* Kwa mtazamo wa Linkerd, gRPC kwa kweli haina tofauti na HTTP/2: inatumia tu protobuf kwenye upakiaji. Kwa mtazamo wa msanidi programu, mambo haya mawili, bila shaka, ni tofauti.
Mengi ya mifumo hii hufanya kazi katika kiwango cha ombi (kwa hivyo "proksi ya L7"). Kwa mfano, ikiwa huduma ya Foo itapiga simu ya HTTP kwa Upau wa huduma, seva mbadala iliyounganishwa kwenye upande wa Foo inaweza kupakia salio kwa akili na kuelekeza simu kutoka kwa matukio ya Foo hadi Bar kulingana na muda unaozingatiwa; inaweza kurudia ombi ikiwa ni lazima (na ikiwa haina nguvu); anaweza kurekodi msimbo wa majibu na muda wa kuisha, na kadhalika. Vile vile, seva mbadala iliyounganishwa kwenye upande wa Mwamba inaweza kukataa ombi ikiwa hairuhusiwi au ikiwa kikomo cha ombi kimepitwa; inaweza kurekebisha kuchelewa kwa upande wake, nk.
Wakala wanaweza "kufanya kitu" katika kiwango cha unganisho pia. Kwa mfano, seva mbadala iliyounganishwa kwenye upande wa Foo inaweza kuanzisha muunganisho wa TLS, na wakala wa kiunganishi kwenye upande wa Mwambaau unaweza kuuzima, na pande zote mbili zinaweza kuthibitisha vyeti vya TLS* vya kila mmoja. Hii haitoi tu usimbaji fiche kati ya huduma, lakini pia njia salama ya kutambua huduma kwa njia fiche: Foo na Bar wanaweza "kuthibitisha" kwamba wao ni wale wanayosema.
* "Rafiki wa rafiki" inamaanisha kuwa cheti cha mteja pia kimethibitishwa (TLS ya pande zote). Katika TLS ya "classic", kwa mfano, kati ya kivinjari na seva, cheti cha upande mmoja tu (seva) kawaida huthibitishwa.
Ikiwa zinafanya kazi kwa kiwango cha ombi au muunganisho, ni muhimu kusisitiza kwamba vipengele vyote vya mesh ya huduma ni inayofanya kazi tabia. Linkerd haiwezi kubadilisha semantiki za upakiaji, kama vile kuongeza sehemu kwenye kipande cha JSON au kufanya mabadiliko kwenye protobuf. Tutazungumza juu ya kipengele hiki muhimu baadaye tunapozungumza kuhusu ESB na vifaa vya kati.
Hii ni seti ya vipengele ambavyo mesh ya huduma hutoa. Swali linatokea: kwa nini usizitekeleze moja kwa moja kwenye programu? Na kwa nini fujo na wakala kabisa?
Kwa nini mesh ya huduma ni wazo nzuri
Ingawa uwezo wa matundu ya huduma unavutia, thamani yake kuu haiko katika vipengele. Mwishowe sisi Je! kutekeleza moja kwa moja kwenye programu (baadaye tutaona kwamba hii ilikuwa asili ya mesh ya huduma). Ili kuiweka katika sentensi moja, thamani ya mesh ya huduma ni: hutoa utendakazi muhimu katika kuendesha programu ya seva ya kisasa kwa njia thabiti, pana, ya msimbo wa maombi-agnostic..
Hebu tuchambue pendekezo hili.
Β«Kazi Muhimu kwa Kuendesha Programu ya Seva ya Kisasa". Ikiwa unaunda programu ya seva ya muamala iliyounganishwa kwenye mtandao wa umma ambayo inakubali maombi kutoka kwa ulimwengu wa nje na kuyajibu ndani ya muda mfupi - kwa mfano, programu ya wavuti, seva ya API, na idadi kubwa ya programu zingine za kisasa - na ikiwa utaitekeleza kama seti ya huduma zinazoingiliana kwa usawa na kila mmoja, na ikiwa unasasisha programu hii kila wakati, na kuongeza huduma mpya, na ikiwa utalazimika kuweka mfumo huu katika hali ya kufanya kazi wakati wa mchakato wa kurekebisha - katika kesi hii, hongera, unaunda programu za kisasa za seva . Na vipengele vyote vyema vilivyoorodheshwa hapo juu vinageuka kuwa muhimu kwako. Programu lazima iwe ya kuaminika, salama, na lazima uweze kuona inachofanya. Ni maswali haya ambayo mesh ya huduma husaidia kutatua.
(Sawa, imani yangu kwamba mbinu hii ni njia ya kisasa ya kuunda programu ya seva imeingia kwenye aya iliyotangulia. Wengine wanapendelea kukuza monoliths, "reactive microservices" na vitu vingine ambavyo haviko chini ya ufafanuzi uliotolewa hapo juu. Watu hawa labda wanayo. maoni ambayo yanatofautiana na yangu, na kwa upande wake, ninaamini kuwa "sio sahihi" - ingawa kwa hali yoyote, mesh ya huduma sio muhimu sana kwao).
Β«Sare kwa rafu nzima". Vipengele vilivyotolewa na mesh ya huduma sio muhimu tu. Zinatumika kwa huduma zote katika programu, bila kujali zimeandikwa kwa lugha gani, ni mfumo gani wanatumia, ni nani aliyeziandika, jinsi zilivyotumwa, na hila zingine zote za ukuzaji na matumizi yao.
Β«Msimbo wa maombi huru". Hatimaye, matundu ya huduma haitoi tu utendakazi thabiti kwenye safu nzima, hufanya hivyo kwa njia ambayo haihitaji kuhariri programu. Msingi wa kimsingi wa utendakazi wa matundu ya huduma, ikijumuisha majukumu ya kusanidi, kusasisha, kufanya kazi, kudumisha, n.k., iko katika kiwango cha jukwaa na haitegemei programu tumizi. Programu inaweza kubadilika bila kuathiri mesh ya huduma. Kwa upande mwingine, mesh ya huduma inaweza kubadilika bila uingiliaji wowote wa programu.
Kwa kifupi, mesh ya huduma haitoi tu utendakazi muhimu, lakini hufanya hivyo kwa njia ya kimataifa, sare, na inayojitegemea ya matumizi. Na kwa hivyo, wakati utendaji wa matundu ya huduma unaweza kutekelezwa katika nambari ya huduma (kwa mfano, kama maktaba iliyojumuishwa na kila huduma), mbinu hii haitatoa usawa na uhuru ambao ni muhimu sana katika kesi ya mesh ya huduma.
Na unachohitaji kufanya ni kuongeza rundo la washirika! Ninaahidi, hivi karibuni tutaangalia gharama za uendeshaji zinazohusiana na kuongeza proksi hizi. Lakini kwanza, hebu tuache na tuangalie wazo hili la uhuru kutoka kwa mtazamo wa anuwai watu.
Je, mesh ya huduma inasaidia nani?
Ingawa inaweza kuwa ngumu, ili teknolojia iwe sehemu muhimu ya mfumo wa ikolojia, ni lazima ukubaliwe na watu. Kwa hivyo ni nani anayevutiwa na matundu ya huduma? Nani anafaidika na matumizi yake?
Ikiwa utatengeneza programu ya seva ya kisasa, unaweza kufikiria timu yako kama kikundi wamiliki wa hudumaambao kwa pamoja wanakuza na kutekeleza mantiki ya biashara, na wamiliki wa jukwaakushiriki katika maendeleo ya jukwaa la ndani ambalo huduma hizi zinaendeshwa. Katika mashirika madogo, hawa wanaweza kuwa watu sawa, lakini kadiri kampuni inavyokua, majukumu haya huwa yanatamkwa zaidi na hata kugawanywa katika majukumu madogo ... (Kuna mengi ya kusemwa hapa juu ya mabadiliko ya asili ya devops, athari za shirika za huduma ndogo, nk) n. Lakini kwa sasa, hebu tuchukue maelezo haya kwa urahisi).
Kwa mtazamo huu, walengwa wazi wa mesh ya huduma ni wamiliki wa jukwaa. Baada ya yote, lengo kuu la timu ya jukwaa ni kuunda jukwaa la ndani ambalo wamiliki wa huduma wanaweza kutekeleza mantiki ya biashara na kuifanya kwa njia ambayo inawahakikishia uhuru wa juu kutoka kwa maelezo mabaya ya uendeshaji wake. Mesh ya huduma haitoi tu uwezo muhimu wa kufikia lengo hili, inafanya hivyo kwa njia ambayo, kwa upande wake, haitoi utegemezi kwa wamiliki wa huduma.
Wamiliki wa huduma pia hunufaika, ingawa kwa njia isiyo ya moja kwa moja. Lengo la mmiliki wa huduma ni kuwa na tija iwezekanavyo katika kutekeleza mantiki ya mchakato wa biashara, na chini ana wasiwasi kuhusu masuala ya uendeshaji, bora zaidi. Badala ya kutekeleza, tuseme, jaribu tena sera au TLS, wanaweza kuzingatia biashara pekee na kutumaini kuwa jukwaa litashughulikia mengine. Kwao, hii ni faida kubwa.
Thamani ya shirika ya mgawanyiko huo kati ya wamiliki wa majukwaa na huduma haiwezi kuwa overestimated. Nadhani anachangia kuu mchango kwa thamani ya mesh ya huduma.
Tulijifunza somo hili wakati shabiki wa mapema wa Linkerd alituambia kwa nini walichagua mesh ya huduma: kwa sababu iliwaruhusu "kuendelea kuzungumza kwa uchache zaidi." Hapa kuna maelezo kadhaa: wavulana kutoka kampuni moja kubwa walihamia jukwaa lao hadi Kubernetes. Kwa kuwa programu ilifanya kazi na taarifa nyeti, walitaka kusimba mawasiliano yote kwenye makundi. Hata hivyo, hali ilikuwa ngumu kutokana na kuwepo kwa mamia ya huduma na mamia ya timu za maendeleo. Matarajio ya kuwasiliana na kila mtu na kuwashawishi kujumuisha msaada kwa TLS katika mipango yao haikuwafurahisha hata kidogo. Kwa kusakinisha Linkerd, walihama wajibu kutoka kwa watengenezaji (kutoka kwa maoni yao ilikuwa shida isiyo ya lazima) hadi waendeshaji majukwaa, ambao hii ilikuwa kipaumbele cha hali ya juu. Kwa maneno mengine, Linkerd ilikuwa ikiwatatulia sio shida ya kiufundi kama ya shirika.
Kwa kifupi, mesh ya huduma ni, badala yake, sio suluhisho la kiufundi, lakini kijamii na kiufundi Matatizo. (Asante kwa ajili ya kutambulisha neno hili.
Je, mesh ya huduma itatatua matatizo yangu yote?
Ndiyo. Namaanisha, hapana!
Kuangalia madarasa matatu ya vipengele vilivyoainishwa hapo juu - kuegemea, usalama, na kuzingatiwa - inakuwa wazi kuwa mesh ya huduma sio suluhisho kamili kwa shida zozote hizi. Ingawa Linkerd inaweza kutuma maombi yanayorudiwa (ikiwa inajua kuwa hawana uwezo), haiko katika nafasi ya kufanya maamuzi kuhusu nini cha kurudisha kwa mtumiaji ikiwa huduma imeshuka - maamuzi kama hayo lazima yafanywe na programu. Linkerd inaweza kuweka takwimu kuhusu maombi yaliyofaulu, lakini haiwezi kuangalia huduma na kutoa vipimo vyake vya ndani - programu inapaswa kuwa na zana kama hiyo. Na ingawa Linkerd ina uwezo wa kukaribisha mTLS, suluhu kamili za usalama zinahitaji mengi zaidi.
Sehemu ndogo ya vipengele katika maeneo haya yanayotolewa na mesh ya huduma yanahusiana na vipengele vya jukwaa. Kwa hili namaanisha kazi ambazo:
- Kujitegemea kwa mantiki ya biashara. Njia ambayo histograms za simu hujengwa kati ya Foo na Bar ni huru kabisa ikiwa kwa nini Foo anaita Bar.
- Vigumu kutekeleza kwa usahihi. Katika Linkerd, majaribio tena yameainishwa na kila aina ya vitu vya kupendeza kama vile bajeti za kujaribu tena. (jaribu tena bajeti), kwa kuwa mbinu rahisi ya utekelezaji wa mambo hayo hakika itasababisha kuibuka kwa kile kinachoitwa "avalanche ya maombi" (jaribu tena dhoruba) na matatizo mengine maalum kwa mifumo iliyosambazwa.
- Ufanisi zaidi wakati unatumiwa mara kwa mara. Utaratibu wa TLS una maana ikiwa utatumika kila mahali.
Kwa sababu huduma hizi zinatekelezwa kwenye safu ya wakala (na sio kwenye safu ya programu), matundu ya huduma yanaziweka wazi kwenye jukwaa, sio maombi. Kwa hivyo, haijalishi huduma zimeandikwa kwa lugha gani, zinatumia mfumo gani, ni nani aliziandika na kwa nini. Proksi hufanya kazi zaidi ya maelezo haya yote, na msingi wa kimsingi wa utendakazi huu, ikijumuisha majukumu ya kusanidi, kusasisha, kufanya kazi, kudumisha, n.k., iko katika kiwango cha jukwaa pekee.
Mifano ya uwezo wa matundu ya huduma
Kwa muhtasari, matundu ya huduma sio suluhisho kamili kwa kutegemewa, kuzingatiwa, au usalama. Upeo wa maeneo haya unamaanisha ushiriki wa lazima wa wamiliki wa huduma, timu za Ops / SRE na wadau wengine wa kampuni. Wavu wa huduma hutoa tu "kipande" katika kiwango cha jukwaa kwa kila moja ya maeneo haya.
Kwa nini mesh ya huduma imekuwa maarufu hivi sasa?
Labda unajiuliza hivi sasa: Sawa, ikiwa mesh ya huduma ni nzuri sana, kwa nini hatukuanza kupeleka mamilioni ya proksi kwenye rafu miaka kumi iliyopita?
Kuna jibu la banal kwa swali hili: miaka kumi iliyopita kila mtu alijenga monoliths, na hakuna mtu aliyehitaji mesh ya huduma. Hii ni kweli, lakini kwa maoni yangu, jibu hili linakosa uhakika. Hata miaka kumi iliyopita, dhana ya huduma ndogo kama njia ya kuahidi kuunda mifumo mikubwa ilijadiliwa sana na kutumika katika kampuni kama Twitter, Facebook, Google na Netflix. Mtazamo wa jumla - angalau katika sehemu za tasnia ambayo nimekuwa nikiwasiliana nayo - ilikuwa kwamba huduma ndogo ndio "njia sahihi" ya kuunda mifumo mikubwa, hata ikiwa ilikuwa ngumu sana.
Kwa kweli, ingawa kulikuwa na kampuni zinazonyonya huduma ndogo miaka kumi iliyopita, hazikubandika washirika kila mahali waliweza kuunda mesh ya huduma. Walakini, ukiangalia kwa karibu, walifanya kitu kama hicho: kampuni nyingi hizi ziliamuru matumizi ya maktaba maalum ya ndani kwa mitandao (wakati mwingine huitwa maktaba ya mteja wa mafuta, maktaba ya mteja wa mafuta).
Netflix ilikuwa na Hysterix, Google ilikuwa na Stubby, Twitter ilikuwa na maktaba ya Finagle. Finagle, kwa mfano, imekuwa ya lazima kwa kila huduma mpya kwenye Twitter. Ilishughulikia upande wa mteja na seva wa miunganisho, kuruhusiwa kwa maombi yanayorudiwa, uelekezaji wa ombi linalotumika, kusawazisha upakiaji na kupima mita. Ilitoa safu thabiti ya kutegemewa na kuzingatiwa katika safu nzima ya Twitter, bila kujali huduma ilikuwa inafanya nini. Kwa kweli, ilifanya kazi kwa lugha za JVM tu na ilitokana na muundo wa programu ambao ulipaswa kutumika kwa programu nzima. Walakini, utendakazi wake ulikuwa karibu sawa na ule wa matundu ya huduma. (Kwa kweli, toleo la kwanza la Linkerd lilikuwa tu Finagle iliyofunikwa kwa fomu ya wakala.)
Kwa hivyo, miaka kumi iliyopita hakukuwa na huduma ndogo tu, bali pia maktaba maalum za proto-service-mesh ambazo zilitatua shida zile zile ambazo mesh ya huduma hutatua leo. Walakini, mesh ya huduma yenyewe haikuwepo wakati huo. Ilibidi kuwe na zamu nyingine kabla hajatokea.
Na hapa ndipo jibu la kina liko, lililofichwa katika mabadiliko mengine ambayo yamefanyika katika kipindi cha miaka 10 iliyopita: kumekuwa na kupungua kwa kasi kwa gharama ya kupeleka huduma ndogo. Kampuni zilizotajwa hapo juu ambazo zilitumia huduma ndogo muongo mmoja uliopita-Twitter, Netflix, Facebook, Google-zilikuwa kampuni za kiwango kikubwa na rasilimali kubwa. Hawakuwa na hitaji tu, bali pia uwezo wa kujenga, kupeleka, na kuendesha programu kubwa kulingana na huduma ndogo. Nguvu na bidii ambayo wahandisi wa Twitter wameweka katika kuhama kutoka kwa monolithic hadi mbinu ya huduma ndogo ni ya kushangaza. (Kwa kweli, kama ilivyokuwa ukweli kwamba ilifanya kazi.) Aina hii ya uendeshaji wa miundombinu ilikuwa haiwezekani kwa makampuni madogo.
Tusogee hadi sasa. Leo kuna startups ambapo uwiano wa microservices kwa watengenezaji ni 5: 1 (au hata ), na zaidi ya hayo, wanafanikiwa kukabiliana nao! Ikiwa kuanza kwa watu 5 kuna uwezo wa kufanya huduma ndogo 50 bila shida, basi kitu kilipunguza wazi gharama ya utekelezaji wao.
Huduma ndogo 1500 huko Monzo; kila mstari ni sheria ya mtandao iliyowekwa ambayo inaruhusu trafiki
Kupungua kwa kiasi kikubwa kwa gharama ya huduma ndogo za uendeshaji ni matokeo ya mchakato mmoja: kuongezeka kwa umaarufu wa vyombo ΠΈ waimbaji. Hili ndilo jibu la kina kwa swali la nini kilichangia kuibuka kwa mesh ya huduma. Teknolojia hiyo hiyo ilifanya matundu ya huduma na huduma ndogo kuvutia: Kubernetes na Docker.
Kwa nini? Kweli, Docker hutatua shida moja kubwa - shida ya ufungaji. Kwa kupakia programu na tegemezi zake (zisizo za mtandao) wakati wa kutekelezwa kwenye chombo, Docker hugeuza programu kuwa kitengo kinachoweza kufungika ambacho kinaweza kupangishwa na kuendeshwa popote. Wakati huo huo, hurahisisha kazi sana. lugha nyingi stack: Kwa kuwa kontena ni kitengo cha atomiki cha utekelezaji, haijalishi kilicho ndani, iwe ni programu ya JVM, Node, Go, Python, au Ruby, kwa madhumuni ya kupelekwa na kufanya kazi. Unaendesha tu na ndivyo hivyo.
Kubernetes inachukua kila kitu kwa kiwango kinachofuata. Sasa kwa kuwa kuna rundo la "vitu vinavyoweza kutekelezwa" na mashine nyingi za kuviendesha, kuna hitaji la zana ambayo inaweza kulinganisha yao dhidi ya kila mmoja. Kwa maana pana, unampa Kubernetes vyombo vingi na mashine nyingi, na inafanana nao kwa kila mmoja (bila shaka, hii ni mchakato wa nguvu na unaobadilika mara kwa mara: vyombo vipya vinazunguka mfumo, mashine huanza na kuacha, nk. Kubernetes anazingatia haya yote).
Mara tu Kubernetes inapowekwa, wakati inachukua kupeleka na kuendesha huduma moja sio tofauti sana na gharama ya kupeleka na kuendesha huduma kumi (kwa kweli, ni karibu sawa kwa huduma 100). Ongeza kwenye vyombo hivi kama utaratibu wa upakiaji unaohimiza utekelezaji wa lugha nyingi, na una tani nyingi za programu mpya zinazotekelezwa kama huduma ndogo zilizoandikwa katika lugha nyingi, aina tu ya mazingira ambayo mesh ya huduma inafaa sana.
Kwa hivyo, tunakuja kwa jibu la swali la kwa nini wazo la mesh ya huduma limekuwa maarufu hivi sasa: usawa ambao Kubernetes hutoa kwa huduma inatumika moja kwa moja kwa kazi za uendeshaji zinazokabili mesh ya huduma. Unafunga proksi kwenye makontena, mpe Kubernetes kazi ya kuwabandika inapowezekana, na voila! Kama matokeo, unapata mesh ya huduma, wakati Kubernetes inadhibiti mitambo yote ya uwekaji wake. (Angalau kutoka kwa mtazamo wa jicho la ndege. Bila shaka, kuna mambo mengi ya mchakato huu.)
Kwa muhtasari: sababu mesh ya huduma ikawa maarufu sasa na sio miaka kumi iliyopita ni kwamba Kubernetes na Docker hawakuongezeka sana tu. haja ndani yake, kurahisisha utekelezaji wa programu kama seti za huduma ndogo za lugha nyingi, lakini pia zimepunguzwa sana. gharama kwa ajili ya uendeshaji wake kwa kutoa mbinu za kupeleka na kudumisha mbuga za wakala wa kando.
Kwa nini kuna mazungumzo mengi juu ya matundu ya huduma?
Onyo: Katika sehemu hii, ninatumia kila aina ya dhana, dhana, uzushi na habari za ndani.
Kutafuta "mesh ya huduma" kutaleta rundo la maudhui yaliyorejeshwa, yenye kalori ya chini, miradi isiyo ya kawaida, na kaleidoscope ya upotoshaji inayostahili chumba cha echo. Teknolojia yoyote mpya ya kisasa ina hii, lakini kwa upande wa matundu ya huduma, shida ni kubwa sana. Kwa nini?
Kweli, kwa sehemu ni kosa langu. Nimejitahidi niwezavyo kukuza Linkerd na mesh ya huduma kwa kila fursa, kupitia machapisho mengi ya blogi na nakala kama hii. Lakini mimi si hivyo nguvu. Ili kujibu swali hili kwa kweli, tunahitaji kuzungumza kidogo juu ya hali ya jumla. Na haiwezekani kuzungumza juu yake bila kutaja mradi mmoja: ni matundu ya huduma huria yaliyotengenezwa kwa pamoja na Google, IBM na Lyft.
(Kampuni hizo tatu zina majukumu tofauti sana: Uhusika wa Lyft unaonekana kuwa mdogo kwa jina pekee; wanaandika Envoy lakini hawatumii au wanahusika katika uundaji wa Istio. IBM inahusika katika uundaji wa Istio na inaitumia. Google inatumika sana. inahusika katika ukuzaji wa Istio , lakini kwa kadiri ninavyoweza kusema, haitumii.)
Mradi wa Istio unajulikana kwa mambo mawili. Kwanza, ni juhudi kubwa ya uuzaji ambayo Google, haswa, inaweka katika ukuzaji wake. Ninakadiria kuwa watu wengi wanaofahamu kwa sasa dhana ya matundu ya huduma walijifunza kwanza kuihusu shukrani kwa Istio. Kipengele cha pili ni jinsi Istio ilivyopokelewa vibaya. Katika suala hili, mimi, kwa hakika, ni mtu anayevutiwa, lakini kujaribu kubaki kama lengo iwezekanavyo, bado siwezi kusaidia lakini , sio maalum sana (ingawa sio ya kipekee: systemd inakuja akilini, ...) kwa mradi wa Open Source.
(Kwa mazoezi, Istio inaonekana kuwa na matatizo si tu na utata na UX, lakini pia na utendaji. Kwa mfano, wakati wa uliofanywa na mtu wa tatu, wataalam walipata hali ambazo latency ya mkia wa Istio ilikuwa mara 100 zaidi kuliko ile ya Linkerd, pamoja na hali na ukosefu wa rasilimali, wakati Linkerd iliendelea kufanya kazi kwa mafanikio, na Istio iliacha kabisa kufanya kazi.)
Ukiacha nadharia zangu kuhusu kwa nini hii ilitokea, ninaamini kwamba mvuto wa nje wa wavu wa huduma ni kwa sababu ya kuhusika kwa Google. Yaani, mchanganyiko wa mambo matatu yafuatayo:
- utangazaji wa kupita kiasi wa Istio na Google;
- kukataa kufaa, mtazamo muhimu kuelekea mradi;
- umaarufu wa hivi karibuni wa Kubernetes, kumbukumbu ambayo bado ni mpya.
Kwa pamoja, mambo haya yanaungana na kuwa aina ya mazingira ya ulevi, ya anoxic ambayo uwezo wa uamuzi wa busara unadhoofika, na aina ya ajabu tu inabaki. .
Kwa mtazamo wa Linkerd, hii ni⦠ningeielezea kama baraka mchanganyiko. Ninamaanisha, ni vizuri kwamba mesh ya huduma imeingia kwenye mkondo - ambayo haikuwa hivyo mnamo 2016 wakati Linkerd ilionekana kwa mara ya kwanza na ilikuwa ngumu sana kupata umakini wa watu kwenye mradi huo. Sasa hakuna shida kama hiyo! Lakini habari mbaya ni kwamba hali ya matundu ya huduma ni ya kutatanisha leo hivi kwamba karibu haiwezekani kujua ni miradi gani ambayo ni ya kitengo cha matundu ya huduma (achilia mbali kujua ni ipi bora kwa kesi fulani ya utumiaji). Hii hakika inapata njia ya kila mtu (na kwa hakika katika baadhi ya matukio Istio au mradi mwingine ni bora kuliko Linkerd, kwani mwisho sio suluhisho la ukubwa mmoja).
Kutoka upande wa Linkerd, mkakati wetu umekuwa ni kupuuza kelele, kuendelea kuzingatia kutatua matatizo halisi katika jamii, na kimsingi kusubiri kelele zipungue. Hatimaye kelele zitapungua na tunaweza kuendelea kufanya kazi kwa amani.
Hadi wakati huo, itabidi sote tuwe na subira.
Je, mesh ya huduma itanifaa, mhandisi wa programu wa kawaida?
Hojaji ifuatayo itasaidia kujibu swali hili:
Je, unashughulika pekee na utekelezaji wa mantiki ya biashara? Katika kesi hii, mesh ya huduma haitakuwa na manufaa kwako. Hiyo ni, kwa kweli, unaweza kupendezwa nayo, lakini kwa kweli, mesh ya huduma haipaswi kuathiri moja kwa moja chochote katika mazingira yako. Endelea kufanyia kazi kile unacholipwa.
Je, unadumisha jukwaa katika kampuni inayotumia Kubernetes? Ndiyo, katika kesi hii unahitaji mesh ya huduma (bila shaka, ikiwa hutumii K8s tu kuendesha usindikaji wa monolith au kundi - lakini basi ningependa kuuliza kwa nini unahitaji K8s). Uwezekano mkubwa zaidi, utajikuta katika hali na microservices nyingi zilizoandikwa na watu tofauti. Wote huingiliana na wamefungwa kwenye tangle ya utegemezi wa wakati wa kukimbia, na unahitaji kutafuta njia ya kukabiliana na haya yote. Matumizi ya Kubernetes inakuwezesha kuchagua mesh ya huduma "kwa ajili yako mwenyewe". Ili kufanya hivyo, jitambulishe na uwezo na huduma zao na ujibu swali la ikiwa miradi yoyote inayopatikana inakufaa kabisa (Ninapendekeza kuanza utafiti wako na Linkerd).
Je, unaendesha jukwaa kwa ajili ya kampuni ambayo haitumii Kubernetes lakini inatumia huduma ndogo? Katika kesi hii, mesh ya huduma itakuwa na manufaa kwako, lakini matumizi yake yatakuwa yasiyo ya maana. Bila shaka unaweza kuiga service mesh kwa kupangisha kundi la proksi, lakini faida muhimu ya Kubernetes haswa ni muundo wa upelekaji: kutunza proksi hizi mwenyewe kutahitaji muda, juhudi na gharama zaidi.
Je, unasimamia jukwaa katika kampuni inayofanya kazi na monoliths? Katika kesi hii, labda hauitaji matundu ya huduma. Ikiwa unafanya kazi na monoliths (au hata seti za monoliths) ambazo zimefafanuliwa vizuri na mara chache hubadilisha mifumo ya mwingiliano, basi matundu ya huduma hayana cha kukupa. Kwa hivyo unaweza kuipuuza na kutumaini itatoweka kama ndoto mbaya ...
Hitimisho
Labda, matundu ya huduma bado hayapaswi kuitwa "teknolojia ya hali ya juu zaidi ulimwenguni" - heshima hii mbaya labda ni ya bitcoin au AI. Labda yuko kwenye tano bora. Lakini ukivunja safu za kelele na din, inakuwa wazi kuwa mesh ya huduma huleta faida halisi kwa wale wanaounda programu katika Kubernetes.
Ningependa ujaribu Linkerd - kuisanikisha kwenye nguzo ya Kubernetes (au hata Minikube kwenye kompyuta ndogo) na unaweza kuona mwenyewe ninachozungumza.
Maswali
- Ikiwa nitapuuza mesh ya huduma, itatoweka?
- Lazima nikukatishe tamaa: mesh ya huduma iko nasi kwa muda mrefu.
- Lakini SITAKI kutumia matundu ya huduma!
- Kweli, sio lazima! Soma tu dodoso langu hapo juu ili kuona ikiwa unapaswa kujijulisha na misingi yake.
- Je, si ni ESB/middleware nzuri ya zamani na mchuzi mpya?
- Matundu ya huduma hushughulika na mantiki ya uendeshaji, si ya kimantiki. basi la huduma ya biashara () Kuweka utengano huu husaidia mesh ya huduma kuepuka hatima sawa.
- Je, mesh ya huduma ni tofauti gani na lango la API?
Kuna nakala milioni juu ya mada hii. google tu.
Je, Mjumbe ni matundu ya huduma?
- Hapana, Mjumbe sio mesh ya huduma, ni seva ya wakala. Inaweza kutumika kupanga matundu ya huduma (na mengi zaidi - ni wakala wa madhumuni ya jumla). Lakini peke yake, sio mesh ya huduma.
- Mtandao wa Huduma ya Mesh - ni mesh ya huduma?
- Hapana. Licha ya jina, hii sio mesh ya huduma (unapendaje maajabu ya uuzaji?).
- Je, matundu ya huduma yatasaidia na mfumo wangu tendaji wa asynchronous kulingana na foleni ya ujumbe?
- Hapana, mesh ya huduma haitakusaidia.
- Ni mesh gani ya huduma ninapaswa kutumia?
- , hakuna mwenye akili.
- Nakala hiyo ni mbaya! / Mwandishi - kwenye sabuni!
- Tafadhali shiriki kiungo chake na marafiki zako wote ili waweze kusadikishwa na hili!
Shukrani
Kama unavyoweza kukisia kutoka kwa kichwa, nakala hii iliongozwa na risala nzuri ya Jay Kreps "". Nilikutana na Jay miaka kumi iliyopita nikifanya mahojiano kwenye Linked In na amekuwa msukumo kwangu tangu wakati huo.
Ingawa napenda kujiita "msanidi programu wa Linkard", ukweli ni kwamba mimi ni mtunzaji zaidi wa faili ya README.md katika mradi. Inafanya kazi kwenye Linkerd leo , , watu, na mradi huu haungewezekana bila jumuiya ya ajabu ya wachangiaji na watumiaji.
Na mwishowe, shukrani maalum kwa muundaji wa Linkerd, (primus inter pares), ambaye, pamoja nami miaka mingi iliyopita, tulijikita katika mzozo huu wote na matundu ya huduma.
PS kutoka kwa mtafsiri
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com