Habari Habr! Ninawasilisha kwa mawazo yako tafsiri ya makala "Ndege ya data ya matundu ya huduma dhidi ya ndege ya kudhibiti" mwandishi Matt Klein.

Wakati huu, "nilitaka na kutafsiri" maelezo ya vipengele vyote viwili vya mesh ya huduma, ndege ya data na ndege ya udhibiti. Maelezo haya yalionekana kwangu kuwa ya kueleweka zaidi na ya kuvutia, na muhimu zaidi yakiongoza kwa uelewa wa "Je, ni muhimu hata kidogo?"

Kadiri wazo la "Mesh ya Huduma" likizidi kuwa maarufu zaidi ya miaka miwili iliyopita (Nakala ya asili Oktoba 10, 2017) na idadi ya washiriki katika nafasi hiyo imeongezeka, nimeona ongezeko la machafuko kati ya watu wote. jumuiya ya teknolojia kuhusu jinsi ya kulinganisha na kulinganisha masuluhisho tofauti.

Hali hiyo imefupishwa vyema na safu zifuatazo za tweets nilizoandika mnamo Julai:

Machafuko ya matundu ya huduma #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Mjumbe. Hakuna hata mmoja wao aliye sawa na Istio. Istio ni kitu tofauti kabisa. 1 /

Ya kwanza ni ndege za data tu. Kwao wenyewe hawafanyi chochote. Lazima wawe katika hali ya kufanya kitu zaidi. 2/

Istio ni mfano wa ndege ya udhibiti inayounganisha sehemu pamoja. Hii ni safu nyingine. /mwisho

Twiti zilizotangulia zinataja miradi kadhaa tofauti (Linkerd, NGINX, HAProxy, Envoy, na Istio), lakini muhimu zaidi kutambulisha dhana za jumla za ndege ya data, mesh ya huduma, na ndege ya kudhibiti. Katika chapisho hili, nitachukua hatua nyuma na kuzungumzia ninachomaanisha kwa maneno "ndege ya data" na "ndege ya kudhibiti" kwa kiwango cha juu sana, kisha nitazungumzia jinsi masharti yanavyotumika kwa miradi iliyotajwa kwenye tweets.

Mesh ya huduma ni nini, kweli?

Kielelezo cha 1: Muhtasari wa matundu ya huduma

Kielelezo 1 inaonyesha dhana ya matundu ya huduma katika kiwango chake cha msingi. Kuna makundi manne ya huduma (AD). Kila mfano wa huduma unahusishwa na seva ya proksi ya ndani. Trafiki yote ya mtandao (HTTP, REST, gRPC, Redis, n.k.) kutoka kwa tukio moja la programu hupitishwa kupitia seva mbadala ya ndani hadi kwa makundi yanayofaa ya huduma za nje. Kwa njia hii, mfano wa programu haujui mtandao kwa ujumla na unajua tu wakala wake wa ndani. Kwa kweli, mtandao wa mfumo uliosambazwa uliondolewa kwenye huduma.

Ndege ya data

Katika matundu ya huduma, seva ya proksi iliyo karibu nawe kwa programu hufanya kazi zifuatazo:

• Ugunduzi wa huduma. Je, ni huduma/programu zipi zinapatikana kwa ombi lako?
• Kuangalia afya. Je, matukio ya huduma yanayorejeshwa na ugunduzi wa huduma ni sawa na tayari kukubali trafiki ya mtandao? Hii inaweza kujumuisha zote amilifu (km majibu/afya) na tusi (kwa mfano kutumia hitilafu 3 mfululizo za 5xx kama dalili ya hali mbaya ya huduma) ukaguzi wa afya.
• Kuelekeza. Unapopokea ombi la "/foo" kutoka kwa huduma ya REST, ombi linapaswa kutumwa kwa kundi gani la huduma?
• Kusawazisha mzigo. Mara tu kikundi cha huduma kimechaguliwa wakati wa kuelekeza, ombi linapaswa kutumwa kwa mfano gani wa huduma? Kwa muda gani? Na mipangilio gani ya kuvunja mzunguko? Ikiwa ombi halitafaulu, je, linapaswa kujaribiwa tena?
• Uthibitishaji na idhini. Kwa maombi yanayoingia, je, huduma ya kupiga simu inaweza kutambuliwa/kuidhinishwa kwa njia fiche kwa kutumia mTLS au njia nyingine? Iwapo itatambuliwa/imeidhinishwa, je, inaruhusiwa kupiga utendakazi ulioombwa (mwisho) kwenye huduma au je, jibu ambalo halijaidhinishwa linapaswa kurejeshwa?
• Kuzingatiwa. Takwimu za kina, kumbukumbu/ kumbukumbu, na data ya ufuatiliaji iliyosambazwa inapaswa kutolewa kwa kila ombi ili waendeshaji waweze kuelewa mtiririko wa trafiki uliosambazwa na masuala ya utatuzi yanapojitokeza.

Ndege ya data inawajibika kwa pointi zote za awali kwenye mesh ya huduma. Kwa kweli, wakala wa ndani kwa huduma (sidecar) ni ndege ya data. Kwa maneno mengine, ndege ya data inawajibika kwa utangazaji, usambazaji na ufuatiliaji kwa masharti kila pakiti ya mtandao inayotumwa au kutoka kwa huduma.

Ndege ya kudhibiti

Muhtasari wa mtandao ambao proksi ya ndani hutoa katika ndege ya data ni ya kichawi(?). Walakini, wakala anajuaje juu ya njia ya "/foo" ya huduma B? Je, data ya ugunduzi wa huduma ambayo imejaa maombi ya wakala inawezaje kutumika? Je, vigezo vimesanidiwa vipi kwa kusawazisha mzigo, kuisha kwa muda, kukatika kwa mzunguko, n.k.? Je, unatumaje programu kwa kutumia mbinu ya buluu/kijani au mbinu nzuri ya mpito ya trafiki? Nani husanidi mipangilio ya uthibitishaji na uidhinishaji wa mfumo mzima?

Vitu vyote hapo juu viko chini ya udhibiti wa ndege ya udhibiti wa mesh ya huduma. Ndege ya udhibiti inachukua seti ya proksi zisizo na uraia zilizotengwa na kuzigeuza kuwa mfumo uliosambazwa.

Nadhani sababu inayofanya wanateknolojia wengi kupata dhana tofauti za ndege ya data na ndege ya kudhibiti kuwa ya kutatanisha ni kwa sababu kwa watu wengi ndege ya data inajulikana wakati ndege ya udhibiti ni ya kigeni/haielewi. Tumekuwa tukifanya kazi na vipanga njia vya mtandao na swichi kwa muda mrefu. Tunaelewa kuwa pakiti/maombi yanahitaji kutoka hatua A hadi ya B na kwamba tunaweza kutumia maunzi na programu kufanya hili. Kizazi kipya cha proksi za programu ni matoleo ya kawaida tu ya zana ambazo tumekuwa tukitumia kwa muda mrefu.

Kielelezo 2: Ndege ya kudhibiti binadamu

Hata hivyo, tumekuwa tukitumia ndege za udhibiti kwa muda mrefu, ingawa waendeshaji wengi wa mtandao huenda wasihusishe sehemu hii ya mfumo na sehemu yoyote ya teknolojia. Sababu ni rahisi:
Ndege nyingi za udhibiti zinazotumika leo ni ... sisi.

Cha Kielelezo cha 2 inaonyesha kile ninachokiita "ndege ya kudhibiti binadamu." Katika aina hii ya uwekaji, ambayo bado ni ya kawaida sana, mwendeshaji wa binadamu ambaye labda ana hasira huunda usanidi tuli - unaowezekana kupitia hati - na kuzipeleka kupitia mchakato maalum kwa washirika wote. Kisha seva mbadala huanza kutumia usanidi huu na kuanza kuchakata ndege ya data kwa kutumia mipangilio iliyosasishwa.

Kielelezo cha 3: Ndege ya udhibiti wa matundu ya huduma ya hali ya juu

Cha Kielelezo cha 3 inaonyesha ndege ya udhibiti "iliyopanuliwa" ya mesh ya huduma. Inajumuisha sehemu zifuatazo:

• Mwanadamu: Bado kuna mtu (inatumaini kuwa hana hasira) ambaye anafanya maamuzi ya hali ya juu kuhusu mfumo mzima kwa ujumla.
• Kudhibiti UI ya ndege: Mtu huingiliana na aina fulani ya kiolesura cha mtumiaji ili kudhibiti mfumo. Hii inaweza kuwa lango la wavuti, programu ya laini ya amri (CLI), au kiolesura kingine. Kwa kutumia kiolesura cha mtumiaji, mwendeshaji anaweza kufikia vigezo vya usanidi wa mfumo wa kimataifa kama vile:
  • Udhibiti wa uwekaji, mabadiliko ya rangi ya samawati/kijani na/au taratibu
  • Chaguzi za Uthibitishaji na Uidhinishaji
  • Vipimo vya jedwali la uelekezaji, kwa mfano wakati programu A inapoomba maelezo kuhusu "/foo" kinachotokea
  • Pakia mipangilio ya kusawazisha, kama vile muda, majaribio tena, mipangilio ya kuvunja mzunguko, n.k.
• Mpangaji wa mzigo wa kazi: Huduma zinaendeshwa kwenye miundombinu kupitia aina fulani ya mfumo wa kuratibu/orchestration, kama vile Kubernetes au Nomad. Kipanga ratiba kinawajibika kupakia huduma pamoja na wakala wake wa ndani.
• Ugunduzi wa huduma. Wakati kiratibu kinapoanza na kusimamisha matukio ya huduma, huripoti hali ya afya kwa mfumo wa ugunduzi wa huduma.
• API za usanidi wa proksi ya Sidecar : Wakala wa ndani hutoa hali kutoka kwa vipengee mbalimbali vya mfumo kwa kutumia muundo thabiti bila uingiliaji kati wa waendeshaji. Mfumo mzima, unaojumuisha hali zote za huduma zinazoendeshwa kwa sasa na seva mbadala za ndani, hatimaye hubadilika kuwa mfumo mmoja wa ikolojia. API ya ndege ya data ya Mjumbe ni mfano mmoja wa jinsi hii inavyofanya kazi kwa vitendo.

Kimsingi, madhumuni ya ndege ya udhibiti ni kuweka sera ambayo hatimaye itakubaliwa na ndege ya data. Ndege za udhibiti wa hali ya juu zaidi zitaondoa sehemu zaidi za baadhi ya mifumo kutoka kwa opereta na zinahitaji utendakazi mdogo wa mikono, mradi zitafanya kazi kwa usahihi!...

Ndege ya data na ndege ya kudhibiti. Ndege ya data dhidi ya muhtasari wa ndege ya kudhibiti

• Ndege ya data ya matundu ya huduma: Huathiri kila pakiti/ombi kwenye mfumo. Inawajibika kwa ugunduzi wa maombi/huduma, ukaguzi wa afya, uelekezaji, kusawazisha mizigo, uthibitishaji/uidhinishaji na uangalizi.
• Ndege ya kudhibiti matundu ya huduma: Hutoa sera na usanidi kwa ndege zote za data zinazoendesha ndani ya mtandao wa huduma. Haigusi vifurushi/maombi yoyote kwenye mfumo. Ndege inayodhibiti hugeuza ndege zote za data kuwa mfumo uliosambazwa.

Mazingira ya sasa ya mradi

Baada ya kuelewa maelezo hapo juu, wacha tuangalie hali ya sasa ya mradi wa matundu ya huduma.

• Ndege za data: Linkerd, NGINX, HAProxy, Mjumbe, Traefik
• Kudhibiti ndege: Istio, Nelson, SmartStack

Badala ya kwenda katika uchanganuzi wa kina wa kila moja ya suluhisho hapo juu, nitashughulikia kwa ufupi baadhi ya vidokezo ambavyo naamini vinasababisha machafuko mengi katika mfumo wa ikolojia hivi sasa.

Linkerd ilikuwa mojawapo ya seva za proksi za ndege za kwanza kwa matundu ya huduma mapema mwaka wa 2016 na imefanya kazi nzuri ya kuongeza ufahamu na umakini kwa muundo wa muundo wa matundu ya huduma. Takriban miezi 6 baada ya hapo, Mjumbe alijiunga na Linkerd (ingawa alikuwa na Lyft tangu mwishoni mwa 2015). Linkerd na Mjumbe ni miradi miwili ambayo hutajwa mara nyingi wakati wa kujadili meshes za huduma.

Istio ilitangazwa mnamo Mei 2017. Malengo ya mradi wa Istio yanafanana sana na ndege ya udhibiti iliyopanuliwa iliyoonyeshwa katika Kielelezo cha 3. Mjumbe wa Istio ndiye proksi chaguo-msingi. Kwa hivyo, Istio ni ndege ya kudhibiti, na Mjumbe ni ndege ya data. Kwa muda mfupi, Istio ilizalisha msisimko mkubwa, na ndege nyingine za data zilianza kuunganisha kama nafasi ya Mjumbe (wote Linkerd na NGINX walionyesha ushirikiano na Istio). Ukweli kwamba ndege tofauti za data zinaweza kutumika ndani ya ndege moja ya kudhibiti inamaanisha kuwa ndege ya udhibiti na ndege ya data sio lazima ziunganishwe kwa nguvu. API kama vile API ya ndege ya data ya jumla ya Mjumbe inaweza kuunda daraja kati ya sehemu mbili za mfumo.

Nelson na SmartStack husaidia kuonyesha zaidi utenganisho wa ndege ya udhibiti na ndege ya data. Nelson hutumia Mjumbe kama wakala wake na huunda ndege inayotegemewa ya kudhibiti wavu wa huduma kulingana na rafu ya HashiCorp, i.e. Nomad, nk. SmartStack labda ilikuwa ya kwanza ya wimbi jipya la meshes za huduma. SmartStack huunda ndege ya kudhibiti karibu na HAProxy au NGINX, inayoonyesha uwezo wa kutenganisha ndege ya udhibiti kutoka kwa wavu wa huduma kutoka kwa ndege ya data.

Usanifu wa Microservice na mesh ya huduma unapata tahadhari zaidi na zaidi (sawa!), Na miradi zaidi na zaidi na wachuuzi wanaanza kufanya kazi katika mwelekeo huu. Katika miaka michache ijayo tutaona uvumbuzi mwingi katika ndege ya data na ndege ya kudhibiti, pamoja na mchanganyiko zaidi wa vipengele tofauti. Hatimaye, usanifu wa huduma ndogo unapaswa kuwa wazi zaidi na wa kichawi (?) kwa opereta.
Tunatumahi kuwa na hasira kidogo na kidogo.

Mambo muhimu ya kuchukua

• Mesh ya huduma ina sehemu mbili tofauti: ndege ya data na ndege ya kudhibiti. Vipengele vyote viwili vinahitajika, na bila yao mfumo hautafanya kazi.
• Kila mtu anafahamu ndege ya udhibiti, na kwa wakati huu, ndege ya udhibiti inaweza kuwa wewe!
• Ndege zote za data hushindana katika vipengele, utendakazi, usanidi na upanuzi.
• Ndege zote za udhibiti hushindana katika vipengele, usanidi, upanuzi, na urahisi wa matumizi.
• Ndege moja ya udhibiti inaweza kuwa na vifupisho sahihi na API ili ndege nyingi za data ziweze kutumika.

Chanzo: mapenzi.com