Hej Habr! Mi prezentas al via atento la tradukon de la artikolo la verkisto Matt Klein.
Ĉi-foje, mi "deziris kaj tradukis" la priskribon de ambaŭ servaj maŝokomponentoj, datumaviadilo kaj kontrolaviadilo. Ĉi tiu priskribo ŝajnis al mi la plej komprenebla kaj interesa, kaj plej grave kondukanta al la kompreno de "Ĉu entute necesas?"
Ĉar la ideo de "Serva reto" fariĝis pli kaj pli populara dum la lastaj du jaroj (Originala artikolo la 10-an de oktobro 2017) kaj la nombro da partoprenantoj en la spaco pliiĝis, mi vidis proporcian pliiĝon de konfuzo inter la tutaĵo. teknika komunumo pri kiel kompari kaj kontrasti malsamajn solvojn.
La situacio estas plej bone resumita per la sekva serio de tweets, kiujn mi skribis en julio:
Serva maŝkonfuzo #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Sendito. Neniu el ili egalas al Istio. Istio estas io tute alia. 1/
La unuaj estas simple datenaviadiloj. Per si mem ili faras nenion. Ili devas esti en humoro por io pli. 2/
Istio estas ekzemplo de kontrolaviadilo kiu ligas la partojn kune. Ĉi tio estas alia tavolo. /fino
La antaŭaj tweets mencias plurajn malsamajn projektojn (Linkerd, NGINX, HAProxy, Envoy kaj Istio), sed pli grave enkondukas la ĝeneralajn konceptojn de datumaviadilo, servomaŝo kaj kontrolaviadilo. En ĉi tiu afiŝo, mi faros paŝon malantaŭen kaj parolos pri tio, kion mi celas per la terminoj "datumaviadilo" kaj "kontrolebeno" je tre alta nivelo, kaj poste parolos pri kiel la terminoj aplikas al la projektoj menciitaj en tweets.
Kio estas servo maŝo, vere?
Figuro 1: Superrigardo pri servo-maŝo
XNUMF-figuro ilustras la koncepton de servomaŝo ĉe ĝia plej baza nivelo. Estas kvar servgrupoj (AD). Ĉiu servokazaĵo estas rilata al loka prokurservilo. Ĉiu rettrafiko (HTTP, REST, gRPC, Redis, ktp.) de ununura aplikaĵkazaĵo estas pasita tra loka prokurilo al la konvenaj eksteraj servaj aretoj. Tiel, la aplikaĵa petskribo ne scias pri la reto kiel tutaĵo kaj nur konas sian lokan prokurilon. Efektive, la distribuita sistemreto estis forigita de la servo.
Datuma aviadilo
En servomaŝo, prokura servilo situanta loke por la aplikaĵo plenumas la sekvajn taskojn:
- Servo-malkovro. Kiuj servoj/aplikoj disponeblas por via aplikaĵo?
- Sankontrolo. Ĉu la servokazaĵoj resenditaj de servo-malkovro estas sanaj kaj pretaj akcepti retan trafikon? Ĉi tio povas inkluzivi kaj aktivajn (ekz. respondan/sankontrolon) kaj pasivan (ekz. uzante 3 sinsekvajn 5xx-erarojn kiel indikon de nesana servostato) sankontrolojn.
- Envojigo. Kiam oni ricevas peton al "/foo" de REST-servo, al kiu servgrupo devus esti sendita la peto?
- Ŝarĝbalancado. Post kiam serva areto estas elektita dum vojigo, al kiu servo-instanco devus esti sendita la peto? Kun kia paŭzo? Kun kiaj agordoj pri cirkvito? Se la peto malsukcesas, ĉu ĝi estu reprovita?
- Aŭtentikigo kaj rajtigo. Por alvenantaj petoj, ĉu la alvoka servo povas esti kriptografie identigita/rajtigita uzante mTLS aŭ iun alian mekanismon? Se ĝi estas rekonita/rajtigita, ĉu ĝi rajtas voki la petitan operacion (finpunkto) sur la servo aŭ ĉu ne aŭtentikigita respondo estu resendita?
- Observeblo. Detalaj statistikoj, protokoloj/protokoloj, kaj distribuitaj spurdatenoj devus esti generitaj por ĉiu peto por ke funkciigistoj povu kompreni distribuitan trafikfluon kaj sencimigajn problemojn kiam ili ekestas.
La datumaviadilo respondecas pri ĉiuj antaŭaj punktoj en la servomaŝo. Fakte, la prokurilo loka al la servo (kromĉaro) estas la datumaviadilo. Alivorte, la datenaviadilo respondecas pri kondiĉe dissendado, plusendado kaj monitorado de ĉiu retpako kiu estas sendita al aŭ de servo.
La kontrolaviadilo
La retabstraktado kiun loka prokurilo disponigas en la datenaviadilo estas magia (?). Tamen, kiel la prokurilo fakte scias pri la "/foo" itinero al servo B? Kiel la servo-malkovraj datumoj, kiuj estas plenigitaj de prokuraj petoj, povas esti uzataj? Kiel estas agordita la parametroj por ŝarĝo-ekvilibro, tempo-tempo, cirkvito-rompado ktp.? Kiel vi disfaldi aplikaĵon uzante la bluan/verdan metodon aŭ la gracian trafikan transiran metodon? Kiu agordas tutsistemajn aŭtentigajn kaj rajtigajn agordojn?
Ĉiuj ĉi-supraj eroj estas sub la kontrolo de la kontrolaviadilo de la servomaŝo. La kontrolaviadilo prenas aron de izolitaj sennaciaj prokuriloj kaj igas ilin distribuita sistemo.
Mi pensas, ke la kialo, ke multaj teknologoj trovas la apartajn konceptojn de datumaviadilo kaj kontrolebeno konfuzaj, estas ĉar por plej multaj homoj la datumaviadilo estas konata dum la kontrolaviadilo estas fremda/nekomprenata. Ni laboras kun fizikaj retaj enkursigiloj kaj ŝaltiloj dum longa tempo. Ni komprenas, ke pakoj/petoj devas iri de punkto A al punkto B kaj ke ni povas uzi aparataron kaj programaron por fari tion. La nova generacio de programaraj prokuriloj estas simple elegantaj versioj de la iloj, kiujn ni uzas delonge.
Figuro 2: Homa kontrolaviadilo
Tamen, ni uzas kontrolaviadilojn dum longa tempo, kvankam la plej multaj retaj telefonistoj eble ne asocias ĉi tiun parton de la sistemo kun iu ajn teknologia komponanto. La kialo estas simpla:
Plej multaj kontrolaviadiloj uzataj hodiaŭ estas... ni.
En figuro 2 montras tion, kion mi nomas la "Homa kontrolaviadilo". En ĉi tiu speco de deplojo, kiu ankoraŭ estas tre ofta, verŝajne grumblema homa funkciigisto kreas senmovajn agordojn - eble per skriptoj - kaj deplojas ilin per iu speciala procezo al ĉiuj prokuriloj. La prokuriloj tiam komencas uzi ĉi tiun agordon kaj komencas prilabori la datumaviadilon uzante la ĝisdatigitajn agordojn.
Figuro 3: Altnivela servo-retra aviadilo
En figuro 3 montras la "plilongigitan" kontrolaviadilon de la servomaŝo. Ĝi konsistas el la sekvaj partoj:
- La homo: Ankoraŭ ekzistas homo (espereble malpli kolera) kiu faras altnivelajn decidojn koncerne la tutan sistemon entute.
- Kontrolaviadilo UI: Persono interagas kun iu speco de uzantinterfaco por kontroli la sistemon. Ĉi tio povus esti retportalo, komandlinia aplikaĵo (CLI), aŭ iu alia interfaco. Uzante la uzantinterfacon, la funkciigisto havas aliron al tutmondaj sistemaj agordaj parametroj kiel ekzemple:
- Deploja kontrolo, blua/verda kaj/aŭ laŭgrada trafika transiro
- Aŭtentigaj kaj Rajtigaj Opcioj
- Specifoj de vojtabelo, ekzemple kiam aplikaĵo A petas informojn pri "/foo" kio okazas
- Ŝarĝbalancilo-agordoj, kiel tempo-tempoj, reprovoj, cirkvitrompiĝaj agordoj, ktp.
- Planilo de laborŝarĝo: Servoj funkcias per la infrastrukturo per iu speco de planado/orkestradsistemo, kiel ekzemple Kubernetes aŭ Nomad. La planisto respondecas pri ŝarĝo de la servo kune kun ĝia loka prokurilo.
- Servo-malkovro. Kiam la planisto komenciĝas kaj haltigas servokazojn, ĝi raportas la sanan staton al la servo-malkovra sistemo.
- Sidecar prokura agordo APIoj : Lokaj prokuriloj dinamike ĉerpas staton de diversaj sistemkomponentoj uzante eventuale konsekvencan modelon sen funkciigistointerveno. La tuta sistemo, konsistanta el ĉiuj aktualaj servokazoj kaj lokaj prokurserviloj, finfine konverĝas al unu ekosistemo. La universala datumaviadilo API de Envoy estas unu ekzemplo de kiel tio funkcias praktike.
Esence, la celo de la kontrolaviadilo estas agordi la politikon kiu finfine estos akceptita per la datenaviadilo. Pli altnivelaj kontrolaviadiloj forigos pli da partoj de iuj sistemoj de la funkciigisto kaj postulos malpli manan operacion, kondiĉe ke ili funkcias ĝuste!...
Datenaviadilo kaj kontrolaviadilo. Resumo de datumoj de aviadilo kontraŭ kontrolo
- Servo mesh datumaviadilo: influas ĉiun paketon/peton en la sistemo. Respondeca pri aplikaĵo/serva malkovro, sankontrolado, enrutado, ŝarĝoekvilibro, aŭtentikigo/rajtigo kaj observebleco.
- Serva maŝo kontrolaviadilo: Provizas politikon kaj agordon por ĉiuj kurantaj datumaviadiloj ene de la servoreto. Ne tuŝas iujn ajn pakaĵojn/petojn en la sistemo. La kontrolaviadilo turnas ĉiujn datenaviadilojn en distribuitan sistemon.
Aktuala projekta pejzaĝo
Kompreninte la supran klarigon, ni rigardu la nunan staton de la servo-maŝo-projekto.
- Datumaj aviadiloj: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Kontrolaj aviadiloj: Istio, Nelson, SmartStack
Prefere ol iri en profundan analizon de ĉiu el la supraj solvoj, mi mallonge traktos kelkajn el la punktoj, kiujn mi kredas, ke nun kaŭzas grandan parton de la konfuzo en la ekosistemo.
Linkerd estis unu el la unuaj datumplanaj prokurserviloj por la servomaŝo komence de 2016 kaj faris mirindan laboron por konsciigi kaj atenton al la servomaŝo desegna modelo. Proksimume 6 monatojn post tio, Envoy aliĝis al Linkerd (kvankam li estis kun Lyft ekde malfrua 2015). Linkerd kaj Envoy estas la du projektoj, kiuj plej ofte estas menciitaj kiam oni diskutas pri servomaŝoj.
Istio estis sciigita en majo 2017. La celoj de la projekto Istio estas tre similaj al la plilongigita kontrolaviadilo montrita enen figuro 3. Sendito por Istio estas la defaŭlta prokurilo. Tiel, Istio estas la kontrolaviadilo, kaj Envoy estas la datenaviadilo. En mallonga tempo, Istio generis multe da ekscito, kaj aliaj datumaviadiloj komencis integriĝi kiel anstataŭaĵo por Envoy (kaj Linkerd kaj NGINX pruvis integriĝon kun Istio). La fakto ke malsamaj datenaviadiloj povas esti uzitaj ene de la sama kontrolaviadilo signifas ke la kontrolaviadilo kaj la datenaviadilo ne estas nepre malloze kunligitaj. API kiel ekzemple la senmarka datenaviadilo API de Envoy povas formi ponton inter du partoj de la sistemo.
Nelson kaj SmartStack helpas plue ilustri la apartigon de la kontrolaviadilo kaj la datenaviadilo. Nelson utiligas Envoy kiel sian prokurilon kaj konstruas fidindan kontrolaviadilon por la servomaŝo bazita sur la HashiCorp-stako, t.e. Nomado, ktp. SmartStack eble estis la unua el nova ondo de servomaŝoj. SmartStack konstruas kontrolaviadilon ĉirkaŭ HAProxy aŭ NGINX, montrante la kapablon malkunligi la kontrolaviadilon de la servomaŝo de la datumaviadilo.
Mikroserva arkitekturo kun serva reto akiras pli kaj pli da atento (prave!), kaj pli kaj pli da projektoj kaj vendistoj komencas labori en ĉi tiu direkto. Dum la venontaj kelkaj jaroj ni vidos multan novigon en kaj la datumaviadilo kaj la kontrolebeno, same kiel plian miksadon de malsamaj komponentoj. Finfine, mikroserva arkitekturo devus iĝi pli travidebla kaj magia (?) por la funkciigisto.
Espereble malpli kaj malpli iritita.
Ŝlosilaĵoj
- Serva maŝo konsistas el du malsamaj partoj: la datenaviadilo kaj la kontrolebeno. Ambaŭ komponantoj estas postulataj, kaj sen ili la sistemo ne funkcios.
- Ĉiuj konas la kontrolaviadilon, kaj ĉe ĉi tiu punkto, la kontrolaviadilo povus esti vi!
- Ĉiuj datenaviadiloj konkuras unu kun la alia pri funkcioj, rendimento, agordeblo kaj etendebleco.
- Ĉiuj kontrolaviadiloj konkuras unu kun la alia en funkcioj, agordebleco, etendebleco kaj facileco de uzo.
- Unu kontrolaviadilo povas enhavi la ĝustajn abstraktaĵojn kaj APIojn tiel ke multoblaj datenaviadiloj povas esti uzitaj.
fonto: www.habr.com