Kio estas Serva Reto?

Saluton denove!.. Antaŭtagmeze de la komenco de la kurso "Programarkitekto" Ni preparis alian utilan tradukon.

Kio estas Serva Reto?

Servomaŝo estas agordebla, malalt-latenta infrastrukturtavolo kiu estas necesa por pritrakti grandajn volumojn de ret-bazitaj inter-procezaj komunikadoj inter aplikaj programaj interfacoj (APIoj). Service Mesh ebligas rapidan, fidindan kaj sekuran komunikadon inter konteneritaj kaj ofte efemeraj aplikaj infrastrukturservoj. Service Mesh disponigas kapablojn kiel ekzemple servo-malkovro, ŝarĝbalancado, ĉifrado, travidebleco, spurebleco, aŭtentikigo kaj rajtigo, kaj aŭtomata malŝalta ŝablono subteno (cirkvitrompilo).
Servomaŝo estas tipe efektivigita provizante ĉiun servokazaĵon per prokura petskribo, nomita Kromĉaro. Kromĉaro pritrakti komunikadojn inter servoj, monitori kaj solvu sekurecajn problemojn, tio estas, ĉion, kio povas esti abstraktata de individuaj servoj. Tiel, programistoj povas skribi, konservi kaj servi aplikaĵkodon en servoj, kaj sistemadministrantoj povas labori kun la Servo-Maŝo kaj ruli la aplikaĵon.

Istio de Google, IBM kaj Lyft estas nuntempe la plej fama serva mesh-arkitekturo. Kaj Kubernetes, kiu estis origine evoluigita ĉe Guglo, nun estas la nura kontenera orkestra kadro subtenata de Istio. Vendistoj provas krei komerce subtenatajn versiojn de Istio. Estos interese vidi kiajn novajn aferojn ili povas alporti al la malfermkoda projekto.

Tamen, Istio ne estas la sola opcio ĉar aliaj efektivigoj de Service Mesh estas evoluigitaj. Ŝablono sidecar proxy estas la plej populara efektivigo, kiel povas esti juĝita de la projektoj Buoyant, HashiCorp, Solo.io kaj aliaj. Ekzistas ankaŭ alternativaj arkitekturoj: la Netflix-teknologia ilaro estas unu el la aliroj, kie la funkcieco de Service Mesh estas efektivigita per la bibliotekoj Ribbon, Hysterix, Eureka, Archaius, same kiel platformoj kiel Azure Service Fabric.

Service Mesh ankaŭ havas sian propran terminologion por servokomponentoj kaj funkcioj:

  • Uja orkestra kadro. Ĉar pli kaj pli da ujoj estas aldonitaj al la aplika infrastrukturo, estas bezono de aparta ilo por monitorado kaj administrado de ujoj - ujo orkestra kadro. Kubernetes firme okupis ĉi tiun niĉon, tiel ke eĉ ĝiaj ĉefaj konkurantoj Docker Swarm kaj Mesosphere DC/OS ofertas integriĝon kun Kubernetes kiel alternativon.
  • Servoj kaj petskriboj (Kubernetes Pods). Ekzemplo estas ununura kuranta kopio de mikroservo. Foje unu kazo estas unu ujo. En Kubernetes, kazo konsistas el grupeto de sendependaj ujoj nomitaj balgo. Klientoj malofte aliras kazon aŭ balgon rekte; pli ofte, ili aliras servon, kio estas aro de identaj, skaleblaj kaj mistolerantaj okazoj aŭ podoj (kopioj).
  • Sidecar Prokurilo. Sidecar Proxy funkcias kun ununura kazo aŭ pod. La celo de Sidecar Proxy estas direkti aŭ prokuran trafikon venantan de la ujo kun kiu ĝi funkcias kaj redoni trafikon. Sidecar interagas kun aliaj Sidecar Proxies kaj estas administrita per instrumentadkadro. Multaj efektivigoj de Service Mesh uzas Sidecar Proxy por kapti kaj administri la tutan trafikon en kaj ekstere de kazo aŭ pod.
  • Servo Discovery. Kiam kazo bezonas komuniki kun alia servo, ĝi devas trovi (malkovri) sanan kaj disponeblan ekzemplon de la alia servo. Tipe, la petskribo faras DNS-serĉojn. La ujo-instrumentadkadro konservas liston de petskriboj pretaj ricevi petojn kaj disponigas interfacon por DNS-demandoj.
  • Ŝarĝbalancado. Plej multaj kontenaj instrumentadkadroj disponigas ŝarĝbalancadon ĉe tavolo 4 (transporto). Service Mesh efektivigas pli kompleksan ŝarĝbalancadon ĉe tavolo 7 (apliknivelo), riĉa je algoritmoj kaj pli efika en administrado de trafiko. Ŝarĝekvilibraj agordoj povas esti ŝanĝitaj per la API, permesante al vi reĝisori bluverdajn aŭ kanariajn deplojojn.
  • Ĉifrado. Service Mesh povas ĉifri kaj deĉifri petojn kaj respondojn, forigante ĉi tiun ŝarĝon de servoj. Service Mesh ankaŭ povas plibonigi agadon prioritatante aŭ reuzante ekzistantajn persistajn ligojn, reduktante la bezonon de multekosta komputado por krei novajn ligojn. La plej ofta efektivigo de trafika ĉifrado estas reciproka TLS (mTLS), kie publika ŝlosila infrastrukturo (PKI) generas kaj distribuas atestilojn kaj ŝlosilojn por uzo de Sidecar Proxy.
  • Aŭtentikigo kaj Rajtigo. La Servo Mesh povas rajtigi kaj aŭtentikigi petojn faritajn de ekster aŭ ene de la aplikaĵo, sendante nur validigitajn petojn al instancoj.
  • Subteno de aŭtomata malŝalto. Servo Mesh-subtenoj aŭtomata malŝalta ŝablono, kiu izolas malsanajn okazojn kaj poste iom post iom resendas ilin al la aro de sanaj okazoj kiam necese.

La parto de aplikaĵo Service Mesh, kiu administras retan trafikon inter okazoj, estas nomita Datuma Aviadilo. Krei kaj deploji agordon kiu kontrolas konduton Datuma Aviadilo, estas farita uzante apartan Kontrola Ebeno. Kontrola Ebeno tipe inkluzivas aŭ estas dizajnita por konekti al API, CLI aŭ GUI por kontroli la aplikaĵon.

Kio estas Serva Reto?
La Kontrola Ebeno en la Serva Reto distribuas la agordon inter la Sidecar Proxy kaj la Datuma Aviadilo.

Service Mesh-arkitekturo ofte estas uzata por solvi kompleksajn funkciajn problemojn uzante ujojn kaj mikroservojn. Pioniroj en la kampo mikroservoj estas kompanioj kiel Lyft, Netflix kaj Twitter, kiuj provizas stabilajn servojn al milionoj da uzantoj tra la mondo. (Jen detala rigardo al iuj el la arkitekturaj defioj alfrontitaj de Netflix.). Por malpli postulemaj aplikoj, pli simplaj arkitekturoj verŝajne sufiĉos.

Service Mesh-arkitekturo verŝajne iam estos la respondo al ĉiuj aplikaĵaj operacioj kaj liveraj problemoj. Arkitektoj kaj programistoj havas grandegan arsenalon da iloj, kaj nur unu el ili estas martelo, kiu, inter multaj taskoj, devas solvi nur unu - martelantaj najloj. Referenca Arkitekturo de Mikroservoj de NGINX, ekzemple, inkludas plurajn malsamajn modelojn kiuj disponigas kontinuumon de aliroj al solvado de problemoj uzante mikroservojn.

La elementoj, kiuj kuniĝas en arkitekturo de Service Mesh, kiel NGINX, ujoj, Kubernetes kaj mikroservoj kiel arkitektura aliro, povas esti same produktivaj en ne-Servaj Mesh-efektivigoj. Ekzemple, Istio estis desegnita kiel kompleta serva maŝo-arkitekturo, sed ĝia modulareco signifas, ke programistoj povas elekti kaj efektivigi nur la teknologiajn komponentojn, kiujn ili bezonas. Konsiderante ĉi tion, gravas disvolvi klaran komprenon pri la koncepto de Service Mesh, eĉ se vi ne certas, ke vi iam povos plene efektivigi ĝin en via aplikaĵo.

Modulaj monolitoj kaj DDD

fonto: www.habr.com

Aldoni komenton