Kwenye wavuti (mesh ya huduma), na hii hapa ni nyingine. Hooray! Lakini kwa nini? Halafu, ninataka kusema maoni yangu kwamba meshes za huduma zingekuwa bora zaidi miaka 10 iliyopita, kabla ya ujio wa majukwaa ya kontena kama vile Docker na Kubernetes. Sisemi kwamba maoni yangu ni bora au mbaya zaidi kuliko wengine, lakini kwa kuwa meshes za huduma ni wanyama ngumu sana, maoni mengi yatasaidia kuelewa vizuri zaidi.
Nitazungumza juu ya jukwaa la dotCloud, ambalo lilijengwa kwa huduma ndogo zaidi ya mia moja na kusaidia maelfu ya programu kwenye vyombo. Nitaeleza changamoto tulizokumbana nazo katika kuitengeneza na kuizindua, na jinsi meshes za huduma zinaweza (au zisingeweza) kusaidia.
historia ya dotcloud
Tayari nimeandika juu ya historia ya dotCloud na uchaguzi wa usanifu wa jukwaa hili, lakini sijazungumza sana kuhusu safu ya mtandao. Ikiwa hutaki kusoma kuhusu dotCloud, hapa ndio muktadha wake: ni PaaS jukwaa-kama-huduma ambayo inaruhusu wateja kuendesha anuwai ya programu (Java, PHP, Python...), kwa msaada wa anuwai ya huduma za data ( MongoDB, MySQL, Redis...) na mtiririko wa kazi kama Heroku: unapakia msimbo wako kwenye jukwaa, huunda picha za kontena na kuzitumia.
Nitakuambia jinsi trafiki ilitumwa kwenye jukwaa la dotCloud. Sio kwa sababu ilikuwa nzuri sana (ingawa mfumo ulifanya kazi vizuri kwa wakati wake!), lakini kimsingi kwa sababu kwa msaada wa zana za kisasa, muundo kama huo unaweza kutekelezwa kwa muda mfupi na timu ya kawaida ikiwa wanahitaji njia ya kuelekeza. trafiki kati ya rundo la huduma ndogo au rundo la programu. Kwa hivyo, unaweza kulinganisha chaguzi: nini kinatokea ikiwa unakuza kila kitu mwenyewe au kutumia mesh ya huduma iliyopo. Chaguo la kawaida: fanya yako mwenyewe au ununue.
Uelekezaji wa trafiki kwa programu zilizopangishwa
Programu kwenye dotCloud zinaweza kufichua ncha za HTTP na TCP.
Miisho ya HTTP imeongezwa kwa nguvu kwenye usanidi wa nguzo ya kusawazisha mzigo . Hii ni sawa na rasilimali zinafanya leo katika Kubernetes na kusawazisha mzigo kama .
Wateja huunganisha kwenye sehemu za mwisho za HTTP kupitia vikoa vinavyofaa, mradi tu alama za jina la kikoa kwa visawazishi vya dotCloud vya upakiaji. Hakuna maalum.
Sehemu za mwisho za TCP inayohusishwa na nambari ya bandari, ambayo hupitishwa kwa kontena zote kwenye rafu hiyo kupitia vigeu vya mazingira.
Wateja wanaweza kuunganisha kwenye vituo vya mwisho vya TCP kwa kutumia jina la mpangishi lifaalo (kitu kama gateway-X.dotcloud.com) na nambari ya mlango.
Jina hili la mpangishaji linatatua kwa nguzo ya seva ya "nats" (haihusiani na ) ambayo itaelekeza miunganisho inayoingia ya TCP kwa kontena sahihi (au, katika kesi ya huduma zilizosawazishwa, kwa vyombo sahihi).
Ikiwa unaifahamu Kubernetes, hii labda itakukumbusha huduma .
Hakukuwa na huduma sawa kwenye jukwaa la dotCloud : kwa urahisi, ufikiaji wa huduma ulifanyika kwa njia ile ile kutoka ndani na nje ya jukwaa.
Kila kitu kilipangwa kwa urahisi kabisa: utekelezaji wa asili wa mitandao ya uelekezaji ya HTTP na TCP labda ilikuwa mistari mia chache tu ya Python. Rahisi (ningesema, naive) algorithms ambazo zimesafishwa na ukuaji wa jukwaa na kuibuka kwa mahitaji ya ziada.
Urekebishaji wa kina wa msimbo uliopo haukuhitajika. Hasa, inaweza kutumia moja kwa moja anwani iliyopatikana kupitia anuwai za mazingira.
Je, hii ni tofauti gani na matundu ya huduma ya kisasa?
Kikomo kujulikana. Hatukuwa na vipimo vyovyote vya mesh ya uelekezaji ya TCP hata kidogo. Linapokuja suala la uelekezaji wa HTTP, matoleo ya hivi majuzi zaidi yana vipimo vya kina vya HTTP vilivyo na misimbo ya hitilafu na nyakati za majibu, lakini meshi za huduma za kisasa huenda mbali zaidi, zikitoa ushirikiano na mifumo ya ukusanyaji wa vipimo kama vile Prometheus, kwa mfano.
Kuonekana ni muhimu sio tu kutoka kwa mtazamo wa uendeshaji (kusaidia kutatua matatizo), lakini pia wakati vipengele vipya vinatolewa. Kuzungumza juu ya salama ΠΈ .
Ufanisi wa njia pia ni mdogo. Katika matundu ya uelekezaji ya dotCloud, trafiki yote ilibidi kupita kwenye kundi la nodi maalum za uelekezaji. Hii ilimaanisha uwezekano wa kuvuka mipaka mingi ya AZ (eneo la upatikanaji) na ongezeko kubwa la muda wa kusubiri. Nakumbuka msimbo wa utatuzi ambao ulifanya zaidi ya hoja mia moja za SQL kwa kila ukurasa na kufungua muunganisho mpya kwa seva ya SQL kwa kila hoja. Inapoendeshwa ndani, ukurasa hupakia papo hapo, lakini kwenye dotCloud inachukua sekunde chache kupakia kwa sababu kila muunganisho wa TCP (na swali linalofuata la SQL) huchukua makumi ya milisekunde. Katika kesi hii, miunganisho inayoendelea ilisuluhisha shida.
Meshes ya kisasa ya huduma ni bora katika kukabiliana na matatizo hayo. Kwanza kabisa, wanaangalia kuwa viunganisho vimepitishwa katika chanzo. Mtiririko wa kimantiki ni sawa: ΠΊΠ»ΠΈΠ΅Π½Ρ β ΠΌΠ΅Ρ β ΡΠ΅ΡΠ²ΠΈΡ, lakini sasa mesh inafanya kazi ndani na sio kwenye nodi za mbali, kwa hivyo unganisho ΠΊΠ»ΠΈΠ΅Π½Ρ β ΠΌΠ΅Ρ ni ya ndani na ya haraka sana (microseconds badala ya milliseconds).
Matundu ya kisasa ya huduma pia hutekeleza algoriti nadhifu za kusawazisha upakiaji. Kwa kufuatilia afya ya backends, wanaweza kutuma trafiki zaidi kwa backends kasi, na kusababisha utendaji bora kwa ujumla.
usalama pia ni bora zaidi. Wavu wa uelekezaji wa dotCloud ulikuwa ukifanya kazi kabisa kwenye EC2 Classic na haukusimba trafiki kwa njia fiche (chini ya kudhaniwa kuwa ikiwa mtu aliweza kuweka kinusi kwenye trafiki ya mtandao wa EC2, tayari uko kwenye matatizo makubwa). Wavu za kisasa za huduma hulinda kwa uwazi trafiki yetu yote, kwa mfano, kwa uthibitishaji wa pande zote wa TLS na usimbaji fiche unaofuata.
Uelekezaji wa trafiki kwa huduma za jukwaa
Sawa, tumejadili trafiki kati ya programu, lakini vipi kuhusu jukwaa la dotCloud yenyewe?
Jukwaa lenyewe lilikuwa na huduma ndogo kama mia zinazohusika na kazi mbalimbali. Baadhi walikuwa wakikubali maombi kutoka kwa wengine, na wengine walikuwa wafanyikazi wa chinichini ambao waliunganishwa na huduma zingine lakini hawakukubali miunganisho wenyewe. Kwa vyovyote vile, kila huduma lazima ijue miisho ya anwani inazohitaji kuunganisha.
Huduma nyingi za kiwango cha juu zinaweza kutumia mesh ya uelekezaji iliyoelezwa hapo juu. Kwa kweli, huduma nyingi kati ya zaidi ya XNUMX za dotCloud zimetumwa kama programu za kawaida kwenye jukwaa la dotCloud lenyewe. Lakini idadi ndogo ya huduma za kiwango cha chini (haswa, zile zinazotekeleza mesh hii ya uelekezaji) zilihitaji kitu rahisi zaidi, na utegemezi mdogo (kwa sababu hawakuweza kutegemea wenyewe kufanya kazi - shida nzuri ya kuku na yai).
Huduma hizi za kiwango cha chini, muhimu zilitumwa kwa kuendesha vyombo moja kwa moja kwenye nodi chache muhimu. Wakati huo huo, huduma za kawaida za jukwaa hazikuhusishwa: kiunganishi, kipanga ratiba, na mkimbiaji. Ikiwa ungependa kulinganisha na mifumo ya kisasa ya kontena, ni kama kuzindua ndege ya kudhibiti docker run moja kwa moja kwenye nodi, badala ya kukabidhi kazi hiyo kwa Kubernetes. Ni sawa katika dhana , ambayo hutumia au wakati wa kuanzisha nguzo ya kujitegemea.
Huduma hizi zilifichuliwa kwa njia rahisi na chafu: faili ya YAML iliorodhesha majina na anwani zao; na kila mteja alilazimika kuchukua nakala ya faili hii ya YAML kwa ajili ya kupelekwa.
Kwa upande mmoja, hii inategemewa sana, kwa sababu haihitaji usaidizi wa ufunguo wa nje/duka la thamani, kama vile Zookeeper (kumbuka, etcd au Consul haikuwepo wakati huo). Kwa upande mwingine, ilifanya iwe vigumu kuhamisha huduma. Kila mara hoja ilipofanywa, wateja wote walilazimika kupata faili iliyosasishwa ya YAML (na uwezekano wa kupakia upya). Sio vizuri sana!
Baadaye, tulianza kutekeleza mpango mpya, ambapo kila mteja aliunganishwa na seva ya wakala ya ndani. Badala ya anwani na bandari, inahitaji tu kujua nambari ya bandari ya huduma, na kuunganisha kupitia localhost. Wakala wa ndani hushughulikia muunganisho huu na kuupeleka kwa seva halisi. Sasa wakati wa kuhamisha backend kwa mashine nyingine au kuongeza, badala ya kusasisha wateja wote, ni washirika hawa wote wa ndani tu wanaohitaji kusasishwa; na kuwasha upya hakuhitajiki tena.
(Ilipangwa pia kujumuisha trafiki katika miunganisho ya TLS na kusakinisha seva nyingine ya proksi kwenye upande wa kupokea, na pia kuangalia vyeti vya TLS bila ushiriki wa huduma ya upokeaji, ambayo imesanidiwa kukubali miunganisho kwenye tu. localhost. Zaidi juu ya hilo baadaye).
Hii inafanana sana na kutoka Airbnb, lakini tofauti kubwa ni kwamba SmartStack inatekelezwa na kupelekwa kwa uzalishaji, wakati mfumo wa uelekezaji wa ndani wa dotCloud uliwekwa kwenye sanduku wakati dotCloud ilipogeuzwa kuwa Docker.
Binafsi ninachukulia SmartStack kuwa mmoja wa watangulizi wa mifumo kama Istio, Linkerd na Consul Connect kwa sababu zote zinafuata muundo sawa:
- Endesha proksi kwenye kila nodi.
- Wateja huunganisha kwenye seva mbadala.
- Ndege inayodhibiti husasisha usanidi wa seva mbadala wakati nakala za nyuma zinabadilika.
- β¦ Faida!
Utekelezaji wa Mesh ya Huduma ya Kisasa
Ikiwa tunahitaji kutekeleza gridi sawa leo, tunaweza kutumia kanuni zinazofanana. Kwa mfano, weka ukanda wa ndani wa DNS kwa kupanga majina ya huduma kwa anwani zilizo angani 127.0.0.0/8. Kisha endesha HAProxy kwenye kila nodi ya nguzo, ukikubali miunganisho kwenye kila anwani ya huduma (kwenye subnet hiyo 127.0.0.0/8) na kuelekeza/kusawazisha mzigo kwenye sehemu za nyuma zinazofaa. Usanidi wa HAProxy unaweza kudhibitiwa , hukuruhusu kuhifadhi maelezo ya nyuma katika etcd au Consul na kusukuma kiotomatiki usanidi uliosasishwa kwa HAProxy inapohitajika.
Hivi ndivyo Istio inavyofanya kazi! Lakini na tofauti kadhaa:
- Matumizi badala ya HAProxy.
- Huhifadhi usanidi wa mazingira nyuma kupitia Kubernetes API badala ya etcd au Consul.
- Huduma zimegawiwa anwani kwenye mtandao mdogo wa ndani (anwani za Kubernetes ClusterIP) badala ya 127.0.0.0/8.
- Ina sehemu ya ziada (Citadel) ya kuongeza uthibitishaji wa pamoja wa TLS kati ya mteja na seva.
- Inaauni vipengele vipya kama vile kuvunja mzunguko, ufuatiliaji uliosambazwa, uwekaji wa canary, n.k.
Hebu tuangalie kwa haraka baadhi ya tofauti hizo.
Wakala wa Mjumbe
Wakala wa Mjumbe iliandikwa na Lyft [mshindani wa Uber katika soko la teksi - takriban. kwa.]. Ni sawa kwa njia nyingi na wakala wengine (k.m. HAProxy, Nginx, Traefik...), lakini Lyft waliandika vyao kwa sababu walihitaji vipengele ambavyo washirika wengine hawana na ilionekana busara zaidi kutengeneza mpya badala ya kupanua. iliyopo.
Mjumbe anaweza kutumika peke yake. Ikiwa nina huduma mahususi ambayo inahitaji kuunganishwa kwa huduma zingine, ninaweza kuiweka ili kuunganishwa na Mjumbe na kisha kusanidi kwa nguvu na kusanidi upya Mjumbe na eneo la huduma zingine, huku nikipata nyongeza nyingi nzuri kama mwonekano. Badala ya maktaba maalum ya mteja au kuingiza msimbo wa kufuatilia simu, tunatuma trafiki kwa Mjumbe, na inatukusanyia vipimo.
Lakini Mjumbe pia anaweza kufanya kazi kama ndege ya data (ndege ya data) kwa matundu ya huduma. Hii inamaanisha kuwa sasa kwa matundu haya ya huduma, Mjumbe amesanidiwa ndege ya kudhibiti (ndege ya kudhibiti).
Kudhibiti ndege
Katika ndege ya udhibiti, Istio inategemea API ya Kubernetes. Hii sio tofauti sana na kutumia confd, ambayo inategemea etcd au Consul kutafuta seti ya funguo kwenye hifadhi ya data. Istio inachunguza seti ya rasilimali za Kubernetes kupitia Kubernetes API.
Kati ya hii na kisha: Mimi binafsi nimeona hii kuwa muhimu ambayo inasomeka:
Seva ya Kubernetes API ni "seva ya kijinga" ambayo hutoa hifadhi, matoleo, uthibitishaji, kusasisha, na semantiki za rasilimali za API.
Istio imeundwa kufanya kazi na Kubernetes; na ikiwa unataka kuitumia nje ya Kubernetes, basi unahitaji kuanza mfano wa seva ya Kubernetes API (na huduma ya msaidizi wa etcd).
Anwani za Huduma
Istio inategemea anwani za ClusterIP ambazo Kubernetes inatenga, kwa hivyo huduma za Istio hupata anwani ya ndani (sio katika safu. 127.0.0.0/8).
Trafiki kwa anwani ya ClusterIP kwa huduma mahususi katika kundi la Kubernetes bila Istio inazuiliwa na proksi ya kube na kutumwa hadi mwisho wa seva mbadala. Iwapo ungependa maelezo ya kiufundi, kube-proksi huweka sheria za iptables (au visawazishi vya upakiaji vya IPVS, kulingana na jinsi imesanidiwa) ili kuandika upya anwani za IP lengwa za miunganisho kwenda kwa anwani ya ClusterIP.
Istio inaposakinishwa kwenye kundi la Kubernetes, hakuna kinachobadilika hadi iwezeshwe kwa uwazi kwa mtumiaji fulani, au hata nafasi nzima ya majina, kwa kuanzisha kontena. sidecar kwa maganda maalum. Chombo hiki kitaanza tukio la Mjumbe na kusanidi seti ya sheria za iptables ili kuzuia trafiki inayoenda kwa huduma zingine na kuelekeza trafiki hiyo kwa Mjumbe.
Inapounganishwa na Kubernetes DNS, hii ina maana kwamba msimbo wetu unaweza kuunganisha kwa jina la huduma, na kila kitu "hufanya kazi tu". Kwa maneno mengine, nambari zetu hutoa maswali kama vile http://api/v1/users/4242basi api kutatua ombi 10.97.105.48, sheria za iptables hukatiza miunganisho kutoka 10.97.105.48 na kuzielekeza kwenye seva mbadala ya karibu ya Mjumbe, ambayo itatuma ombi kwa mandharinyuma halisi ya API. Phew!
Vifungo vya ziada
Istio pia hutoa usimbaji fiche kutoka mwisho hadi mwisho na uthibitishaji kupitia mTLS (TLS ya pande zote). Sehemu iliita Ngome.
Pia kuna sehemu mixer, ambayo Mjumbe anaweza kuomba kila mmoja ombi la kufanya uamuzi maalum kuhusu ombi hilo kulingana na mambo mbalimbali kama vile vichwa, upakiaji wa mandharinyuma, n.k... (usijali: kuna zana nyingi za kufanya Kichanganyaji kifanye kazi, na hata ikiharibika, Mjumbe ataendelea kufanya kazi. kama wakala).
Na, bila shaka, tulitaja mwonekano: Mjumbe hukusanya kiasi kikubwa cha vipimo huku akitoa ufuatiliaji uliosambazwa. Katika usanifu wa huduma ndogo, ikiwa ombi moja la API linahitaji kupitia huduma ndogo A, B, C, na D, basi baada ya kuingia, ufuatiliaji uliosambazwa utaongeza kitambulisho cha kipekee kwa ombi na kuhifadhi kitambulisho hiki kupitia maombi madogo kwa huduma hizi zote ndogo, ikiruhusu. unasa simu zote zinazohusiana, ucheleweshaji wao, nk.
Kuendeleza au kununua
Istio ina sifa ya kuwa mfumo mgumu. Kinyume chake, kujenga mesh ya uelekezaji ambayo nilielezea mwanzoni mwa chapisho hili ni rahisi na zana zilizopo. Kwa hivyo, inaeleweka kuunda matundu yako ya huduma badala yake?
Ikiwa tuna mahitaji ya kawaida (hatuhitaji kujulikana, kivunja mzunguko na hila nyingine), basi mawazo huja kuhusu kuendeleza chombo chetu wenyewe. Lakini ikiwa tunatumia Kubernetes, huenda hata isihitajike kwa sababu Kubernetes tayari inatoa zana za msingi za ugunduzi wa huduma na kusawazisha upakiaji.
Lakini ikiwa tuna mahitaji ya juu, basi "kununua" mesh ya huduma inaonekana kuwa chaguo bora zaidi. (Huu sio "ununuzi" kila wakati kwa kuwa Istio ni chanzo huria, lakini bado tunahitaji kuwekeza muda wa uhandisi ili kuelewa, kusambaza na kudhibiti.)
Nini cha kuchagua: Istio, Linkerd au Consul Connect?
Kufikia sasa tumezungumza tu kuhusu Istio, lakini sio matundu ya huduma pekee. Mbadala maarufu ni , lakini kuna zaidi .
Nini cha kuchagua?
Kuwa mkweli, sijui. Kwa sasa sijioni kuwa na uwezo wa kutosha kujibu swali hili. Kuna wachache kwa kulinganisha zana hizi na hata .
Njia moja ya kuahidi ni kutumia zana kama . Hutumia safu ya uondoaji kurahisisha na kuunganisha API zinazotolewa na meshes za huduma. Badala ya kujifunza API maalum (na, kwa maoni yangu, ngumu) ya meshes anuwai za huduma, tunaweza kutumia muundo rahisi wa SuperGloo - na kubadili kwa urahisi kutoka kwa moja hadi nyingine, kana kwamba tunayo umbizo la usanidi wa kati linaloelezea miingiliano ya HTTP na viunga vya nyuma. yenye uwezo wa kutengeneza usanidi halisi wa Nginx, HAProxy, Traefik, Apache...
Nilicheza karibu na Istio na SuperGloo kidogo, na katika makala inayofuata nataka kuonyesha jinsi ya kuongeza Istio au Linkerd kwenye nguzo iliyopo kwa kutumia SuperGloo, na jinsi ya mwisho itafanya kazi yake, yaani, inakuwezesha kubadili kutoka. matundu ya huduma moja hadi nyingine bila kuandika upya usanidi.
Chanzo: mapenzi.com