Ar an idirlíon (mogalra seirbhíse), agus seo ceann eile. Hooray! Ach cén fáth? Ansin, ba mhaith liom mo thuairim a chur in iúl go mbeadh sé níos fearr dá mbeadh an chuma ar mogaill seirbhíse 10 mbliana ó shin, roimh theacht ardáin coimeádáin mar Docker agus Kubernetes. Níl mé ag rá go bhfuil mo dhearcadh níos fearr nó níos measa ná daoine eile, ach ós rud é gur ainmhithe casta go leor iad mogaill seirbhíse, cabhróidh iliomad tuairimí chun iad a thuiscint níos fearr.
Labhróidh mé faoin ardán dotCloud, a tógadh ar bhreis is céad microservices agus a thacaigh leis na mílte feidhmchlár coimeádaithe. Míneoidh mé na dúshláin a bhí romhainn agus é á fhorbairt agus á sheoladh, agus conas a d'fhéadfadh (nó nach bhféadfadh) mogaill seirbhíse cabhrú.
Stair dotCloud
Scríobh mé faoi stair dotCloud agus na roghanna ailtireachta don ardán seo, ach níor labhair mé mórán faoin gciseal líonra. Más rud é nach bhfuil tú ag iarraidh a Léim isteach sa léitheoireacht Maidir le dotCloud, seo an scéal go hachomair: is ardán mar sheirbhís PaaS é a ligeann do chustaiméirí raon leathan feidhmchlár a rith (Java, PHP, Python...), le tacaíocht do raon leathan sonraí seirbhísí (MongoDB, MySQL, Redis...) agus sreabhadh oibre cosúil le Heroku: Uaslódálann tú do chód chuig an ardán, tógann sé íomhánna coimeádáin agus imlonnaítear iad.
Inseoidh mé duit conas a díríodh trácht chuig an ardán dotCloud. Ní mar gheall go raibh sé fíor-fhionnuar (cé gur oibrigh an córas go maith dá chuid ama!), ach go príomha mar gheall ar uirlisí nua-aimseartha is féidir le foireann bheag dearadh den sórt sin a chur i bhfeidhm go héasca i mbeagán ama má theastaíonn bealach uathu chun trácht a dhéanamh idir grúpa. de mhicrisheirbhísí nó a lán feidhmchlár. Ar an mbealach seo, is féidir leat na roghanna a chur i gcomparáid: cad a tharlaíonn má fhorbraíonn tú gach rud tú féin nó má úsáideann tú mogalra seirbhíse atá ann cheana féin. Is é an rogha caighdeánach é a dhéanamh leat féin nó é a cheannach.
Ródú tráchta le haghaidh feidhmchláir óstaithe
Is féidir le feidhmchláir ar dotCloud críochphointí HTTP agus TCP a nochtadh.
Críochphointí HTTP curtha go dinimiciúil leis an gcumraíocht braisle cothromóir ualaigh . Tá sé seo cosúil leis an méid a dhéanann acmhainní inniu i Kubernetes agus cothromóir ualaigh cosúil .
Ceanglaíonn cliaint le críochphointí HTTP trí fhearann cuí, ar choinníoll go díríonn an t-ainm fearainn ar chothromóirí ualaigh dotCloud. Ní dhéanfaidh aon ní speisialta.
Críochphointí TCP a bhaineann le huimhir phoirt, a chuirtear ar aghaidh ansin chuig gach coimeádán sa chruach sin trí athróga comhshaoil.
Is féidir le cliaint nascadh le críochphointí TCP ag baint úsáide as an óstainm cuí (rud éigin cosúil le gateway-X.dotcloud.com) agus uimhir an phoirt.
Réitíonn an t-óstainm seo leis an mbraisle freastalaí “nats” (nach mbaineann le ), a sheolfaidh naisc TCP isteach chuig an gcoimeádán ceart (nó, i gcás seirbhísí ualach-chothromaithe, chuig na coimeádáin chearta).
Má tá cur amach agat ar Kubernetes, is dócha go gcuirfidh sé seo Seirbhísí i gcuimhne duit .
Ní raibh aon seirbhísí coibhéiseacha ar an ardán dotCloud : Ar mhaithe le simplíocht, fuarthas rochtain ar sheirbhísí ar an mbealach céanna ón taobh istigh agus lasmuigh den ardán.
Eagraíodh gach rud go simplí: is dócha nach raibh i bhfeidhmiúcháin tosaigh líonraí ródaithe HTTP agus TCP ach cúpla céad líne de Python an ceann. Algartaim shimplí (déarfainn naive) a bhí scagtha de réir mar a d'fhás an t-ardán agus bhí ceanglais bhreise le feiceáil.
Ní raibh gá leis an gcód a bhí ann cheana a athfhachtóiriú go fairsing. Go háirithe, is féidir leis an seoladh a fhaightear trí athróga timpeallachta a úsáid go díreach.
Cén difríocht atá idir seo agus mogalra seirbhíse nua-aimseartha?
Teoranta infheictheacht. Ní raibh aon mhéadracht againn don mhogalra ródaithe TCP ar chor ar bith. Maidir le ródú HTTP, thug leaganacha níos déanaí isteach méadrachtaí mionsonraithe HTTP le cóid earráide agus amanna freagartha, ach téann mogaill seirbhíse nua-aimseartha níos faide fós, ag soláthar comhtháthú le córais bailithe méadrachta mar Prometheus, mar shampla.
Tá infheictheacht tábhachtach, ní hamháin ó thaobh na hoibríochta de (chun cabhrú le fadhbanna a réiteach), ach freisin nuair a bhíonn gnéithe nua á scaoileadh. Tá sé faoi sábháilte и .
Éifeachtúlacht ródaithe teoranta freisin. Sa mhogall ródaithe dotCloud, bhí ar an trácht go léir dul trí bhraisle de nóid ródaithe tiomnaithe. Chiallaigh sé seo go bhféadfaí teorainneacha iolracha AZ (Crios Infhaighteachta) a thrasnú agus méadú suntasach ar an bhfola. Is cuimhin liom cód fabhtcheartaithe a bhí ag déanamh breis agus céad fiosrú SQL in aghaidh an leathanaigh agus ag oscailt nasc nua leis an bhfreastalaí SQL do gach ceist. Nuair a bhíonn sé ag rith go háitiúil, lódálann an leathanach láithreach, ach i dotCloud tógann sé cúpla soicind é a luchtú mar go dtógann gach nasc TCP (agus ceist SQL ina dhiaidh sin) na mílte milleasoicindí. Sa chás áirithe seo, réitigh naisc sheasmhacha an fhadhb.
Is fearr mogaill seirbhíse nua-aimseartha chun déileáil le fadhbanna den sórt sin. Ar an gcéad dul síos, seiceann siad go ndéantar naisc a ródú sa bhfoinse. Tá an sreabhadh loighciúil mar an gcéanna: клиент → меш → сервис, ach anois oibríonn an mogalra go háitiúil agus ní ar nóid iargúlta, mar sin an nasc клиент → меш áitiúil agus an-tapa (micreasoicindí in ionad na milleasoicindí).
Cuireann mogaill seirbhíse nua-aimseartha halgartaim um chothromú ualach níos cliste i bhfeidhm freisin. Trí mhonatóireacht a dhéanamh ar shláinte na n-ais, is féidir leo níos mó tráchta a sheoladh go dtí cúlchríocha níos tapúla, rud a fhágann go mbeidh feidhmíocht níos fearr ar an iomlán.
slándála níos fearr freisin. Rith an mogalra ródaithe dotCloud go hiomlán ar EC2 Classic agus níor chriptigh sé trácht (bunaithe ar an toimhde dá mba rud é gur éirigh le duine sniffer a chur ar thrácht líonra EC2, go raibh tú i dtrioblóid mhór cheana féin). Cosnaíonn mogaill seirbhíse nua-aimseartha ár dtrácht go léir go trédhearcach, mar shampla, le fíordheimhniú TLS frithpháirteach agus criptiú ina dhiaidh sin.
Ródú tráchta le haghaidh seirbhísí ardáin
Ceart go leor, tá trácht idir iarratais pléite againn, ach cad mar gheall ar an ardán dotCloud féin?
Bhí an t-ardán féin comhdhéanta de thart ar céad microservices freagrach as feidhmeanna éagsúla. Ghlac cuid acu le hiarratais ó dhaoine eile, agus bhí cuid acu ina n-oibrithe cúlra a cheangail le seirbhísí eile ach nár ghlac le naisc iad féin. Ar aon chuma, ní mór go mbeadh a fhios ag gach seirbhís críochphointí na seoltaí a gcaithfidh sí nascadh leo.
Féadfaidh go leor seirbhísí ardleibhéil úsáid a bhaint as an mogalra ródaithe ar a gcuirtear síos thuas. Go deimhin, tá go leor de níos mó ná céad microservices dotCloud imscaradh mar iarratais rialta ar an ardán dotCloud féin. Ach bhí rud níos simplí ag teastáil ó líon beag seirbhísí ar leibhéal íseal (go háirithe iad siúd a chuireann an mogalra ródaithe seo i bhfeidhm) le níos lú spleáchais (toisc nárbh fhéidir leo brath orthu féin le bheith ag obair - an tseanfhadhb sicín agus uibheacha).
Baineadh úsáid as na seirbhísí íseal-leibhéil seo atá ríthábhachtach ó thaobh misean de trí choimeádáin a rith go díreach ar roinnt príomhnóid. Sa chás seo, níor úsáideadh seirbhísí ardán caighdeánach: nascóir, sceidealóir agus rádala. Más mian leat a chur i gcomparáid le ardáin coimeádán nua-aimseartha, tá sé cosúil le reáchtáil eitleán rialaithe le docker run go díreach ar na nóid, in ionad an tasc a tharmligean chuig Kubernetes. Tá sé cosúil go leor i gcoincheap , a úsáideann sé nó nuair a booting braisle neamhspleách.
Nochtadh na seirbhísí seo ar bhealach simplí agus amh: liostaíodh i gcomhad YAML a n-ainmneacha agus a seoltaí; agus bhí ar gach cliant cóip den chomhad YAML seo a thógáil lena imscaradh.
Ar thaobh amháin, tá sé thar a bheith iontaofa toisc nach dteastaíonn tacaíocht ó stór eochair/luacha seachtrach ar nós Zookeeper (cuimhnigh, etcd nó nach raibh Consal ann ag an am sin). Ar an láimh eile, rinne sé deacair seirbhísí a bhogadh. Gach uair a dhéantar aistriú, gheobhaidh gach cliant comhad YAML nuashonraithe (agus b'fhéidir go ndéanfaí é a atosaigh). Nach bhfuil an-chompordach!
Ina dhiaidh sin, thosaigh muid ar scéim nua a chur i bhfeidhm, inar cheangail gach cliant le seachfhreastalaí áitiúil. In ionad seoladh agus calafort, ní gá go mbeadh a fhios aige ach uimhir phoirt na seirbhíse, agus ceangal trí localhost. Láimhseálann an seachfhreastalaí áitiúil an ceangal seo agus cuireann sé ar aghaidh chuig an bhfreastalaí féin é. Anois, nuair a bhogann tú an t-innill chuig meaisín eile nó go scálú, in ionad gach cliant a nuashonrú, ní gá duit ach na seachvótálaithe áitiúla seo go léir a nuashonrú; agus ní gá atosaigh a thuilleadh.
(Bhí sé beartaithe freisin an trácht i naisc TLS a chuimsiú agus seachfhreastalaí eile a chur ar an taobh glactha, chomh maith le deimhnithe TLS a fhíorú gan rannpháirtíocht na seirbhíse glactha, atá cumraithe chun glacadh le naisc amháin ar localhost. Tuilleadh faoi seo níos déanaí).
Tá sé seo an-chosúil le ó Airbnb, ach is é an difríocht shuntasach ná go gcuirtear SmartStack i bhfeidhm agus go n-imscartar chuig táirgeadh é, agus cuireadh córas ródaithe inmheánach dotCloud ar an seilf nuair a tháinig dotCloud Docker.
Measaim go pearsanta go bhfuil SmartStack ar cheann de na réamhtheachtaithe ar chórais mar Istio, Linkerd agus Consul Connect mar go leanann siad go léir an patrún céanna:
- Rith seachfhreastalaí ar gach nód.
- Ceanglaíonn cliaint leis an seachfhreastalaí.
- Nuashonraíonn an t-eitleán rialaithe an chumraíocht seachfhreastalaí nuair a athraíonn na hinnill.
- ... Brabús!
Mogall seirbhíse a chur i bhfeidhm nua-aimseartha
Dá mba ghá dúinn eangach den chineál céanna a chur i bhfeidhm inniu, d’fhéadfaimis prionsabail chomhchosúla a úsáid. Mar shampla, cumraigh crios inmheánach DNS trí ainmneacha seirbhíse a mhapáil chuig seoltaí sa spás 127.0.0.0/8. Ansin rith HAProxy ar gach nód sa bhraisle, ag glacadh le naisc ag gach seoladh seirbhíse (san fholíon sin 127.0.0.0/8) agus an t-ualach a atreorú/cothromú go dtí na hinnill chuí. Is féidir cumraíocht HAProxy a rialú , rud a ligeann duit faisnéis inneall a stóráil in etcd nó Consal agus cumraíocht nuashonraithe a bhrú go huathoibríoch chuig HAProxy nuair is gá.
Seo mar a oibríonn Istio go leor! Ach le roinnt difríochtaí:
- Úsáidí in ionad HAProxy.
- Stórálann cumraíocht inneall trí Kubernetes API in ionad srld nó Consal.
- Leithdháiltear seoltaí ar sheirbhísí ar an bhfolíon inmheánach (seoltaí Kubernetes ClusterIP) in ionad 127.0.0.0/8.
- Tá comhpháirt bhreise aige (Citadel) chun fíordheimhniú TLS frithpháirteach a chur leis idir an cliant agus na freastalaithe.
- Tacaíonn sé le gnéithe nua cosúil le briseadh ciorcaid, rianú dáilte, imscaradh canáraí, etc.
Breathnaímis go gasta ar chuid de na difríochtaí.
Seachfhreastalaí Toscaire
Ba é Lyft [iomaitheoir Uber sa mhargadh tacsaithe a scríobh Toscaire Proxy - thart ar. lána]. Tá sé cosúil ar go leor bealaí le seachvótálaithe eile (m.sh. HAProxy, Nginx, Traefik ...), ach scríobh Lyft a gcuid féin toisc go raibh gnéithe de dhíth orthu nach raibh ag seachvótálaithe eile, agus ba chosúil go raibh sé níos cliste ceann nua a dhéanamh seachas an ceann a bhí ann a leathnú.
Is féidir Toscaire a úsáid ar a chuid féin. Má tá seirbhís ar leith agam ar gá nascadh le seirbhísí eile, is féidir liom í a chumrú chun ceangal le Toscaire, agus ansin Toscaire a chumrú agus a athchumrú go dinimiciúil le suíomh seirbhísí eile, agus ag an am céanna ag fáil go leor feidhmiúlacht bhreise iontach, mar infheictheacht. In ionad leabharlann cliant saincheaptha nó rianta glaonna a instealladh isteach sa chód, cuirimid trácht chuig Toscaire, agus bailíonn sé méadracht dúinn.
Ach tá Toscaire in ann oibriú mar eitleán sonraí (eitleán sonraí) don mhogall seirbhíse. Ciallaíonn sé seo go bhfuil Toscaire cumraithe anois don mhogall seirbhíse seo eitleán rialaithe (eitleán rialaithe).
Eitleán rialaithe
Maidir leis an eitleán rialaithe, braitheann Istio ar Kubernetes API. Níl sé seo an-difriúil ó úsáid confd, atá ag brath ar etcd nó Consal chun féachaint ar an tsraith eochracha sa stór sonraí. Úsáideann Istio API Kubernetes chun féachaint ar thacar acmhainní Kubernetes.
Idir seo agus ansin: Bhí sé seo úsáideach dom go pearsanta a léann:
Is “freastalaí balbh” é Freastalaí API Kubernetes a thairgeann stóráil, leagan, bailíochtú, nuashonrú agus semantics le haghaidh acmhainní API.
Tá Istio deartha chun oibriú le Kubernetes; agus más mian leat é a úsáid lasmuigh de Kubernetes, ní mór duit sampla den fhreastalaí Kubernetes API a rith (agus an tseirbhís cúntóir etcd).
Seoltaí seirbhíse
Braitheann Istio ar sheoltaí ClusterIP a leithdháileann Kubernetes, mar sin faigheann seirbhísí Istio seoladh inmheánach (nach bhfuil sa raon 127.0.0.0/8).
Déantar trácht chuig an seoladh ClusterIP do sheirbhís ar leith i mbraisle Kubernetes gan Istio a idircheapadh trí sheachvótálaí kube agus seoltar chuig inneall an seachfhreastalaí sin é. Má tá suim agat sna sonraí teicniúla, socraíonn kube-proxy rialacha iptables (nó cothromóirí ualaigh IPVS, ag brath ar an gcaoi a bhfuil sé cumraithe) chun seoltaí IP ceann scríbe na nasc atá ag dul go dtí an seoladh ClusterIP a athscríobh.
Nuair atá Istio suiteáilte ar bhraisle Kubernetes, ní athraíonn aon rud go dtí go mbeidh sé cumasaithe go sainráite do thomhaltóir áirithe, nó fiú an t-ainmspás iomlán, trí choimeádán a thabhairt isteach sidecar i pods saincheaptha. Casfaidh an coimeádán seo sampla Toscaire agus socróidh sé sraith rialacha iptables chun trácht atá ag dul go seirbhísí eile a chosc agus an trácht sin a atreorú chuig Toscaire.
Nuair a dhéantar é a chomhtháthú le Kubernetes DNS, ciallaíonn sé seo gur féidir lenár gcód ceangal a dhéanamh de réir ainm na seirbhíse agus "oibríonn gach rud". I bhfocail eile, eisíonn ár gcód ceisteanna cosúil le http://api/v1/users/4242ansin api iarratas a réiteach ar 10.97.105.48, déanfaidh na rialacha iptables naisc a idircheapadh ó 10.97.105.48 agus iad a chur ar aghaidh chuig an seachfhreastalaí Toscaire áitiúil, agus cuirfidh an seachfhreastalaí áitiúil sin an t-iarratas ar aghaidh chuig an API backend iarbhír. Phew!
Torthaí breise
Soláthraíonn Istio criptiú agus fíordheimhniú deireadh go deireadh freisin trí mTLS (TLS frithpháirteach). Comhpháirt ar a dtugtar Citadel.
Tá comhpháirt ann freisin Meascthóir, ar féidir leis an Toscaire a iarraidh gach iarratas cinneadh speisialta a dhéanamh faoin iarratas sin ag brath ar fhachtóirí éagsúla cosúil le ceanntásca, ualach inneall, etc... (ná bíodh imní ort: tá go leor bealaí ann chun Meascthóir a choinneáil ar siúl, agus fiú má thuairteanna sé, leanfaidh an Toscaire ag obair fíneáil mar sheachvótálaí).
Agus, ar ndóigh, luaigh muid infheictheacht: Bailíonn Toscaire méid ollmhór méadrachta agus é ag soláthar rianaithe dáilte. In ailtireacht micrisheirbhísí, más gá d'iarratas API amháin dul trí mhicrisheirbhísí A, B, C, agus D, ansin ar logáil isteach, cuirfidh rianú dáilte aitheantóir uathúil leis an iarratas agus stórálfaidh sé an t-aitheantóir seo trí fho-iarrataí chuig na micriseirbhísí seo go léir, rud a cheadaíonn gach glao gaolmhar le gabháil, moill, etc.
A fhorbairt nó a cheannach
Tá cáil ar Istio as a bheith casta. I gcodarsnacht leis sin, tá tógáil an mhogalra ródaithe a ndearna mé cur síos air ag tús an phoist seo sách simplí ag baint úsáide as uirlisí atá ann cheana féin. Mar sin, an ndéanann sé ciall do mhogalra seirbhíse féin a chruthú ina ionad?
Má bhíonn riachtanais bheaga againn (níl infheictheacht, scoradán ciorcaid agus nithe eile de dhíth orainn), ansin smaoinítear ar ár n-uirlis féin a fhorbairt. Ach má úsáidimid Kubernetes, b'fhéidir nach mbeidh gá leis fiú toisc go soláthraíonn Kubernetes uirlisí bunúsacha cheana féin le haghaidh fionnachtain seirbhíse agus cothromaíocht ualaigh.
Ach má tá ardriachtanais againn, is cosúil gur rogha i bhfad níos fearr é “mogall seirbhíse a cheannach”. (Ní “cheannach” é seo i gcónaí toisc gur foinse oscailte é Istio, ach ní mór dúinn fós am innealtóireachta a infheistiú chun é a thuiscint, a imscaradh agus a bhainistiú.)
Ar cheart dom Istio, Linkerd nó Consul Connect a roghnú?
Go dtí seo níor labhair muid ach faoi Istio, ach ní hé seo an t-aon mogalra seirbhíse. Tá rogha eile tóir , agus tá níos mó .
Cad atá le roghnú?
Go hionraic, níl a fhios agam. I láthair na huaire ní dóigh liom go bhfuil mé inniúil go leor chun an cheist seo a fhreagairt. Tá cúpla le comparáid idir na huirlisí seo agus fiú .
Cur chuige amháin a bhfuil tuar dóchais inti is ea uirlis mar . Cuireann sé ciseal astarraingthe i bhfeidhm chun na APIanna a nochtar ag mogaill seirbhíse a shimpliú agus a aontú. In ionad a bheith ag foghlaim na APIs sonracha (agus, i mo thuairim, sách casta) de mogaill seirbhíse éagsúla, is féidir linn úsáid a bhaint as constructs níos simplí SuperGloo - agus go héasca aistriú ó cheann go ceann eile, amhail is dá mbeadh formáid cumraíochta idirmheánach againn ag cur síos ar chomhéadain HTTP agus backends in ann. an chumraíocht iarbhír a ghiniúint do Nginx, HAProxy, Traefik, Apache ...
Tá mé tar éis dul i ngleic le Istio agus SuperGloo beagán, agus sa chéad alt eile ba mhaith liom a thaispeáint conas Istio nó Linkerd a chur le braisle atá ann cheana féin ag baint úsáide as SuperGloo, agus conas a dhéanann an dara ceann an post, is é sin, ligeann duit aistriú ó mogalra seirbhíse amháin go ceann eile gan cumraíochtaí a fhorscríobh.
Foinse: will.com