Ar y rhyngrwyd (rhwyll gwasanaeth), a dyma un arall. Hwre! Ond pam? Yna, rwyf am fynegi fy marn y byddai wedi bod yn well pe bai rhwyllau gwasanaeth yn ymddangos 10 mlynedd yn ôl, cyn dyfodiad llwyfannau cynwysyddion fel Docker a Kubernetes. Nid wyf yn dweud bod fy safbwynt yn well nac yn waeth nag eraill, ond gan fod rhwyllau gwasanaeth yn anifeiliaid eithaf cymhleth, bydd safbwyntiau lluosog yn helpu i'w deall yn well.
Siaradaf am y platfform dotCloud, a adeiladwyd ar dros gant o ficrowasanaethau ac a gefnogodd filoedd o gymwysiadau mewn cynwysyddion. Egluraf yr heriau a wynebwyd gennym wrth ei ddatblygu a'i lansio, a sut y gallai (neu na allai) rhwyllau gwasanaeth helpu.
Hanes dotCloud
Rwyf wedi ysgrifennu am hanes dotCloud a'r dewisiadau pensaernïaeth ar gyfer y platfform hwn, ond nid wyf wedi siarad llawer am haen y rhwydwaith. Os nad ydych am blymio i ddarllen am dotCloud, dyma'r hanfod yn gryno: mae'n blatfform-fel-a-gwasanaeth PaaS sy'n caniatáu i gwsmeriaid redeg ystod eang o gymwysiadau (Java, PHP, Python...), gyda chefnogaeth ar gyfer ystod eang o ddata gwasanaethau (MongoDB, MySQL, Redis...) a llif gwaith fel Heroku: Rydych chi'n uwchlwytho'ch cod i'r platfform, mae'n adeiladu delweddau cynhwysydd ac yn eu defnyddio.
Byddaf yn dweud wrthych sut y cafodd traffig ei gyfeirio at y platfform dotCloud. Nid oherwydd ei fod yn arbennig o cŵl (er bod y system wedi gweithio'n dda am ei amser!), ond yn bennaf oherwydd gydag offer modern mae'n hawdd gweithredu dyluniad o'r fath mewn amser byr gan dîm cymedrol os oes angen ffordd arnynt i gyfeirio traffig rhwng criw. o ficrowasanaethau neu griw o gymwysiadau. Fel hyn, gallwch chi gymharu'r opsiynau: beth sy'n digwydd os byddwch chi'n datblygu popeth eich hun neu'n defnyddio rhwyll gwasanaeth sy'n bodoli eisoes. Y dewis safonol yw ei wneud eich hun neu ei brynu.
Llwybr traffig ar gyfer ceisiadau a gynhelir
Gall cymwysiadau ar dotCloud ddatgelu pwyntiau terfyn HTTP a TCP.
Terfynbwyntiau HTTP wedi'i ychwanegu'n ddeinamig at gyfluniad clwstwr y cydbwysedd llwyth . Mae hyn yn debyg i'r hyn y mae adnoddau yn ei wneud heddiw yn Kubernetes a balancer llwyth fel .
Mae cleientiaid yn cysylltu â diweddbwyntiau HTTP trwy barthau priodol, ar yr amod bod yr enw parth yn pwyntio at gydbwyswyr llwyth dotCloud. Dim byd arbennig.
Terfynbwyntiau TCP sy'n gysylltiedig â rhif porthladd, sydd wedyn yn cael ei drosglwyddo i bob cynhwysydd yn y pentwr hwnnw trwy newidynnau amgylchedd.
Gall cleientiaid gysylltu â diweddbwyntiau TCP gan ddefnyddio'r enw gwesteiwr priodol (rhywbeth fel porth-X.dotcloud.com) a rhif porthladd.
Mae'r enw gwesteiwr hwn yn cyd-fynd â'r clwstwr gweinydd “nats” (ddim yn gysylltiedig â ), a fydd yn cyfeirio cysylltiadau TCP sy'n dod i mewn i'r cynhwysydd cywir (neu, yn achos gwasanaethau llwyth-cytbwys, i'r cynwysyddion cywir).
Os ydych chi'n gyfarwydd â Kubernetes, mae'n debyg y bydd hyn yn eich atgoffa o Wasanaethau .
Nid oedd unrhyw wasanaethau cyfatebol ar y platfform dotCloud : Er mwyn symlrwydd, cyrchwyd gwasanaethau yr un ffordd o'r tu mewn a'r tu allan i'r platfform.
Trefnwyd popeth yn eithaf syml: mae'n debyg mai dim ond ychydig gannoedd o linellau o Python yr un oedd gweithrediadau cychwynnol rhwydweithiau llwybro HTTP a TCP. Algorithmau syml (naïf) a gafodd eu mireinio wrth i'r platfform dyfu ac wrth i ofynion ychwanegol ymddangos.
Nid oedd angen ad-drefnu'r cod presennol yn helaeth. Yn benodol, yn gallu defnyddio'r cyfeiriad a gafwyd trwy newidynnau amgylchedd yn uniongyrchol.
Sut mae hyn yn wahanol i rwyll gwasanaeth modern?
Cyfyngedig gwelededd. Nid oedd gennym unrhyw fetrigau ar gyfer y rhwyll llwybro TCP o gwbl. O ran llwybro HTTP, cyflwynodd fersiynau diweddarach fetrigau HTTP manwl gyda chodau gwall ac amseroedd ymateb, ond mae rhwyllau gwasanaeth modern yn mynd hyd yn oed ymhellach, gan ddarparu integreiddio â systemau casglu metrigau fel Prometheus, er enghraifft.
Mae gwelededd yn bwysig nid yn unig o safbwynt gweithredol (i helpu i ddatrys problemau), ond hefyd wrth ryddhau nodweddion newydd. Mae'n ymwneud â diogel и .
Effeithlonrwydd llwybro yn gyfyngedig hefyd. Yn y rhwyll llwybro dotCloud, roedd yn rhaid i'r holl draffig fynd trwy glwstwr o nodau llwybro pwrpasol. Roedd hyn yn golygu o bosibl croesi ffiniau AZ (Parth Argaeledd) lluosog a chynyddu cuddni'n sylweddol. Rwy'n cofio cod datrys problemau a oedd yn gwneud dros gant o ymholiadau SQL fesul tudalen ac yn agor cysylltiad newydd â'r gweinydd SQL ar gyfer pob ymholiad. Wrth redeg yn lleol, mae'r dudalen yn llwytho ar unwaith, ond yn dotCloud mae'n cymryd ychydig eiliadau i'w llwytho oherwydd mae pob cysylltiad TCP (ac ymholiad SQL dilynol) yn cymryd degau o filieiliadau. Yn yr achos penodol hwn, roedd cysylltiadau parhaus yn datrys y broblem.
Mae rhwyllau gwasanaeth modern yn well am ddelio â phroblemau o'r fath. Yn gyntaf oll, maent yn gwirio bod cysylltiadau wedi'u cyfeirio yn y ffynhonnell. Mae'r llif rhesymegol yr un peth: клиент → меш → сервис, ond nawr mae'r rhwyll yn gweithio'n lleol ac nid ar nodau anghysbell, felly mae'r cysylltiad клиент → меш yn lleol ac yn gyflym iawn (microseiliadau yn lle milieiliadau).
Mae rhwyllau gwasanaeth modern hefyd yn gweithredu algorithmau cydbwyso llwyth doethach. Trwy fonitro iechyd backends, gallant anfon mwy o draffig i backends cyflymach, gan arwain at berfformiad cyffredinol gwell.
diogelwch well hefyd. Roedd y rhwyll llwybro dotCloud yn rhedeg yn gyfan gwbl ar EC2 Classic ac nid oedd yn amgryptio traffig (yn seiliedig ar y rhagdybiaeth pe bai rhywun yn llwyddo i roi synhwyro ar draffig rhwydwaith EC2, roeddech eisoes mewn trafferth mawr). Mae rhwyllau gwasanaeth modern yn amddiffyn ein holl draffig yn dryloyw, er enghraifft, gyda dilysu TLS ar y cyd ac amgryptio dilynol.
Llwybro traffig ar gyfer gwasanaethau platfform
Iawn, rydym wedi trafod traffig rhwng ceisiadau, ond beth am y platfform dotCloud ei hun?
Roedd y platfform ei hun yn cynnwys tua chant o ficrowasanaethau sy'n gyfrifol am wahanol swyddogaethau. Roedd rhai yn derbyn ceisiadau gan eraill, ac roedd rhai yn weithwyr cefndir a oedd yn cysylltu â gwasanaethau eraill ond nad oeddent yn derbyn cysylltiadau eu hunain. Beth bynnag, rhaid i bob gwasanaeth wybod diweddbwynt y cyfeiriadau y mae angen iddo gysylltu â nhw.
Gall llawer o wasanaethau lefel uchel ddefnyddio'r rhwyll llwybro a ddisgrifir uchod. Mewn gwirionedd, mae llawer o fwy na chant o ficrowasanaethau dotCloud wedi'u defnyddio fel cymwysiadau rheolaidd ar y platfform dotCloud ei hun. Ond roedd angen rhywbeth symlach ar nifer fach o wasanaethau lefel isel (yn enwedig y rhai sy'n gweithredu'r rhwyll llwybro hwn), gyda llai o ddibyniaethau (gan na allent ddibynnu arnynt eu hunain i weithio - yr hen broblem cyw iâr ac wy da).
Defnyddiwyd y gwasanaethau lefel isel hyn sy'n hanfodol i genhadaeth trwy redeg cynwysyddion yn uniongyrchol ar ychydig o nodau allweddol. Yn yr achos hwn, ni ddefnyddiwyd gwasanaethau platfform safonol: cysylltydd, trefnydd a rhedwr. Os ydych chi am gymharu â llwyfannau cynhwysydd modern, mae fel rhedeg awyren reoli gyda docker run yn uniongyrchol ar y nodau, yn lle dirprwyo'r dasg i Kubernetes. Mae'n eithaf tebyg o ran cysyniad , y mae'n ei ddefnyddio neu wrth gychwyn clwstwr annibynnol.
Amlygwyd y gwasanaethau hyn mewn modd syml ac amrwd: roedd ffeil YAML yn rhestru eu henwau a'u cyfeiriadau; ac roedd yn rhaid i bob cleient gymryd copi o'r ffeil YAML hon i'w defnyddio.
Ar y naill law, mae'n hynod ddibynadwy oherwydd nid oes angen cefnogaeth storfa allwedd/gwerth allanol fel Zookeeper (cofiwch, ac ati neu nid oedd Conswl yn bodoli bryd hynny). Ar y llaw arall, roedd yn ei gwneud yn anodd symud gwasanaethau. Bob tro y byddai symudiad yn cael ei wneud, byddai pob cleient yn derbyn ffeil YAML wedi'i diweddaru (ac o bosibl yn ailgychwyn). Ddim yn gyfforddus iawn!
Yn dilyn hynny, rydym yn dechrau gweithredu cynllun newydd, lle mae pob cleient yn cysylltu â gweinydd dirprwyol lleol. Yn lle cyfeiriad a phorthladd, dim ond rhif porthladd y gwasanaeth sydd ei angen arno, a chysylltu trwyddo localhost. Mae'r dirprwy lleol yn trin y cysylltiad hwn ac yn ei anfon ymlaen i'r gweinydd ei hun. Nawr, wrth symud y backend i beiriant arall neu raddio, yn hytrach na diweddaru'r holl gleientiaid, dim ond angen diweddaru'r holl ddirprwyon lleol hyn; ac nid oes angen ailgychwyn mwyach.
(Cynlluniwyd hefyd i grynhoi'r traffig mewn cysylltiadau TLS a rhoi gweinydd dirprwy arall ar yr ochr dderbyn, yn ogystal â gwirio tystysgrifau TLS heb gyfranogiad y gwasanaeth derbyn, sydd wedi'i ffurfweddu i dderbyn cysylltiadau yn unig ar localhost. Mwy am hyn yn nes ymlaen).
Mae hyn yn debyg iawn i o Airbnb, ond y gwahaniaeth sylweddol yw bod SmartStack yn cael ei weithredu a'i ddefnyddio i gynhyrchu, tra bod system llwybro fewnol dotCloud wedi'i rhoi o'r neilltu pan ddaeth dotCloud yn Docker.
Yn bersonol, rwy'n ystyried SmartStack yn un o'r rhagflaenwyr i systemau fel Istio, Linkerd a Consul Connect oherwydd eu bod i gyd yn dilyn yr un patrwm:
- Rhedeg dirprwy ar bob nod.
- Mae cleientiaid yn cysylltu â'r dirprwy.
- Mae'r awyren reoli yn diweddaru'r cyfluniad dirprwy pan fydd backends yn newid.
- ... Elw!
Gweithredu rhwyll gwasanaeth yn fodern
Pe bai angen inni roi grid tebyg ar waith heddiw, gallem ddefnyddio egwyddorion tebyg. Er enghraifft, ffurfweddwch barth DNS mewnol trwy fapio enwau gwasanaethau i gyfeiriadau yn y gofod 127.0.0.0/8. Yna rhedeg HAProxy ar bob nod yn y clwstwr, gan dderbyn cysylltiadau ym mhob cyfeiriad gwasanaeth (yn yr is-rwydwaith hwnnw 127.0.0.0/8) ac ailgyfeirio/cydbwyso'r llwyth i'r pen ôl priodol. Gellir rheoli ffurfweddiad HAProxy , sy'n eich galluogi i storio gwybodaeth backend yn etcd neu Conswl a gwthio cyfluniad wedi'i ddiweddaru yn awtomatig i HAProxy pan fo angen.
Dyma sut mae Istio yn gweithio fwy neu lai! Ond gyda rhai gwahaniaethau:
- Defnyddiau yn lle HAProxy.
- Yn storio cyfluniad backend trwy Kubernetes API yn lle ac ati neu Conswl.
- Rhoddir cyfeiriadau i wasanaethau ar yr is-rwydwaith mewnol (cyfeiriadau Kubernetes ClusterIP) yn lle 127.0.0.0/8.
- Mae ganddo gydran ychwanegol (Citadel) i ychwanegu dilysiad TLS cilyddol rhwng y cleient a gweinyddwyr.
- Yn cefnogi nodweddion newydd megis torri cylched, olrhain gwasgaredig, lleoli caneri, ac ati.
Gadewch i ni edrych yn gyflym ar rai o'r gwahaniaethau.
Cennad Dirprwy
Ysgrifennwyd Envoy Proxy gan Lyft [cystadleuydd Uber yn y farchnad dacsis - tua. lôn]. Mae'n debyg mewn sawl ffordd i ddirprwyon eraill (e.e. HAProxy, Nginx, Traefik...), ond ysgrifennodd Lyft eu rhai nhw oherwydd bod angen nodweddion nad oedd gan ddirprwyon eraill eu hangen arnynt, ac roedd yn ymddangos yn gallach gwneud un newydd yn hytrach nag ymestyn yr un presennol.
Gellir defnyddio Cennad ar ei ben ei hun. Os oes gennyf wasanaeth penodol sydd angen ei gysylltu â gwasanaethau eraill, gallaf ei ffurfweddu i gysylltu â'r Cennad, ac yna ffurfweddu ac ailgyflunio'r Cennad yn ddeinamig gyda lleoliad gwasanaethau eraill, tra'n cael llawer o swyddogaethau ychwanegol gwych, megis gwelededd. Yn lle llyfrgell cleient arferol neu chwistrellu olion galwadau i'r cod, rydym yn anfon traffig i Envoy, ac mae'n casglu metrigau i ni.
Ond mae Envoy hefyd yn gallu gweithio fel awyren data (awyren ddata) ar gyfer y rhwyll gwasanaeth. Mae hyn yn golygu bod Envoy bellach wedi'i ffurfweddu ar gyfer y rhwyll gwasanaeth hwn awyren reoli (awyren reoli).
Awyren reoli
Ar gyfer yr awyren reoli, mae Istio yn dibynnu ar API Kubernetes. Nid yw hyn yn wahanol iawn i ddefnyddio confd, sy'n dibynnu ar etcd neu Conswl i weld y set o allweddi yn y storfa ddata. Mae Istio yn defnyddio API Kubernetes i weld set o adnoddau Kubernetes.
Rhwng hyn ac yna: Yn bersonol, roedd hyn yn ddefnyddiol sy'n darllen:
Mae Gweinydd API Kubernetes yn “weinydd mud” sy'n cynnig storfa, fersiwn, dilysu, diweddaru a semanteg ar gyfer adnoddau API.
Mae Istio wedi'i gynllunio i weithio gyda Kubernetes; ac os ydych chi am ei ddefnyddio y tu allan i Kubernetes, yna mae angen i chi redeg enghraifft o weinydd Kubernetes API (a'r gwasanaeth cynorthwyydd ac ati).
Cyfeiriadau gwasanaeth
Mae Istio yn dibynnu ar gyfeiriadau ClusterIP y mae Kubernetes yn eu dyrannu, felly mae gwasanaethau Istio yn derbyn cyfeiriad mewnol (nid yn yr ystod 127.0.0.0/8).
Mae traffig i'r cyfeiriad ClusterIP ar gyfer gwasanaeth penodol mewn clwstwr Kubernetes heb Istio yn cael ei ryng-gipio gan kube-proxy a'i anfon i gefn y dirprwy hwnnw. Os oes gennych ddiddordeb yn y manylion technegol, mae kube-proxy yn sefydlu rheolau iptables (neu fantolwyr llwyth IPVS, yn dibynnu ar sut mae wedi'i ffurfweddu) i ailysgrifennu cyfeiriadau IP cyrchfan y cysylltiadau sy'n mynd i'r cyfeiriad ClusterIP.
Unwaith y bydd Istio wedi'i osod ar glwstwr Kubernetes, nid oes dim yn newid nes ei fod wedi'i alluogi'n benodol ar gyfer defnyddiwr penodol, neu hyd yn oed y gofod enw cyfan, trwy gyflwyno cynhwysydd sidecar mewn codennau arfer. Bydd y cynhwysydd hwn yn deillio enghraifft o Gennad ac yn sefydlu set o reolau iptables i atal traffig sy'n mynd i wasanaethau eraill ac ailgyfeirio'r traffig hwnnw i'r Cennad.
Pan gaiff ei integreiddio â Kubernetes DNS, mae hyn yn golygu y gall ein cod gysylltu yn ôl enw'r gwasanaeth a bod popeth “yn gweithio.” Mewn geiriau eraill, mae ein cod yn codi ymholiadau fel http://api/v1/users/4242yna api datrys cais am 10.97.105.48, bydd rheolau iptables yn rhyng-gipio cysylltiadau o 10.97.105.48 ac yn eu hanfon ymlaen at y dirprwy Envoy lleol, a bydd y dirprwy lleol hwnnw'n anfon y cais ymlaen at yr API backend gwirioneddol. Phew!
Ffrils ychwanegol
Mae Istio hefyd yn darparu amgryptio a dilysu o'r dechrau i'r diwedd trwy mTLS (TLS ar y cyd). Cydran o'r enw Citadel.
Mae yna hefyd gydran Cymysgydd, y gall y Cennad ofyn amdano yr un cais i wneud penderfyniad arbennig am y cais hwnnw yn dibynnu ar ffactorau amrywiol megis penawdau, llwyth ôl-wyneb, ac ati... (peidiwch â phoeni: mae yna lawer o ffyrdd i gadw Mixer i redeg, a hyd yn oed os yw'n damwain, bydd Envoy yn parhau i weithio dirwy fel dirprwy).
Ac, wrth gwrs, soniasom am welededd: mae Envoy yn casglu llawer iawn o fetrigau wrth ddarparu olrhain gwasgaredig. Mewn pensaernïaeth microwasanaethau, os oes rhaid i un cais API basio trwy ficrowasanaethau A, B, C, a D, yna wrth fewngofnodi, bydd olrhain gwasgaredig yn ychwanegu dynodwr unigryw i'r cais ac yn storio'r dynodwr hwn trwy is-geisiadau i'r holl ficrowasanaethau hyn, gan ganiatáu yr holl alwadau cysylltiedig i'w dal, oedi, etc.
Datblygu neu brynu
Mae gan Istio enw am fod yn gymhleth. Mewn cyferbyniad, mae adeiladu'r rhwyll llwybro a ddisgrifiais ar ddechrau'r swydd hon yn gymharol syml gan ddefnyddio offer presennol. Felly, a yw'n gwneud synnwyr i greu eich rhwyll gwasanaeth eich hun yn lle hynny?
Os oes gennym ni anghenion cymedrol (nid oes angen gwelededd, torrwr cylched a chynildeb eraill), yna meddyliwch am ddatblygu ein hofferyn ein hunain. Ond os ydym yn defnyddio Kubernetes, efallai na fydd ei angen hyd yn oed oherwydd bod Kubernetes eisoes yn darparu offer sylfaenol ar gyfer darganfod gwasanaeth a chydbwyso llwythi.
Ond os oes gennym ofynion uwch, yna mae “prynu” rhwyll gwasanaeth yn ymddangos yn opsiwn llawer gwell. (Nid yw hyn bob amser yn "brynu" oherwydd mae Istio yn ffynhonnell agored, ond mae angen i ni fuddsoddi amser peirianneg o hyd i'w ddeall, ei ddefnyddio a'i reoli.)
A ddylwn i ddewis Istio, Linkerd neu Consul Connect?
Hyd yn hyn dim ond am Istio yr ydym wedi siarad, ond nid dyma'r unig rwyll gwasanaeth. Dewis arall poblogaidd - , ac mae mwy .
Beth i'w ddewis?
Yn onest, nid wyf yn gwybod. Ar hyn o bryd nid wyf yn ystyried fy hun yn ddigon cymwys i ateb y cwestiwn hwn. Mae yna ychydig gyda chymhariaeth o'r offer hyn a hyd yn oed .
Un dull addawol yw defnyddio teclyn fel . Mae'n gweithredu haen tynnu dŵr i symleiddio ac uno'r APIs a ddatgelir gan rwyllau gwasanaeth. Yn hytrach na dysgu'r APIs penodol (ac, yn fy marn i, gymharol gymhleth) o rwyllau gwasanaeth gwahanol, gallwn ddefnyddio lluniadau symlach SuperGloo - a newid yn hawdd o un i'r llall, fel pe bai gennym fformat cyfluniad canolradd sy'n disgrifio rhyngwynebau HTTP ac backends galluog. o gynhyrchu'r cyfluniad gwirioneddol ar gyfer Nginx, HAProxy, Traefik, Apache ...
Rwyf wedi dablo ychydig gydag Istio a SuperGloo, ac yn yr erthygl nesaf rwyf am ddangos sut i ychwanegu Istio neu Linkerd i glwstwr presennol gan ddefnyddio SuperGloo, a sut mae'r olaf yn cyflawni'r swydd, hynny yw, yn caniatáu ichi newid o un rhwyll gwasanaeth i un arall heb drosysgrifo ffurfweddau.
Ffynhonnell: hab.com