Á internetinu (þjónustunet), og hér er annar. Húrra! En afhverju? Síðan vil ég lýsa þeirri skoðun minni að þjónustunet hefði verið betra fyrir 10 árum, áður en gámapallar eins og Docker og Kubernetes komu til sögunnar. Ég er ekki að segja að mitt sjónarhorn sé betra eða verra en annarra, en þar sem þjónustumöskurnar eru frekar flókin dýr munu mörg sjónarmið hjálpa til við að skilja þau betur.
Ég mun tala um dotCloud vettvanginn, sem var byggður á yfir hundrað örþjónustum og studdi þúsundir forrita í gámum. Ég mun útskýra áskoranirnar sem við lentum í við að þróa og koma því á markað og hvernig þjónustunet gæti (eða gæti ekki) hjálpað.
dotcloud sögu
Ég hef þegar skrifað um sögu dotCloud og val á arkitektúr fyrir þennan vettvang, en hef ekki talað mikið um netlagið. Ef þú vilt ekki lesa um dotCloud, hér er kjarni þess: þetta er PaaS vettvangur sem þjónusta sem gerir viðskiptavinum kleift að keyra fjölbreytt úrval af forritum (Java, PHP, Python...), með stuðningi fyrir fjölbreytt úrval gagnaþjónustu ( MongoDB, MySQL, Redis...) og verkflæði eins og Heroku: þú hleður upp kóðanum þínum á pallinn, hann smíðar gámamyndir og setur þær upp.
Ég mun segja þér hvernig umferð var send á dotCloud pallinn. Ekki vegna þess að það hafi verið sérstaklega flott (þó kerfið hafi virkað vel á sínum tíma!), heldur fyrst og fremst vegna þess að með hjálp nútíma tækja er auðvelt að útfæra slíka hönnun á stuttum tíma af hóflegu teymi ef þeir þurfa leið til að leiða umferð milli fullt af örþjónustum eða fullt af forritum. Þannig geturðu borið saman valkosti: hvað gerist ef þú þróar allt sjálfur eða notar núverandi þjónustunet. Venjulegt val: búðu til þitt eigið eða keyptu.
Umferðarleiðing fyrir hýst forrit
Forrit á dotCloud geta afhjúpað HTTP og TCP endapunkta.
HTTP endapunktar virkt bætt við uppsetningu álagsjafnaðarklasans . Þetta er svipað og auðlindir eru að gera í dag í Kubernetes og álagsjafnara eins og .
Viðskiptavinir tengjast HTTP endapunktum í gegnum viðeigandi lén, að því gefnu að lénið bendi til dotCloud hleðslujafnara. Ekkert sérstakt.
TCP endapunktar tengt gáttarnúmeri, sem síðan er sent til allra gáma í þeim stafla í gegnum umhverfisbreytur.
Viðskiptavinir geta tengst TCP endapunktum með því að nota viðeigandi hýsingarheiti (eitthvað eins og gateway-X.dotcloud.com) og gáttarnúmer.
Þetta hýsingarnafn leysist við „nats“ netþjónklasann (ekki tengt við ) sem mun leiða komandi TCP tengingar í réttan gáma (eða, ef um er að ræða álagsjafnaðar þjónustu, í rétta gáma).
Ef þú þekkir Kubernetes mun þetta líklega minna þig á þjónustu .
Það var engin sambærileg þjónusta á dotCloud pallinum : Til einföldunar gerðist aðgangur að þjónustu á sama hátt bæði innan og utan pallsins.
Allt var skipulagt á einfaldan hátt: upprunalegu útfærslurnar á HTTP og TCP leiðarnetum voru líklega aðeins nokkur hundruð línur af Python. Einföld (ég myndi segja barnaleg) reiknirit sem hafa verið betrumbætt með vexti vettvangsins og tilkomu viðbótarkröfur.
Ekki var þörf á víðtækri endurbreytingu á núverandi kóða. Einkum, getur beint notað heimilisfangið sem fæst með umhverfisbreytum.
Hvernig er þetta frábrugðið nútíma þjónustuneti?
Takmarkað skyggni. Við vorum alls ekki með neinar mælingar fyrir TCP leiðarnetið. Þegar kemur að HTTP leiðarlýsingu hafa nýrri útgáfur nákvæmar HTTP mælingar með villukóðum og viðbragðstíma, en nútíma þjónustunet ganga enn lengra og veita samþættingu við mælikvarðasöfnunarkerfi eins og Prometheus, til dæmis.
Sýnileiki er ekki aðeins mikilvægur frá rekstrarlegu sjónarhorni (til að hjálpa til við að leysa vandamál), heldur einnig þegar nýir eiginleikar eru gefnir út. Talandi um öruggt и .
Skilvirkni leiðar er líka takmörkuð. Í dotCloud leiðarnetinu þurfti öll umferð að fara í gegnum þyrping af sérstökum leiðarhnútum. Þetta þýddi hugsanlega að fara yfir mörg AZ (availability zone) mörk og veruleg aukning á leynd. Ég man eftir bilanaleitarkóða sem gerði yfir hundrað SQL fyrirspurnir á síðu og opnaði nýja tengingu við SQL netþjóninn fyrir hverja fyrirspurn. Þegar hún er keyrð á staðnum hleðst síðan samstundis, en á dotCloud tekur það nokkrar sekúndur að hlaðast því hver TCP tenging (og síðari SQL fyrirspurn) tekur tugi millisekúndna. Í þessu tiltekna tilviki leystu viðvarandi tengingar vandamálið.
Nútíma þjónustunet eru betri í að takast á við slík vandamál. Fyrst og fremst athuga þeir hvort tengingarnar séu fluttar í heimild. Rökfræðilega flæðið er það sama: клиент → меш → сервис, en nú virkar möskvan á staðnum og ekki á ytri hnútum, þannig að tengingin клиент → меш er staðbundið og mjög hratt (míkrósekúndur í stað millisekúndna).
Nútíma þjónustunet innleiðir einnig snjallari reiknirit fyrir álagsjafnvægi. Með því að fylgjast með heilbrigði bakenda geta þeir sent meiri umferð til hraðari bakenda, sem leiðir til betri heildarafkasta.
öryggi er líka betra. DotCloud leiðarnetið keyrði algjörlega á EC2 Classic og dulkóðaði ekki umferðina (með þeirri forsendu að ef einhverjum tókst að setja sniffer á EC2 netumferð, þá ertu nú þegar í miklum vandræðum). Nútíma þjónustunet vernda á gagnsæjan hátt alla umferð okkar, til dæmis með gagnkvæmri TLS auðkenningu og síðari dulkóðun.
Umferðarleiðing fyrir vettvangsþjónustu
Allt í lagi, við höfum rætt umferð á milli forrita, en hvað með dotCloud vettvanginn sjálfan?
Pallurinn sjálfur samanstóð af um hundrað örþjónustum sem bera ábyrgð á ýmsum aðgerðum. Sumir tóku við beiðnum frá öðrum og sumir voru bakgrunnsstarfsmenn sem tengdust annarri þjónustu en þáðu ekki tengingar sjálfir. Í báðum tilvikum verður hver þjónusta að þekkja endapunkta heimilisfönganna sem hún þarf að tengjast.
Margar þjónustur á háu stigi kunna að nota leiðarnetið sem lýst er hér að ofan. Reyndar hafa margar af meira en XNUMX dotCloud örþjónustum verið notaðar sem venjuleg forrit á dotCloud pallinum sjálfum. En fáir þjónustur á lágu stigi (sérstaklega þær sem innleiða þetta leiðarnet) þurftu eitthvað einfaldara, með færri ósjálfstæði (vegna þess að þeir gátu ekki treyst á sjálfir til að vinna - gamla góða kjúklinga- og eggvandamálið).
Þessar lágu, nauðsynlegu þjónustur voru notaðar með því að keyra gáma beint á nokkra lykilhnúta. Á sama tíma var staðlað vettvangsþjónusta ekki viðriðinn: tengill, tímaáætlun og hlaupari. Ef þú vilt bera saman við nútíma gámapalla, þá er það eins og að ræsa stjórnflugvél með docker run beint á hnútana, í stað þess að fela verkefnið til Kubernetes. Það er frekar svipað í hugtakinu , sem notar eða þegar þú ræsir sjálfstæðan klasa.
Þessi þjónusta var afhjúpuð á einfaldan og grófan hátt: YAML skrá skráði nöfn þeirra og heimilisföng; og hver viðskiptavinur þurfti að taka afrit af þessari YAML skrá til dreifingar.
Annars vegar er þetta ákaflega áreiðanlegt, vegna þess að það krefst ekki stuðnings utanaðkomandi lykla/verðmætaverslunar, eins og Zookeeper (mundu, etcd eða Consul var ekki til á þeim tíma). Á hinn bóginn gerði það erfitt að flytja þjónustu. Í hvert skipti sem hreyfing var gerð þurftu allir viðskiptavinir að fá uppfærða YAML skrá (og hugsanlega endurhlaða). Ekki mjög þægilegt!
Í kjölfarið byrjuðum við að innleiða nýtt kerfi, þar sem hver viðskiptavinur tengdist staðbundnum proxy-miðlara. Í stað heimilisfangs og gáttar þarf það aðeins að vita gáttarnúmer þjónustunnar og tengjast í gegnum localhost. Staðbundinn umboðsmaður sér um þessa tengingu og sendir hana áfram á raunverulegan netþjón. Nú þegar stuðningur er færður yfir í aðra vél eða skalast, í stað þess að uppfæra alla viðskiptavini, þarf aðeins að uppfæra alla þessa staðbundna umboð; og ekki er lengur þörf á endurræsingu.
(Einnig var fyrirhugað að hylja umferð í TLS tengingar og setja upp annan proxy-miðlara á móttökumegin, auk þess að athuga TLS vottorð án þátttöku viðtökuþjónustunnar, sem er stillt til að taka við tengingum eingöngu á localhost. Meira um það síðar).
Þetta er mjög svipað frá Airbnb, en mikilvægi munurinn er sá að SmartStack er innleitt og sett í framleiðslu, en innra leiðarkerfi dotCloud var sett í kassa þegar dotCloud breyttist í Docker.
Ég lít persónulega á SmartStack sem einn af forverum kerfa eins og Istio, Linkerd og Consul Connect vegna þess að þau fylgja öll sama mynstur:
- Keyra proxy á hverjum hnút.
- Viðskiptavinir tengjast umboðinu.
- Stýriplanið uppfærir proxy stillinguna þegar bakenda breytist.
- … Hagnaður!
Nútímaleg innleiðing þjónustunets
Ef við þurfum að innleiða svipað rist í dag getum við notað svipaðar reglur. Til dæmis, settu upp innra DNS svæði með því að kortleggja þjónustuheiti við heimilisföng í geimnum 127.0.0.0/8. Keyrðu síðan HAProxy á hverjum klasahnút og samþykktu tengingar á hverju þjónustu heimilisfangi (á því undirneti 127.0.0.0/8) og beina/jafna álaginu í viðeigandi bakenda. Hægt er að stjórna HAProxy stillingum , sem gerir þér kleift að geyma bakendaupplýsingar í etcd eða Consul og ýta sjálfkrafa uppfærðum stillingum í HAProxy þegar þörf krefur.
Svona virkar Istio! En með nokkrum mun:
- Notar í stað HAProxy.
- Vistar grunnstillingar í gegnum Kubernetes API í stað etcd eða Consul.
- Þjónusta er úthlutað vistföngum á innra undirnetinu (Kubernetes ClusterIP vistföng) í stað 127.0.0.0/8.
- Er með viðbótarhluta (Citadel) til að bæta við gagnkvæmri TLS auðkenningu milli viðskiptavinar og netþjóna.
- Styður nýja eiginleika eins og rafrásarrof, dreifða rakningu, dreifingu kanarífugla osfrv.
Við skulum líta fljótt á suma muninn.
Umboð sendiherra
Envoy Proxy var skrifað af Lyft [keppinaut Uber á leigubílamarkaði - u.þ.b. á.]. Það er að mörgu leyti líkt öðrum umboðum (t.d. HAProxy, Nginx, Traefik...), en Lyft skrifaði sína eigin vegna þess að þeir þurftu eiginleika sem aðrir umboðsaðilar hafa ekki og það virtist skynsamlegra að búa til nýjan frekar en að lengja fyrirliggjandi.
Envoy er hægt að nota sjálfur. Ef ég er með ákveðna þjónustu sem þarf að tengjast öðrum þjónustum get ég sett hana upp þannig að hún tengist Envoy og síðan stillt og endurstillt Envoy með staðsetningu annarra þjónustu, á sama tíma og ég fæ fullt af frábærum aukahlutum eins og sýnileika. Í stað sérsniðins viðskiptavinabókasafns eða innspýtingar í símtalsrakningarkóðann sendum við umferð til Envoy og það safnar mælingum fyrir okkur.
En Envoy getur líka starfað sem gagnaplan (gagnaplan) fyrir þjónustunetið. Þetta þýðir að nú fyrir þetta þjónustunet er Envoy stillt stjórna flugvél (stjórnflugvél).
Stjórnarflugvél
Í stjórnunarplaninu treystir Istio á Kubernetes API. Þetta er ekki mjög frábrugðið því að nota confd, sem treystir á etcd eða Consul til að fletta upp setti lykla í gagnageymslunni. Istio skoðar safn Kubernetes auðlinda í gegnum Kubernetes API.
Milli þessa og þá: Mér persónulega fannst þetta gagnlegt sem hljóðar:
Kubernetes API þjónninn er „heimskur þjónn“ sem býður upp á geymslu, útgáfu, staðfestingu, uppfærslu og merkingarfræði API tilfanga.
Istio er hannað til að vinna með Kubernetes; og ef þú vilt nota það utan Kubernetes, þá þarftu að ræsa tilvik af Kubernetes API þjóninum (og etcd hjálparþjónustunni).
Þjónustuföng
Istio treystir á ClusterIP vistföngin sem Kubernetes úthlutar, þannig að Istio þjónustur fá innra heimilisfang (ekki á bilinu 127.0.0.0/8).
Umferð á ClusterIP-tölu fyrir tiltekna þjónustu í Kubernetes klasa án Istio er hleruð af kube-proxy og send til bakenda umboðsins. Ef þú hefur áhuga á tæknilegum upplýsingum, setur kube-proxy upp iptables reglur (eða IPVS hleðslujafnara, eftir því hvernig það er stillt) til að endurskrifa IP-tölur áfangastaðar tenginga sem fara á ClusterIP vistfangið.
Þegar Istio hefur verið sett upp á Kubernetes klasa breytist ekkert fyrr en það er sérstaklega virkt fyrir tiltekinn neytanda, eða jafnvel allt nafnrýmið, með því að kynna ílát sidecar að sérsniðnum belgjum. Þessi gámur mun ræsa Envoy tilvik og setja upp sett af iptables reglum til að stöðva umferð sem fer í aðra þjónustu og beina þeirri umferð til Envoy.
Þegar það er samþætt við Kubernetes DNS þýðir þetta að kóðinn okkar getur tengst með þjónustuheiti og allt „virkar bara“. Með öðrum orðum, kóðann okkar gefur út fyrirspurnir eins og http://api/v1/users/4242þá api leysa úr beiðni um 10.97.105.48, stöðva iptables reglurnar tengingar frá 10.97.105.48 og beina þeim til staðbundins umboðsmanns sendifulltrúa, sem mun framsenda beiðnina til raunverulegs API bakenda. Púff!
Fleiri fínirí
Istio veitir einnig dulkóðun og auðkenningu frá enda til enda í gegnum mTLS (gagnkvæm TLS). Hlutinn sem heitir Citadel.
Það er líka hluti Hrærivél, sem sendimaður getur óskað eftir af hverju beiðni um að taka sérstaka ákvörðun um þá beiðni sem fer eftir ýmsum þáttum eins og hausum, hleðslu á bakenda osfrv... (ekki hafa áhyggjur: það eru mörg verkfæri til að halda blöndunartækinu í gangi, og jafnvel þótt það hrynji mun Envoy halda áfram að vinna sem umboð).
Og auðvitað nefndum við sýnileika: Sendiherra safnar gríðarlegu magni af mælingum á meðan hann veitir dreifða rakningu. Í örþjónustuarkitektúr, ef ein API beiðni þarf að fara í gegnum örþjónustur A, B, C og D, þá mun dreifð rakning við innskráningu bæta einkvæmu auðkenni við beiðnina og geyma þetta auðkenni í gegnum undirbeiðnir í allar þessar örþjónustur, sem gerir kleift að þú til að fanga öll tengd símtöl, tafir þeirra osfrv.
Þróa eða kaupa
Istio hefur orð á sér fyrir að vera flókið kerfi. Aftur á móti er tiltölulega auðvelt að byggja upp leiðarnetið sem ég lýsti í upphafi þessarar færslu með núverandi verkfærum. Svo, er skynsamlegt að búa til þitt eigið þjónustunet í staðinn?
Ef við höfum hóflegar þarfir (við þurfum ekki skyggni, aflrofa og aðra fínleika), þá koma hugsanir um að þróa okkar eigið tól. En ef við erum að nota Kubernetes, gæti það ekki einu sinni verið nauðsynlegt vegna þess að Kubernetes veitir nú þegar grunnverkfærin fyrir þjónustuuppgötvun og álagsjafnvægi.
En ef við höfum háþróaðar kröfur, þá virðist það vera miklu betri kostur að „kaupa“ þjónustunet. (Þetta eru ekki alltaf "kaup" þar sem Istio er opinn uppspretta, en við þurfum samt að fjárfesta verkfræðitíma til að skilja, dreifa og stjórna því.)
Hvað á að velja: Istio, Linkerd eða Consul Connect?
Hingað til höfum við aðeins talað um Istio, en það er ekki eina þjónustunetið. Vinsæli valkosturinn er , en það er meira .
Hvað á að velja?
Satt að segja veit ég það ekki. Í augnablikinu tel ég mig ekki nógu hæfan til að svara þessari spurningu. Það eru nokkrir með samanburði á þessum verkfærum og jafnvel .
Ein efnileg aðferð er að nota tæki eins og . Það útfærir útdráttarlag til að einfalda og sameina API sem veitt eru af þjónustumöskvum. Í stað þess að læra sérstök (og, að mínu mati, tiltölulega flókin) API ýmissa þjónustuneta, getum við notað einfaldari SuperGloo smíðar - og auðveldlega skipt úr einu yfir í annað, eins og við værum með millistillingarsnið sem lýsir HTTP viðmótum og bakenda. fær um að búa til raunverulega stillingu fyrir Nginx, HAProxy, Traefik, Apache ...
Ég lék mér aðeins að Istio og SuperGloo og í næstu grein vil ég sýna hvernig á að bæta Istio eða Linkerd við núverandi þyrping með SuperGloo, og hvernig sá síðarnefndi mun gera starf sitt, það er að segja að það gerir þér kleift að skipta úr eitt þjónustunet yfir í annað án þess að endurskrifa stillingar.
Heimild: www.habr.com