Þjónustunet gagnaplans vs stjórnunarplans

Hæ Habr! Ég kynni þér þýðingu greinarinnar „Þjónustunetsgagnaplan vs stýriplan“ höfundurinn Matt Klein.

Þjónustunet gagnaplans vs stjórnunarplans

Að þessu sinni „vildi ég og þýddi“ lýsinguna á báðum þjónustumöskvum hlutum, gagnaplani og stjórnplani. Þessi lýsing fannst mér skiljanlegasta og áhugaverðasta, og síðast en ekki síst leiðandi til skilnings á "Er það yfirhöfuð nauðsynlegt?"

Þar sem hugmyndin um „Þjónustunet“ hefur orðið sífellt vinsælli á síðustu tveimur árum (Upprunaleg grein 10. október 2017) og fjöldi þátttakenda í rýminu hefur aukist, hef ég séð aukningu á ruglingi meðal alls tæknisamfélag um hvernig á að bera saman og andstæða mismunandi lausnir.

Staðan er best dregin saman með eftirfarandi röð af tístum sem ég skrifaði í júlí:

Þjónustunet rugl #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Sendiherra. Enginn þeirra er jafn Istio. Istio er eitthvað allt annað. 1 /

Fyrstu eru einfaldlega gagnaflugvélar. Ein og sér gera þeir ekki neitt. Þeir hljóta að vera í skapi fyrir eitthvað meira. 2/

Istio er dæmi um stjórnplan sem tengir hlutana saman. Þetta er annað lag. /lok

Í fyrri tístunum er minnst á nokkur mismunandi verkefni (Linkerd, NGINX, HAProxy, Envoy og Istio), en mikilvægara að kynna almennu hugtökin gagnaplan, þjónustunet og stjórnplan. Í þessari færslu mun ég stíga skref til baka og tala um hvað ég á við með hugtökunum „gagnaflugvél“ og „stjórnplan“ á mjög háu stigi og tala síðan um hvernig skilmálar eiga við um verkefnin sem nefnd eru í tístum.

Hvað er þjónustunet, eiginlega?

Þjónustunet gagnaplans vs stjórnunarplans
Mynd 1: Yfirlit yfir þjónustunet

Mynd 1 sýnir hugmyndina um þjónustunet á grunnstigi þess. Það eru fjórir þjónustuklasar (AD). Hvert þjónustutilvik er tengt staðbundnum proxy-miðlara. Öll netumferð (HTTP, REST, gRPC, Redis, o.s.frv.) frá einu forritatilviki fer í gegnum staðbundið umboð til viðeigandi ytri þjónustuklasa. Þannig er forritatilvikið ekki meðvitað um netið í heild sinni og aðeins meðvitað um staðbundið umboð þess. Í raun var dreifða kerfisnetið fjarlægt úr þjónustunni.

Gagnaplan

Í þjónustuneti framkvæmir proxy-þjónn sem staðsettur er á staðnum fyrir forritið eftirfarandi verkefni:

  • Þjónustuuppgötvun. Hvaða þjónusta/forrit eru í boði fyrir umsókn þína?
  • Heilsufarsskoðun. Eru þjónustutilvikin sem skilað er með þjónustuuppgötvun heilbrigð og tilbúin til að taka við netumferð? Þetta getur falið í sér bæði virkt (td svar/heilsuskoðun) og óvirkt (td með því að nota 3 5xx villur í röð sem vísbendingu um óhollt þjónustuástand) heilsufarsskoðun.
  • Leiðsögn. Þegar beðið er um "/foo" frá REST þjónustu, til hvaða þjónustuklasa á að senda beiðnina?
  • Álagsjafnvægi. Þegar þjónustuklasi hefur verið valinn við leiðsögn, til hvaða þjónustutilviks á að senda beiðnina? Með hvaða tímamörkum? Með hvaða hringrásarstillingum? Ef beiðnin mistekst, ætti að reyna hana aftur?
  • Staðfesting og heimild. Fyrir komandi beiðnir, er hægt að auðkenna/heimila hringingarþjónustuna með því að nota mTLS eða einhvern annan búnað? Ef það er viðurkennt/heimilt, er leyfilegt að hringja í umbeðna aðgerð (endapunkt) á þjónustunni eða á að skila óstaðfestu svari?
  • Athugunarhæfni. Nákvæm tölfræði, annálar/skrár og dreifð rekjagögn ættu að vera búin til fyrir hverja beiðni svo að rekstraraðilar geti skilið dreifða umferðarflæði og villuleit þegar þau koma upp.

Gagnaflugvélin ber ábyrgð á öllum fyrri punktum í þjónustunetinu. Reyndar er staðgengill umboðsþjónustunnar (hliðarvagn) gagnaplanið. Með öðrum orðum, gagnaflugvélin ber ábyrgð á skilyrtri útsendingu, áframsendingu og eftirliti með hverjum netpakka sem er sendur til eða frá þjónustu.

Stjórnarflugvélin

Netútdrátturinn sem staðbundinn umboð veitir í gagnaplaninu er töfrandi(?). Hins vegar, hvernig veit umboðsmaðurinn raunverulega um "/foo" leiðina til þjónustu B? Hvernig er hægt að nota þjónustuuppgötvunargögnin sem fyllt er út með umboðsbeiðnum? Hvernig eru færibreyturnar stilltar fyrir álagsjafnvægi, tímamörk, rafrásarrof o.s.frv.? Hvernig setur þú upp forrit með því að nota bláa/grænu aðferðina eða þokkafulla umferðarskiptaaðferð? Hver stillir auðkenningar- og heimildarstillingar fyrir allt kerfið?

Öll ofangreind atriði eru undir stjórn stjórnborðs þjónustunetsins. Stjórnarflugvélin tekur sett af einangruðum ríkislausum umboðum og breytir þeim í dreifð kerfi.

Ég held að ástæðan fyrir því að mörgum tæknifræðingum finnst aðskilin hugtök gagnaplans og stjórnflugvélar ruglingsleg sé sú að fyrir flesta er gagnaflugvélin kunnugleg á meðan stjórnplanið er framandi/óskilið. Við höfum verið að vinna með beinar og rofa fyrir netkerfi í langan tíma. Við skiljum að pakkar/beiðnir þurfa að fara frá punkti A til punktar B og að við getum notað vélbúnað og hugbúnað til að gera þetta. Nýja kynslóðin af hugbúnaðarumboðum eru einfaldlega fínar útgáfur af verkfærunum sem við höfum notað í langan tíma.

Þjónustunet gagnaplans vs stjórnunarplans
Mynd 2: Stjórnflugvél manna

Hins vegar höfum við notað stjórnflugvélar í langan tíma, þó að flestir símafyrirtæki tengja þennan hluta kerfisins við neinn tæknihluta. Ástæðan er einföld:
Flestar stjórnflugvélar sem eru í notkun í dag eru... við.

Á 2. mynd sýnir það sem ég kalla „Mannleg stjórnflugvél“. Í þessari tegund dreifingar, sem er enn mjög algeng, býr líklega pirraður mannlegur rekstraraðili til kyrrstæðar stillingar - hugsanlega með forskriftum - og sendir þær í gegnum sérstakt ferli til allra umboðsaðila. Umboðsmennirnir byrja síðan að nota þessa stillingu og byrja að vinna úr gagnaplaninu með því að nota uppfærðar stillingar.

Þjónustunet gagnaplans vs stjórnunarplans
Mynd 3: Stýriflugvél fyrir háþróaða þjónustumöskv

Á 3. mynd sýnir „útvíkkað“ stjórnplan þjónustunetsins. Það samanstendur af eftirfarandi hlutum:

  • Hið mannlega: Það er enn manneskja (vonandi minna reiður) sem tekur ákvarðanir á háu stigi varðandi allt kerfið í heild sinni.
  • HÍ stýriplani: Einstaklingur hefur samskipti við einhvers konar notendaviðmót til að stjórna kerfinu. Þetta gæti verið vefgátt, skipanalínuforrit (CLI) eða annað viðmót. Með því að nota notendaviðmótið hefur rekstraraðilinn aðgang að alþjóðlegum kerfisstillingarbreytum eins og:
    • Dreifingarstýring, blá/græn og/eða hægfara umferðarskipti
    • Auðkenningar- og heimildarvalkostir
    • Leiðartöfluforskriftir, til dæmis þegar forrit A biður um upplýsingar um "/foo" hvað gerist
    • Hlaða jafnvægisstillingar, svo sem tímamörk, endurtilraunir, stillingar fyrir rafrásarrof o.s.frv.
  • Vinnuálagsáætlun: Þjónusta er keyrð á innviðum í gegnum einhvers konar tímasetningar/hljómsveitarkerfi, eins og Kubernetes eða Nomad. Tímagerðarmaðurinn er ábyrgur fyrir því að hlaða þjónustunni ásamt staðbundnum umboðsmanni hennar.
  • Þjónustuuppgötvun. Þegar tímaáætlunarmaðurinn byrjar og stöðvar þjónustutilvik tilkynnir hann heilsufarsstöðuna til þjónustuuppgötvunarkerfisins.
  • Sidecar proxy stillingar API : Staðbundnir umboðsaðilar draga ástand úr ýmsum kerfishlutum með því að nota að lokum samræmt líkan án afskipta rekstraraðila. Allt kerfið, sem samanstendur af öllum núverandi þjónustutilvikum og staðbundnum proxy-þjónum, rennur að lokum saman í eitt vistkerfi. Envoy's universal data plane API er eitt dæmi um hvernig þetta virkar í reynd.

Í meginatriðum er tilgangur stjórnunarplansins að setja stefnuna sem að lokum verður samþykkt af gagnaplaninu. Fullkomnari stjórnflugvélar munu fjarlægja fleiri hluta sumra kerfa frá flugrekandanum og krefjast minni handvirkrar notkunar, að því tilskildu að þær virki rétt!...

Gagnaplan og stjórnplan. Samantekt gagnaplans vs stjórnflugs

  • Þjónustunet gagnaplan: Hefur áhrif á alla pakka/beiðnir í kerfinu. Ábyrgð fyrir uppgötvun forrita/þjónustu, heilsufarsskoðun, leiðarlýsingu, álagsjafnvægi, auðkenningu/heimild og athugun.
  • Stýriflugvél fyrir þjónustunet: Veitir stefnu og stillingar fyrir allar keyrandi gagnavélar innan þjónustunetsins. Snertir ekki neina pakka/beiðnir á kerfinu. Stjórnarplanið breytir öllum gagnaplanum í dreifð kerfi.

Núverandi verkefni landslag

Eftir að hafa skilið skýringuna hér að ofan skulum við skoða núverandi stöðu þjónustunetsverkefnisins.

  • Gagnaflugvélar: Linkerd, NGINX, HAProxy, Envoy, Traefik
  • Stjórna flugvélum: Istio, Nelson, SmartStack

Frekar en að fara í ítarlega greiningu á hverri af lausnunum hér að ofan mun ég fjalla stuttlega um nokkur atriði sem ég tel að valdi miklu af ruglingi í vistkerfinu núna.

Linkerd var einn af fyrstu umboðsþjónum gagnaplans fyrir þjónustunetið snemma árs 2016 og hefur unnið frábært starf við að vekja athygli og athygli á hönnunarlíkaninu fyrir þjónustunetið. Um það bil 6 mánuðum eftir það gekk Envoy til liðs við Linkerd (þó hann hafi verið hjá Lyft síðan seint á árinu 2015). Linkerd og Envoy eru þau tvö verkefni sem oftast eru nefnd þegar rætt er um þjónustunet.

Istio var tilkynnt í maí 2017. Markmið Istio verkefnisins eru mjög svipuð útvíkkuðu stjórnborðinu sem sýnt er í 3. mynd. Sendiboði fyrir Istio er sjálfgefinn umboðsmaður. Þannig er Istio stjórnborðið og Sendiherra er gagnaplanið. Á stuttum tíma vakti Istio mikla spennu og aðrar gagnaflugvélar fóru að samþættast í stað Envoy (bæði Linkerd og NGINX sýndu samþættingu við Istio). Sú staðreynd að hægt er að nota mismunandi gagnaplan innan sama stjórnplans þýðir að stjórnplanið og gagnaplanið eru ekki endilega þétt tengd. API eins og Envoy almenna gagnaplans API getur myndað brú á milli tveggja hluta kerfisins.

Nelson og SmartStack hjálpa til við að sýna frekar aðskilnað stjórnborðsins og gagnaplansins. Nelson notar Envoy sem umboð sitt og byggir áreiðanlega stjórnvél fyrir þjónustunetið sem byggir á HashiCorp staflanum, þ.e. Nomad o.s.frv. SmartStack var kannski sá fyrsti af nýrri bylgju þjónustuneta. SmartStack byggir stjórnplan utan um HAProxy eða NGINX, sem sýnir getu til að aftengja stjórnplanið frá þjónustunetinu frá gagnaplaninu.

Örþjónustuarkitektúr með þjónustuneti fær sífellt meiri athygli (með réttu!), og fleiri og fleiri verkefni og seljendur eru farin að vinna í þessa átt. Á næstu árum munum við sjá mikla nýsköpun bæði á gagnaplaninu og stjórnplaninu, auk frekari blöndunar mismunandi íhluta. Að lokum ætti örþjónustuarkitektúr að verða gagnsærri og töfrandi (?) fyrir rekstraraðilann.
Vonandi minna og minna pirraður.

Helstu veitingar

  • Þjónustunet samanstendur af tveimur mismunandi hlutum: gagnaplaninu og stjórnplaninu. Báðir íhlutir eru nauðsynlegir og án þeirra mun kerfið ekki virka.
  • Allir kannast við stjórnflugvélina og á þessum tímapunkti gæti stjórnflugvélin verið þú!
  • Öll gagnaflug keppa sín á milli um eiginleika, frammistöðu, stillanleika og stækkanleika.
  • Allar stjórnvélar keppa sín á milli hvað varðar eiginleika, stillanleika, stækkanleika og auðvelda notkun.
  • Eitt stjórnplan getur innihaldið réttar útdrætti og API svo hægt sé að nota mörg gagnaplan.

Heimild: www.habr.com

Bæta við athugasemd