A Intanit (ragon sabis), kuma ga wani. Hooray! Amma me ya sa? Bayan haka, ina so in bayyana ra'ayi na cewa layin sabis ɗin zai kasance mafi kyau shekaru 10 da suka gabata, kafin zuwan dandamalin kwantena kamar Docker da Kubernetes. Ba na cewa ra'ayi na ya fi wasu kyau ko mafi muni ba, amma tun da yake layin sabis ɗin dabbobi ne masu rikitarwa, ra'ayoyi da yawa zasu taimaka wajen fahimtar su.
Zan yi magana game da dandalin dotCloud, wanda aka gina akan fiye da ɗari microservices kuma yana tallafawa dubban aikace-aikace a cikin kwantena. Zan bayyana ƙalubalen da muka fuskanta wajen haɓakawa da ƙaddamar da shi, da kuma yadda meshes ɗin sabis zai iya taimakawa (ko a'a).
dotcloud tarihi
Na riga na rubuta game da tarihin dotCloud da zaɓin gine-gine don wannan dandamali, amma ban yi magana da yawa game da layin cibiyar sadarwa ba. Idan baka son karantawa game da dotCloud, ga ainihin abin da ke ciki: yana da tsarin PaaS-as-a-sabis wanda ke ba abokan ciniki damar gudanar da aikace-aikace masu yawa (Java, PHP, Python ...), tare da goyon baya ga ayyuka masu yawa na bayanai ( MongoDB, MySQL, Redis...) da kuma aikin aiki kamar Heroku: kuna loda lambar ku zuwa dandamali, yana gina hotunan akwati kuma yana tura su.
Zan gaya muku yadda aka aika zirga-zirga zuwa dandalin dotCloud. Ba saboda yana da kyau musamman (ko da yake tsarin ya yi aiki da kyau don lokacinsa!), Amma da farko saboda tare da taimakon kayan aikin zamani, irin wannan ƙirar za a iya aiwatar da shi cikin sauƙi a cikin ɗan gajeren lokaci ta hanyar ƙananan ƙungiya idan suna buƙatar hanyar da za a bi. zirga-zirga tsakanin gungun microservices ko gungun aikace-aikace. Don haka, zaku iya kwatanta zaɓuɓɓuka: menene zai faru idan kun haɓaka komai da kanku ko amfani da ragamar sabis ɗin data kasance. Daidaitaccen zaɓi: yi naka ko saya.
Hanyar zirga-zirga don aikace-aikacen da aka shirya
Aikace-aikace akan dotCloud na iya fallasa wuraren ƙarshen HTTP da TCP.
HTTP ƙarshen daɗaɗɗen ƙara zuwa ƙayyadaddun tarin ma'aunin nauyi . Wannan yayi kama da abin da albarkatun ke yi a yau a Kubernetes da ma'aunin nauyi kamar .
Abokan ciniki suna haɗi zuwa wuraren ƙarshen HTTP ta cikin wuraren da suka dace, idan aka ba da maƙasudin sunan yankin zuwa ma'aunin nauyi na dotCloud. Babu wani abu na musamman.
Farashin TCP hade da lambar tashar jiragen ruwa, wanda daga nan aka wuce zuwa duk kwantena a cikin wannan tari ta hanyar canjin yanayi.
Abokan ciniki na iya haɗawa zuwa ƙarshen ƙarshen TCP ta amfani da sunan mai masaukin da ya dace (wani abu kamar gateway-X.dotcloud.com) da lambar tashar jiragen ruwa.
Wannan sunan mai masaukin yana warwarewa zuwa gungu na uwar garken "nats" (ba shi da alaƙa da ) wanda zai ba da hanyar haɗin TCP mai shigowa zuwa daidaitaccen akwati (ko, a cikin yanayin ayyuka masu daidaitawa, zuwa daidaitattun kwantena).
Idan kun saba da Kubernetes, tabbas wannan zai tunatar da ku sabis .
Babu wasu ayyuka da suka yi daidai akan dandalin dotCloud : don sauƙi, samun dama ga ayyuka ya faru iri ɗaya daga ciki da wajen dandamali.
An tsara komai a sauƙaƙe: ainihin aiwatar da hanyoyin sadarwar HTTP da TCP mai yiwuwa wasu layukan Python kaɗan ne kawai. Sauƙaƙan (zan iya faɗi, butulci) algorithms waɗanda aka gyara tare da haɓakar dandamali da fitowar ƙarin buƙatu.
Ba a buƙatar babban sake fasalin lambar data kasance ba. Musamman, na iya amfani da adireshin da aka samu ta hanyar masu canjin yanayi kai tsaye.
Yaya wannan ya bambanta da layin sabis na zamani?
iyakance ganuwa. Ba mu da wani ma'auni na ragamar tuƙi na TCP kwata-kwata. Lokacin da ya zo kan hanyar HTTP, ƙarin sigogin baya-bayan nan suna da cikakkun ma'aunin HTTP tare da lambobin kuskure da lokutan amsawa, amma meshes sabis na zamani ya wuce gaba, yana ba da haɗin kai tare da tsarin tarin awo kamar Prometheus, alal misali.
Ganuwa yana da mahimmanci ba kawai daga yanayin aiki ba (don taimakawa magance matsalolin), har ma lokacin da aka fitar da sabbin abubuwa. Magana akan lafiya и .
Ingantacciyar hanya yana da iyaka. A cikin ragar hanyar dotCloud, duk zirga-zirgar ababen hawa dole ne su wuce ta gungu na nodes ɗin da aka keɓe. Wannan yana nufin yuwuwar ƙetare iyakokin AZ da yawa (yankin samuwa) da haɓakar latency. Na tuna lambar gyara matsala wanda yayi sama da ɗari SQL queries a kowane shafi kuma ya buɗe sabon haɗi zuwa uwar garken SQL don kowace tambaya. Lokacin da ake aiki a gida, shafin yana ɗauka nan take, amma akan dotCloud yana ɗaukar ƴan daƙiƙa kaɗan don lodawa saboda kowane haɗin TCP (da kuma tambayar SQL na gaba) yana ɗaukar dubun milliseconds. A cikin wannan yanayin musamman, haɗin kai mai tsayi ya warware matsalar.
Meshes sabis na zamani sun fi dacewa da magance irin waɗannan matsalolin. Da farko, suna duba cewa an lalata hanyoyin haɗin a tushen. Gudun ma'ana guda ɗaya ne: клиент → меш → сервис, amma yanzu raga yana aiki a gida kuma ba akan nodes masu nisa ba, don haka haɗin клиент → меш na gida ne kuma yana da sauri sosai (microseconds maimakon milliseconds).
Meshes sabis na zamani kuma suna aiwatar da algorithms daidaita nauyi mafi wayo. Ta hanyar saka idanu akan lafiyar masu goyan baya, za su iya aika ƙarin zirga-zirga zuwa ga baya da sauri, yana haifar da kyakkyawan aiki gaba ɗaya.
Tsaro shi ma yafi. DotCloud ragamar tuƙi ta gudana gaba ɗaya akan EC2 Classic kuma ba ta ɓoye zirga-zirgar ababen hawa ba (a ƙarƙashin zaton cewa idan wani ya sami nasarar sanya sniffer akan zirga-zirgar hanyar sadarwar EC2, kun riga kun shiga cikin babbar matsala). Sabis ɗin sabis na zamani a bayyane yana kare duk zirga-zirgar mu, misali, tare da amincin TLS na juna da boye-boye na gaba.
Hanyar zirga-zirga don ayyukan dandamali
To, mun tattauna zirga-zirga tsakanin aikace-aikace, amma menene game da dandalin dotCloud da kanta?
Dandalin da kansa ya ƙunshi kusan ƙananan ayyuka ɗari da ke da alhakin ayyuka daban-daban. Wasu suna karɓar buƙatu daga wasu, wasu kuma ma'aikatan baya ne waɗanda ke da alaƙa da wasu ayyuka amma ba su karɓi haɗin kai da kansu ba. A kowane hali, kowane sabis dole ne ya san ƙarshen adiresoshin da yake buƙatar haɗa su.
Yawancin manyan ayyuka na iya amfani da ragamar tuƙi da aka kwatanta a sama. A zahiri, yawancin fiye da XNUMX dotCloud microservices an tura su azaman aikace-aikace na yau da kullun akan dandalin dotCloud kanta. Amma karamin adadin ƙananan ayyuka (musamman, waɗanda ke aiwatar da wannan ragamar zirga-zirga) suna buƙatar wani abu mafi sauƙi, tare da ƙarancin dogaro (saboda ba za su iya dogara da kansu don yin aiki ba - tsohuwar kaza da matsalar kwai).
Waɗannan ƙananan matakan, ayyuka masu mahimmanci an tura su ta hanyar kwantena masu gudana kai tsaye a kan ƴan maɓalli kaɗan. A lokaci guda, daidaitattun sabis na dandamali ba su shiga ba: mai haɗawa, mai tsarawa, da mai gudu. Idan kuna son kwatanta da dandamali na kwantena na zamani, yana kama da ƙaddamar da jirgin sama mai sarrafawa da docker run kai tsaye a kan nodes, maimakon ba da aikin zuwa Kubernetes. Yana da kyawawan kama a ra'ayi , wanda ke amfani ko lokacin yin booting gungu na tsaye.
An fallasa waɗannan ayyuka ta hanya mai sauƙi da ɗanyen aiki: fayil ɗin YAML ya jera sunayensu da adireshi; kuma kowane abokin ciniki ya ɗauki kwafin wannan fayil ɗin YAML don turawa.
A gefe guda, wannan abin dogara ne sosai, saboda baya buƙatar goyon bayan maɓalli / ƙimar waje, kamar Zookeeper (tuna, da dai sauransu ko Consul ba su wanzu a lokacin). A gefe guda, ya sa ya zama mai wahala don motsa ayyukan. Duk lokacin da aka yi motsi, duk abokan ciniki dole ne su sami fayil ɗin YAML da aka sabunta (kuma mai yuwuwa a sake lodawa). Ba dadi sosai!
Daga baya, mun fara aiwatar da sabon tsari, inda kowane abokin ciniki ya haɗa zuwa uwar garken wakili na gida. Maimakon adireshin da tashar jiragen ruwa, kawai yana buƙatar sanin lambar tashar tashar sabis ɗin, kuma haɗi ta hanyar localhost. Wakilin gida yana kula da wannan haɗin kuma yana tura shi zuwa ainihin uwar garken. Yanzu lokacin matsar da baya zuwa wata na'ura ko sikeli, maimakon sabunta duk abokan ciniki, duk waɗannan proxies na gida kawai suna buƙatar sabuntawa; kuma ba a buƙatar sake kunnawa.
(An kuma tsara shi don ƙaddamar da zirga-zirgar ababen hawa a cikin haɗin TLS da shigar da wani uwar garken wakili a gefen karɓar, da kuma duba takaddun shaida na TLS ba tare da sa hannun sabis ɗin karɓa ba, wanda aka saita don karɓar haɗin kai kawai akan. localhost. Karin bayani akan haka daga baya).
Wannan yayi kama da daga Airbnb, amma babban bambanci shine ana aiwatar da SmartStack kuma an tura shi don samarwa, yayin da tsarin dotCloud na cikin gida ya kasance cikin akwati lokacin da dotCloud ya juya zuwa Docker.
Ni da kaina na ɗauki SmartStack ɗaya daga cikin magabata na tsarin kamar Istio, Linkerd da Consul Connect saboda duk suna bin tsari iri ɗaya:
- Gudanar da wakili akan kowane kumburi.
- Abokan ciniki suna haɗi zuwa wakili.
- Jirgin sama mai sarrafawa yana sabunta tsarin wakili lokacin da abubuwan baya suka canza.
- … Riba!
Aiwatar Rukunin Sabis na Zamani
Idan muna buƙatar aiwatar da irin wannan grid a yau, za mu iya amfani da ƙa'idodi iri ɗaya. Misali, saita yankin DNS na ciki ta taswira sunayen sabis zuwa adireshi a sarari 127.0.0.0/8. Sannan gudanar da HAProxy akan kowane kullin gungu, karɓar haɗi akan kowane adireshin sabis (akan wannan rukunin yanar gizon 127.0.0.0/8) da kuma turawa/daidaita kaya zuwa madaidaitan baya masu dacewa. Ana iya sarrafa tsarin HAProxy , ba ka damar adana bayanan baya a cikin etcd ko Consul kuma tura sabuntawa ta atomatik zuwa HAProxy lokacin da ake buƙata.
Wannan shine yadda Istio ke aiki! Amma da wasu bambance-bambance:
- Amfani maimakon HAProxy.
- Yana adana saitin baya ta hanyar Kubernetes API maimakon etcd ko Consul.
- Ana keɓance sabis ɗin adireshi akan rukunin yanar gizo na ciki (adiresoshin Kubernetes ClusterIP) maimakon 127.0.0.0/8.
- Yana da ƙarin sashi (Citadel) don ƙara amincin TLS tsakanin abokin ciniki da sabobin.
- Yana goyan bayan sabbin abubuwa kamar watsewar da'ira, rarrabawar ganowa, tura canary, da sauransu.
Bari mu yi saurin duba wasu bambance-bambancen.
Wakili Wakili
Wakilin wakili Lyft ne ya rubuta shi [Mai hamayya da Uber a cikin kasuwar taksi - kusan. da.]. Ya yi kama da hanyoyi da yawa zuwa wasu proxies (misali HAProxy, Nginx, Traefik ...), amma Lyft ya rubuta nasu saboda suna buƙatar fasalulluka waɗanda wasu wakilai ba su da su kuma yana da alama mafi mahimmanci don yin sabon maimakon fadadawa. mai wanzuwa.
Ana iya amfani da wakili da kanta. Idan ina da takamaiman sabis ɗin da ke buƙatar haɗawa zuwa wasu ayyuka, zan iya saita shi don haɗawa da Manzo sannan kuma a hankali daidaitawa da sake daidaita manzo tare da wurin sauran ayyuka, yayin samun ƙarin abubuwa masu yawa kamar ganuwa. Maimakon ɗakin karatu na abokin ciniki na al'ada ko allura a cikin lambar gano kira, muna aika zirga-zirga zuwa Manzo, kuma yana tattara ma'auni mana.
Amma Manzo kuma yana iya aiki a matsayin jirgin data (jirgin sama) don layin sabis. Wannan yana nufin cewa yanzu don wannan layin sabis ɗin, an saita Manzo sarrafa jirgin sama (jirgin sarrafawa).
Jirgin sarrafawa
A cikin jirgin sarrafawa, Istio ya dogara da Kubernetes API. Wannan bai bambanta sosai da amfani da confd ba, wanda ya dogara da etcd ko Consul don duba saitin maɓalli a cikin ma'ajin bayanai. Istio yana duba ta hanyar saitin albarkatun Kubernetes ta hanyar Kubernetes API.
Tsakanin wannan sai kuma: Ni da kaina na sami wannan yana da amfani wanda ya karanta:
Sabar Kubernetes API shine "sabar wawa" wacce ke ba da ma'ajiya, siga, ingantawa, sabuntawa, da ma'anar albarkatun API.
An tsara Istio don yin aiki tare da Kubernetes; kuma idan kuna son amfani da shi a wajen Kubernetes, to kuna buƙatar fara misalin sabar Kubernetes API (da sabis ɗin taimako da sauransu).
Adireshin Sabis
Istio ya dogara da adiresoshin ClusterIP wanda Kubernetes ke keɓancewa, don haka sabis ɗin Istio ya sami adireshin ciki (ba a cikin kewayon ba. 127.0.0.0/8).
Traffic zuwa adireshin ClusterIP don takamaiman sabis a cikin gungu na Kubernetes ba tare da Istio ba ana kama shi ta hanyar kube-proxy kuma ana aika shi zuwa ga bayan wakili. Idan kuna sha'awar cikakkun bayanan fasaha, kube-proxy yana saita ƙa'idodin iptables (ko IPVS load balancers, dangane da yadda aka daidaita shi) don sake rubuta adireshin IP na manufa na haɗin kai zuwa adireshin ClusterIP.
Da zarar an shigar da Istio akan gungu na Kubernetes, babu abin da ke canzawa har sai an kunna shi a sarari don mabukaci, ko ma gabaɗayan sunan suna, ta hanyar gabatar da akwati. sidecar zuwa kwasfa na al'ada. Wannan kwantena zai fara misalin Manzo kuma ya kafa saitin ka'idojin iptables don katse zirga-zirgar da ke zuwa wasu hidimomi da tura waccan hanyar zuwa Manzo.
Lokacin da aka haɗa tare da Kubernetes DNS, wannan yana nufin cewa lambar mu na iya haɗawa da sunan sabis, kuma duk abin "kawai yana aiki". A takaice dai, lambar mu tana haifar da tambayoyi kamar http://api/v1/users/4242to api warware bukatar don 10.97.105.48, Dokokin iptables suna katse haɗin kai daga 10.97.105.48 kuma a tura su zuwa wakili na Wakilin gida, wanda zai tura buƙatar zuwa ainihin bayanan API. Phew!
Ƙarin frills
Istio kuma yana ba da ɓoyayyen ɓoye-zuwa-ƙarshe da tabbatarwa ta mTLS (TLS na juna). Bangaren da ake kira kagara.
Akwai kuma bangaren Mahaɗa, wanda Manzo zai iya nema kowane roƙon yanke shawara na musamman game da wannan buƙatar ya dogara da dalilai daban-daban kamar rubutun kai, ɗorawa na baya, da sauransu ... (kada ku damu: akwai kayan aikin da yawa don ci gaba da aiki Mixer, kuma ko da ya fashe, Wakilin zai ci gaba da aiki. a matsayin wakili).
Kuma, ba shakka, mun ambaci ganuwa: Manzo yana tattara ma'auni masu yawa yayin da yake ba da gano rarrabawa. A cikin gine-ginen microservices, idan buƙatun API guda ɗaya yana buƙatar wucewa ta hanyar microservices A, B, C, da D, sannan bayan shiga, ganowa da aka rarraba zai ƙara mai ganowa na musamman ga buƙatun kuma ya adana wannan mai gano ta hanyar buƙatun ga duk waɗannan microservices, bada izinin don kama duk kira masu alaƙa, jinkirin su, da sauransu.
Ci gaba ko saya
Istio yana da suna don kasancewa mai rikitarwa tsarin. Sabanin haka, gina ragar hanyar da na bayyana a farkon wannan post ɗin yana da sauƙi tare da kayan aikin da ake dasu. Don haka, shin yana da ma'ana don ƙirƙirar ragamar sabis ɗin ku maimakon?
Idan muna da matsakaicin buƙatu (ba ma buƙatar ganuwa, na'urar kewayawa da sauran dabaru), to tunani yana zuwa game da haɓaka kayan aikin mu. Amma idan muna amfani da Kubernetes, bazai ma zama dole ba saboda Kubernetes ya riga ya samar da kayan aikin asali don gano sabis da daidaita kaya.
Amma idan muna da buƙatun ci-gaba, to "siyan" ragamar sabis yana kama da zaɓi mafi kyau. (Wannan ba koyaushe bane "siyan" tunda Istio buɗaɗɗen tushe ne, amma har yanzu muna buƙatar saka hannun jari lokacin injiniya don fahimta, turawa, da sarrafa shi.)
Abin da za a zaɓa: Istio, Linkerd ko Consul Connect?
Ya zuwa yanzu mun yi magana game da Istio kawai, amma ba shine kawai layin sabis ba. Shahararriyar madadin ita ce , amma akwai ƙari .
Abin da za a zabi?
Maganar gaskiya ban sani ba. A halin yanzu ban dauki kaina da isa in amsa wannan tambayar ba. Akwai kadan tare da kwatanta waɗannan kayan aikin har ma .
Wata hanya mai ban sha'awa ita ce amfani da kayan aiki kamar . Yana aiwatar da Layer abstraction don sauƙaƙawa da haɓaka APIs ɗin da ke samar da meshes sabis. Maimakon koyon takamaiman (kuma, a ganina, ingantacciyar hadaddun) APIs na meshes sabis daban-daban, za mu iya amfani da mafi sauƙin ginin SuperGloo - kuma a sauƙaƙe canzawa daga ɗayan zuwa wani, kamar muna da tsarin daidaitawa na tsaka-tsaki wanda ke kwatanta musaya na HTTP da baya. iya samar da ainihin sanyi don Nginx, HAProxy, Traefik, Apache…
Na ɗan yi wasa tare da Istio da SuperGloo, kuma a cikin labarin na gaba ina so in nuna yadda ake ƙara Istio ko Linkerd zuwa gungu na yanzu ta amfani da SuperGloo, da kuma yadda ƙarshen zai yi aikinsa, wato, yana ba ku damar canzawa daga. ragamar sabis ɗaya zuwa wani ba tare da sake rubuta saiti ba.
source: www.habr.com