Ang Service Mesh ay isang kilalang pattern ng arkitektura para sa pagsasama ng mga microservice at paglipat sa imprastraktura ng ulap. Ngayon sa mundo ng cloud-container medyo mahirap gawin kung wala ito. Maraming mga open-source service mesh na pagpapatupad ay magagamit na sa merkado, ngunit ang kanilang pag-andar, pagiging maaasahan at seguridad ay hindi palaging sapat, lalo na pagdating sa mga kinakailangan ng malalaking kumpanya sa pananalapi sa buong bansa. Iyon ang dahilan kung bakit kami sa Sbertech ay nagpasya na i-customize ang Service Mesh at gustong pag-usapan kung ano ang cool tungkol sa Service Mesh, kung ano ang hindi masyadong cool, at kung ano ang gagawin namin tungkol dito.
Ang katanyagan ng pattern ng Service Mesh ay lumalaki kasabay ng katanyagan ng mga teknolohiya sa cloud. Ito ay isang nakatuong layer ng imprastraktura na nagpapasimple sa pakikipag-ugnayan sa pagitan ng iba't ibang mga serbisyo ng network. Ang mga modernong cloud application ay binubuo ng daan-daan o kahit libu-libo ng mga naturang serbisyo, bawat isa ay maaaring magkaroon ng libu-libong kopya.
Ang pakikipag-ugnayan sa pagitan at pamamahala ng mga serbisyong ito ay isang mahalagang gawain ng Service Mesh. Sa katunayan, ito ay isang modelo ng network ng maraming mga proxy, pinamamahalaan sa gitna at gumaganap ng isang hanay ng mga kapaki-pakinabang na function.
Sa antas ng proxy (data plane):
- Pagtatalaga at pamamahagi ng mga patakaran sa pagruruta at pagbabalanse ng trapiko
- Pamamahagi ng mga susi, sertipiko, mga token
- Koleksyon ng telemetry, pagbuo ng mga sukatan ng pagsubaybay
- Pagsasama sa imprastraktura ng seguridad at pagsubaybay
Sa antas ng control plane:
- Paglalapat ng mga patakaran sa pagruruta at pagbabalanse ng trapiko
- Pamamahala ng mga rettry at timeout, pag-detect ng mga "patay" na node (circuit breaking), pamamahala sa mga injecting fault at pagtiyak ng service resilience sa pamamagitan ng iba pang mekanismo
- Pagpapatunay/pagpapahintulot ng tawag
- Pagbaba ng mga sukatan (observability)
Ang hanay ng mga user na interesado sa pag-unlad ng teknolohiyang ito ay napakalawak - mula sa maliliit na startup hanggang sa malalaking korporasyon sa Internet, halimbawa, PayPal.
Bakit kailangan ang Service Mesh sa sektor ng korporasyon?
Maraming malinaw na benepisyo sa paggamit ng Service Mesh. Una sa lahat, ito ay simpleng maginhawa para sa mga developer: para sa pagsusulat ng code lumilitaw ang isang platform ng teknolohiya, na makabuluhang pinapasimple ang pagsasama sa imprastraktura ng ulap dahil sa katotohanan na ang layer ng transportasyon ay ganap na nakahiwalay sa lohika ng aplikasyon.
Bilang karagdagan, Pinapasimple ng Service Mesh ang relasyon sa pagitan ng mga supplier at consumer. Ngayon, mas madali para sa mga provider ng API at mga consumer na magkasundo sa mga interface at kontrata nang mag-isa, nang hindi kinasasangkutan ng isang espesyal na intermediary at arbiter ng integration - ang enterprise service bus. Ang diskarte na ito ay makabuluhang nakakaapekto sa dalawang tagapagpahiwatig. Ang bilis ng pagdadala ng bagong functionality sa market (time-to-market) ay tumataas, ngunit sa parehong oras ang gastos ng solusyon ay tumataas, dahil ang pagsasama ay kailangang gawin nang nakapag-iisa. Ang paggamit ng Service Mesh ng mga business functionality development team ay nakakatulong na mapanatili ang balanse dito. Bilang resulta, ang mga provider ng API ay maaaring mag-focus ng eksklusibo sa bahagi ng application ng kanilang serbisyo at i-publish lang ito sa Service Mesh - ang API ay agad na magiging available sa lahat ng mga kliyente, at ang kalidad ng pagsasama ay magiging handa sa produksyon at hindi mangangailangan ng isang solong linya ng karagdagang code.
Ang susunod na kalamangan ay iyon ang developer, gamit ang Service Mesh, ay nakatuon lamang sa pagpapagana ng negosyo β sa produkto kaysa sa teknolohikal na bahagi ng serbisyo nito. Halimbawa, hindi mo na kailangang isipin ang katotohanan na sa isang sitwasyon kung saan ang isang serbisyo ay tinawag sa network, ang isang pagkabigo ng koneksyon ay maaaring mangyari sa isang lugar. Bilang karagdagan, tumutulong ang Service Mesh na balansehin ang trapiko sa pagitan ng mga kopya ng parehong serbisyo: kung "mamatay" ang isa sa mga kopya, ililipat ng system ang lahat ng trapiko sa mga natitirang live na kopya.
Serbisyo Mesh - ito ay isang magandang batayan para sa paglikha ng mga distributed application, na nagtatago mula sa kliyente ng mga detalye ng pagbibigay ng mga tawag sa mga serbisyo nito sa loob at labas. Ang lahat ng mga application na gumagamit ng Service Mesh ay nakahiwalay sa antas ng transportasyon kapwa mula sa network at mula sa isa't isa: walang komunikasyon sa pagitan nila. Sa kasong ito, natatanggap ng developer ang ganap na kontrol sa kanyang mga serbisyo.
Dapat pansinin na Nagiging mas madali ang pag-update ng mga distributed application sa isang service mesh environment. Halimbawa, isang asul/berdeng deployment, kung saan ang dalawang application environment ay available para sa pag-install, ang isa ay hindi na-update at nasa standby mode. Ang pagbabalik sa nakaraang bersyon sa kaganapan ng isang hindi matagumpay na paglabas ay isinasagawa ng isang espesyal na router, ang papel na ginagampanan ng Service Mesh na mahusay na nakayanan. Upang subukan ang bagong bersyon, maaari mong gamitin paglabas ng kanaryo β lumipat sa bagong bersyon 10% lamang ng trapiko o mga kahilingan mula sa isang pilot na grupo ng mga kliyente. Ang pangunahing trapiko ay napupunta sa lumang bersyon, walang masira.
Rin Binibigyan kami ng Service Mesh ng real-time na kontrol sa SLA. Hindi papayagan ng distributed proxy system na mabigo ang serbisyo kapag ang isa sa mga kliyente ay lumampas sa quota na itinalaga dito. Kung limitado ang API throughput, walang sinuman ang makakapag-overwhelm dito ng malaking bilang ng mga transaksyon: nakatayo ang Service Mesh sa harap ng serbisyo at hindi pinapayagan ang hindi kinakailangang trapiko. Lalaban lang ito sa layer ng integration, at ang mga serbisyo mismo ay patuloy na gagana nang hindi ito napapansin.
Kung nais ng isang kumpanya na bawasan ang mga gastos para sa pagbuo ng mga solusyon sa pagsasama, tumutulong din ang Service Mesh: Maaari kang lumipat sa open-source na bersyon nito mula sa mga komersyal na produkto. Ang aming Enterprise Service Mesh ay batay sa open-source na bersyon ng Service Mesh.
Isa pang kalamangan - pagkakaroon ng isang ganap na hanay ng mga serbisyo sa pagsasama. Dahil ang lahat ng integration ay binuo sa pamamagitan ng middleware na ito, maaari naming pamahalaan ang lahat ng integration traffic at mga koneksyon sa pagitan ng mga application na bumubuo sa business core ng kumpanya. Ito ay napaka komportable.
At sa wakas Hinihikayat ng Service Mesh ang isang kumpanya na lumipat sa isang dynamic na imprastraktura. Ngayon marami ang naghahanap patungo sa containerization. Ang pagputol ng isang monolith sa mga microservice, ang pagpapatupad ng lahat ng ito nang maganda - ang paksa ay tumataas. Ngunit kapag sinubukan mong ilipat ang isang system na nasa produksyon sa loob ng maraming taon sa isang bagong platform, makakaharap ka kaagad ng ilang mga problema: ang pagtulak ng lahat ng ito sa mga lalagyan at pag-deploy nito sa platform ay hindi madali. At ang pagpapatupad, pag-synchronize at pakikipag-ugnayan ng mga ipinamamahaging bahagi na ito ay isa pang napakakomplikadong paksa. Paano sila makikipag-usap sa isa't isa? Magkakaroon ba ng mga cascading failures? Binibigyang-daan ka ng Service Mesh na malutas ang ilan sa mga problemang ito at mapadali ang paglipat mula sa lumang arkitektura patungo sa bago dahil sa katotohanan na maaari mong kalimutan ang tungkol sa lohika ng palitan ng network.
Bakit mo kailangan ang pag-customize ng Service Mesh?
Sa aming kumpanya, daan-daang mga system at module ang magkakasamang nabubuhay, at ang runtime ay napaka-load. Kaya ang isang simpleng pattern ng isang sistema na tumatawag sa isa pa at makatanggap ng tugon ay hindi sapat, dahil sa produksyon ay gusto natin ng higit pa. Ano pa ang kailangan mo mula sa isang enterprise service mesh?
Serbisyo sa pagproseso ng kaganapan
Isipin natin na kailangan nating gumawa ng real-time na pagpoproseso ng kaganapan - isang system na sinusuri ang mga aksyon ng kliyente sa real time at maaaring agad na gawin siyang isang nauugnay na alok. Upang ipatupad ang katulad na pag-andar, gamitin pattern ng arkitektura na tinatawag na event-driven architecture (EDA). Wala sa mga kasalukuyang Service Meshes ang katutubong sumusuporta sa gayong mga pattern, ngunit ito ay napakahalaga, lalo na para sa isang bangko!
Medyo kakaiba na ang Remote Procedure Call (RPC) ay sinusuportahan ng lahat ng bersyon ng Service Mesh, ngunit hindi sila friendly sa EDA. Dahil ang Service Mesh ay isang uri ng modernong distributed integration, at ang EDA ay isang napaka-kaugnay na pattern ng arkitektura na nagbibigay-daan sa iyong gumawa ng mga natatanging bagay sa mga tuntunin ng karanasan ng customer.
Dapat lutasin ng aming Enterprise Service Mesh ang problemang ito. Bilang karagdagan, gusto naming makita dito ang pagpapatupad ng garantisadong paghahatid, streaming at kumplikadong pagproseso ng kaganapan gamit ang iba't ibang mga filter at template.
Serbisyo sa paglilipat ng file
Bilang karagdagan sa EDA, mainam na makapaglipat ng mga file: sa sukat ng Enterprise, kadalasan ay posible lamang ang pagsasama ng file. Sa partikular, ginagamit ang pattern ng arkitektura ng ETL (Extract, Transform, Load). Sa loob nito, bilang isang panuntunan, ang lahat ay nagpapalitan ng mga file nang eksklusibo: ang malaking data ay ginagamit, na hindi praktikal na itulak sa magkahiwalay na mga kahilingan. Ang kakayahang katutubong suportahan ang mga paglilipat ng file sa Enterprise Service Mesh ay nagbibigay sa iyo ng flexibility na kailangan ng iyong negosyo.
Serbisyo ng orkestra
Ang malalaking organisasyon ay halos palaging may iba't ibang team na gumagawa ng iba't ibang produkto. Halimbawa, sa isang bangko, ang ilang mga koponan ay nagtatrabaho sa mga deposito, habang ang iba ay nagtatrabaho sa mga produkto ng pautang, at medyo marami ang mga ganitong kaso. Iba't ibang tao ito, iba't ibang team na gumagawa ng kanilang mga produkto, bumuo ng kanilang mga API at nagbibigay ng mga ito sa iba. At napakadalas ay may pangangailangang buuin ang mga serbisyong ito, pati na rin ipatupad ang kumplikadong lohika para sa sunud-sunod na pagtawag sa isang hanay ng mga API. Upang malutas ang problemang ito, kailangan mo ng solusyon sa integration layer na magpapasimple sa lahat ng composite logic na ito (pagtawag ng ilang API, naglalarawan sa ruta ng kahilingan, atbp.). Ito ang serbisyo ng orkestra sa Enterprise Service Mesh.
AI at ML
Kapag nakikipag-usap ang mga microservice sa pamamagitan ng iisang layer ng integration, natural na alam ng Service Mesh ang lahat tungkol sa mga tawag ng bawat serbisyo. Kinokolekta namin ang telemetry: sino ang tumawag kung kanino, kailan, gaano katagal, gaano karaming beses, at iba pa. Kapag mayroong daan-daang libo ng mga serbisyong ito, at bilyun-bilyong mga tawag, ang lahat ng ito ay nag-iipon at bumubuo ng Big Data. Maaaring masuri ang data na ito gamit ang AI, machine learning, atbp., at pagkatapos ay maaaring gawin ang ilang kapaki-pakinabang na bagay batay sa mga resulta ng pagsusuri. Angkop na hindi bababa sa bahagyang ibigay ang kontrol ng lahat ng trapiko sa network na ito at mga tawag sa aplikasyon na isinama sa Service Mesh sa artificial intelligence.
Serbisyo ng API Gateway
Karaniwan, ang isang Service Mesh ay may mga proxy at serbisyo na nakikipag-usap sa isa't isa sa loob ng isang pinagkakatiwalaang perimeter. Ngunit mayroon ding mga panlabas na katapat. Ang mga kinakailangan para sa mga API na nakalantad sa grupong ito ng mga consumer ay mas malala. Hinahati namin ang gawaing ito sa dalawang pangunahing bahagi.
- katiwasayan. Mga isyung nauugnay sa ddos, kahinaan ng mga protocol, application, operating system, at iba pa.
- Scale. Kapag ang bilang ng mga API na kailangang ihatid sa mga kliyente ay umabot sa libu-libo o kahit daan-daang libo, may pangangailangan para sa ilang uri ng tool sa pamamahala para sa hanay ng mga API na ito. Kailangan mong patuloy na subaybayan ang API: kung sila ay gumagana o hindi, kung ano ang kanilang katayuan, kung ano ang daloy ng trapiko, kung ano ang mga istatistika, atbp. Dapat pangasiwaan ng API gateway ang gawaing ito habang pinapamahalaan at secure ang buong proseso. Salamat sa bahaging ito, natututo ang Enterprise Service Mesh na madaling mag-publish ng parehong panloob at panlabas na mga API.
Serbisyo ng suporta para sa mga partikular na protocol at mga format ng data (AS gateway)
Sa kasalukuyan, karamihan sa mga solusyon sa Service Mesh ay maaaring gumana nang native lamang sa trapiko ng HTTP at HTTP2 o sa isang pinababang mode sa antas ng TCP/IP. Ang Enterprise Service Mesh ay umuusbong kasama ng maraming iba pang napaka-espesipikong mga protocol sa paglilipat ng data. Ang ilang mga sistema ay maaaring gumamit ng mga broker ng mensahe, ang iba ay isinama sa antas ng database. Kung ang kumpanya ay may SAP, maaari rin itong gumamit ng sarili nitong sistema ng pagsasama. Bukod dito, gumagana ang lahat ng ito at mahalagang bahagi ng negosyo.
Hindi mo lang masasabing: "Iwanan natin ang legacy at gumawa ng mga bagong system na maaaring gumamit ng Service Mesh." Para ikonekta ang lahat ng lumang system sa mga bago (sa isang microservice architecture), ang mga system na maaaring gumamit ng Service Mesh ay mangangailangan ng ilang uri ng adapter, intermediary, gateway. Sumang-ayon, maganda kung ito ay dumating sa isang kahon kasama ng serbisyo. Maaaring suportahan ng AC gateway ang anumang opsyon sa pagsasama. Isipin mo lang, i-install mo lang ang Enterprise Service Mesh at handa na itong makipag-ugnayan sa lahat ng mga protocol na kailangan mo. Ang diskarte na ito ay napakahalaga para sa amin.
Ito ay halos kung paano namin isipin ang corporate na bersyon ng Service Mesh (Enterprise Service Mesh). Ang inilarawang pag-customize ay nilulutas ang karamihan sa mga problemang lumalabas kapag sinusubukang gumamit ng mga handa na open-source na bersyon ng integration platform. Ipinakilala ilang taon pa lang ang nakalipas, patuloy na umuunlad ang arkitektura ng Service Mesh, at nasasabik kaming makapag-ambag sa pag-unlad nito. Umaasa kami na ang aming karanasan ay magiging kapaki-pakinabang sa iyo.
Pinagmulan: www.habr.com