Service Mesh estas konata arkitektura ŝablono por integri mikroservojn kaj migri al nuba infrastrukturo. Hodiaŭ en la nubo-ujo estas sufiĉe malfacile fari sen ĝi. Pluraj malfermfontaj servomaŝo-efektivigoj jam haveblas sur la merkato, sed ilia funkcieco, fidindeco kaj sekureco ne ĉiam sufiĉas, precipe se temas pri la postuloj de grandaj financaj kompanioj tra la lando. Tial ni ĉe Sbertech decidis personecigi Service Mesh kaj volas paroli pri kio estas bonega pri Service Mesh, kio ne estas tiel bonega, kaj kion ni faros pri ĝi.
La populareco de la servo Mesh-ŝablono kreskas kun la populareco de nubaj teknologioj. Ĝi estas diligenta infrastruktura tavolo, kiu simpligas la interagadon inter malsamaj retaj servoj. Modernaj nubaj aplikaĵoj konsistas el centoj aŭ eĉ miloj da tiaj servoj, ĉiu el kiuj povas havi milojn da kopioj.
La interago inter kaj administrado de ĉi tiuj servoj estas ŝlosila tasko de la Servo-Maŝo. Fakte, ĉi tio estas retmodelo de multaj prokuriloj, administritaj centre kaj plenumanta aron da tre utilaj funkcioj.
Sur la prokura nivelo (datumaviadilo):
- Asigni kaj distribuante vojajn kaj trafikajn ekvilibrajn politikojn
- Distribuado de ŝlosiloj, atestiloj, ĵetonoj
- Kolekto de telemetrio, generacio de monitoraj metrikoj
- Integriĝo kun sekureco kaj monitora infrastrukturo
Je la kontrolebena nivelo:
- Aplikante vojajn kaj trafikajn ekvilibrajn politikojn
- Administri reprovojn kaj paŭzojn, detektante "mortintajn" nodojn (cirkvita rompo), administri injektajn misfunkciadojn kaj certigi servoreziston per aliaj mekanismoj
- Voku aŭtentikigon/rajtigon
- Forigo de metrikoj (observebleco)
La gamo de uzantoj interesitaj pri la disvolviĝo de ĉi tiu teknologio estas tre vasta - de malgrandaj noventreprenoj ĝis grandaj interretaj korporacioj, ekzemple PayPal.
Kial Service Mesh bezonas en la kompania sektoro?
Estas multaj klaraj avantaĝoj uzi Servan Reton. Antaŭ ĉio, ĝi estas simple oportuna por programistoj: por skribi kodon aperas teknologia platformo, kiu signife simpligas integriĝon en la nuba infrastrukturo pro la fakto ke la transporta tavolo estas tute izolita de aplika logiko.
Krome, Service Mesh simpligas la rilaton inter provizantoj kaj konsumantoj. Hodiaŭ, estas multe pli facile por API-provizantoj kaj konsumantoj konsenti pri interfacoj kaj kontraktoj memstare, sen impliki specialan integrigan peranto kaj arbitracianto - la entreprena servobuso. Ĉi tiu aliro signife influas du indikilojn. La rapideco alporti novan funkciecon al merkato (tempo-al-merkato) pliiĝas, sed samtempe la kosto de la solvo pliiĝas, ĉar integriĝo devas esti farita sendepende. La uzo de Service Mesh fare de komercaj funkciecaj evoluteamoj helpas konservi ekvilibron ĉi tie. Kiel rezulto, API-provizantoj povas koncentriĝi ekskluzive sur la aplikaĵo-komponento de sia servo kaj simple publikigi ĝin en la Servo-Reto - la API tuj fariĝos disponebla por ĉiuj klientoj, kaj la kvalito de integriĝo estos produktada preta kaj ne postulos eĉ unu solan. linio de plia kodo.
La sekva avantaĝo estas tio la programisto, uzante Service Mesh, temigas nur komercan funkciecon — sur la produkto prefere ol la teknologia komponento de ĝia servo. Ekzemple, vi ne plu devas pensi pri tio, ke en situacio, kie servo estas vokita tra la reto, ie povas okazi malsukceso de konekto. Krome, Service Mesh helpas ekvilibrigi trafikon inter kopioj de la sama servo: se unu el la kopioj "mortas", la sistemo ŝanĝos la tutan trafikon al la ceteraj vivkopioj.
Servo Mesh - ĉi tio estas bona bazo por krei distribuitajn aplikaĵojn, kiu kaŝas de la kliento la detalojn pri liverado de vokoj al siaj servoj kaj interne kaj ekstere. Ĉiuj aplikaĵoj uzantaj Service Mesh estas izolitaj je la transportnivelo kaj de la reto kaj unu de la alia: ne ekzistas komunikado inter ili. En ĉi tiu kazo, la programisto ricevas plenan kontrolon de siaj servoj.
Oni notu ke Ĝisdatigi distribuitajn aplikaĵojn en serva mesh-medio fariĝas pli facila. Ekzemple, blua/verda deplojo, en kiu du aplikaĵmedioj estas disponeblaj por instalado, unu el kiuj ne estas ĝisdatigita kaj estas en standby reĝimo. Reveni al la antaŭa versio en la okazo de malsukcesa eldono estas farita de speciala enkursigilo, kies rolo Service Mesh bone traktas.. Por testi la novan version, vi povas uzi kanaria liberigo — ŝanĝu al la nova versio nur 10% de trafiko aŭ petoj de pilotgrupo de klientoj. La ĉefa trafiko iras al la malnova versio, nenio rompas.
Ankaŭ Service Mesh donas al ni realtempan SLA-kontrolon. La distribuita prokura sistemo ne permesos al la servo malsukcesi kiam unu el la klientoj superas la kvoton atribuitan al ĝi. Se API-traigo estas limigita, neniu povos superforti ĝin per granda nombro da transakcioj: la Servo-Maŝo staras antaŭ la servo kaj ne permesas nenecesan trafikon. Ĝi simple batalos reen en la integriga tavolo, kaj la servoj mem daŭre funkcios sen rimarki ĝin.
Se firmao volas redukti kostojn por la disvolviĝo de integrigaj solvoj, Service Mesh ankaŭ helpas: Vi povas ŝanĝi al ĝia malfermfonta versio de komercaj produktoj. Nia Enterprise Service Mesh baziĝas sur la malfermfonta versio de Service Mesh.
Alia avantaĝo - havebleco de ununura plenkreska aro de integrigaj servoj. Ĉar ĉiu integriĝo estas konstruita per ĉi tiu mezprogramo, ni povas administri la tutan integrigan trafikon kaj ligojn inter aplikaĵoj, kiuj formas la komercan kernon de la kompanio. Ĝi estas tre komforta.
Fine Service Mesh instigas kompanion moviĝi al dinamika infrastrukturo. Nun multaj rigardas al kontenerigo. Tranĉi monoliton en mikroservojn, efektivigante ĉion ĉi bele - la temo pliiĝas. Sed kiam vi provas translokigi sistemon kiu estis en produktado dum multaj jaroj al nova platformo, vi tuj renkontas kelkajn problemojn: puŝi ĉion en ujojn kaj deploji ĝin sur la platformo ne estas facila. Kaj la efektivigo, sinkronigado kaj interago de ĉi tiuj distribuitaj komponantoj estas alia tre kompleksa temo. Kiel ili komunikiĝos unu kun la alia? Ĉu estos kaskadaj fiaskoj? Servo Mesh permesas vin solvi iujn ĉi tiujn problemojn kaj faciligi migradon de la malnova arkitekturo al la nova pro la fakto, ke vi povas forgesi pri la reto-interŝanĝa logiko.
Kial vi bezonas personigon de Service Mesh?
En nia firmao, centoj da sistemoj kaj moduloj kunekzistas, kaj la rultempo estas tre ŝarĝita. Do simpla ŝablono de unu sistemo vokas alian kaj ricevas respondon ne sufiĉas, ĉar en produktado ni volas pli. Kion alian vi bezonas de entreprena serva reto?
Servo pri traktado de eventoj
Ni imagu, ke ni devas fari realtempan evento-traktadon - sistemon, kiu analizas la agojn de la kliento en reala tempo kaj povas tuj fari al li koncernan oferton. Por efektivigi similan funkciojn, uzu arkitektura ŝablono nomita okazaĵ-movita arkitekturo (EDA). Neniu el la nunaj Servaj Retoj denaske subtenas tiajn ŝablonojn, sed ĉi tio estas tre grava, precipe por banko!
Estas sufiĉe strange, ke Remote Procedure Call (RPC) estas subtenata de ĉiuj versioj de Service Mesh, sed ili ne amikas kun EDA. Ĉar Service Mesh estas speco de moderna distribuita integriĝo, kaj EDA estas tre grava arkitektura ŝablono, kiu permesas vin fari unikajn aferojn laŭ klienta sperto.
Nia Enterprise Service Mesh devus solvi ĉi tiun problemon. Krome, ni volas vidi en ĝi la efektivigon de garantiita livero, streaming kaj kompleksa evento-prilaborado uzante diversajn filtrilojn kaj ŝablonojn.
Servo de dosiertransigo
Krom EDA, estus bone povi translokigi dosierojn: en Enterprise-skalo, tre ofte nur dosiera integriĝo eblas. Aparte, la arkitektura ŝablono ETL (Extract, Transform, Load) estas uzata. En ĝi, kiel regulo, ĉiuj interŝanĝas dosierojn ekskluzive: oni uzas grandajn datumojn, kio estas nepraktike enpuŝi apartajn petojn. La kapablo denaske subteni dosiertranslokigojn en la Enterprise Service Mesh donas al vi la flekseblecon, kiun via komerco bezonas.
Servo de orkestrado
Grandaj organizoj preskaŭ ĉiam havas malsamajn teamojn farantajn malsamajn produktojn. Ekzemple, en banko, iuj teamoj laboras kun deponejoj, dum aliaj laboras kun pruntproduktoj, kaj estas sufiĉe multaj tiaj kazoj. Ĉi tiuj estas malsamaj homoj, malsamaj teamoj, kiuj faras siajn produktojn, disvolvas siajn APIojn kaj provizas ilin al aliaj. Kaj tre ofte necesas formi ĉi tiujn servojn, kaj ankaŭ efektivigi kompleksan logikon por sinsekve voki aron da API-oj. Por solvi ĉi tiun problemon, vi bezonas solvon en la integriga tavolo, kiu simpligos ĉi tiun tutan kunmetitan logikon (voki plurajn API-ojn, priskribante la petan itineron, ktp.). Ĉi tio estas la orkestra servo en la Enterprise Service Mesh.
AI kaj ML
Kiam mikroservoj komunikas per ununura integriga tavolo, la Servo Mesh nature scias ĉion pri la vokoj de ĉiu servo. Ni kolektas telemetrion: kiu vokis kiun, kiam, dum kiom da tempo, kiom da fojoj, ktp. Kiam ekzistas centoj da miloj da ĉi tiuj servoj, kaj miliardoj da vokoj, tiam ĉio ĉi amasiĝas kaj formas Big Data. Ĉi tiuj datumoj povas esti analizitaj per AI, maŝinlernado ktp., kaj tiam iuj utilaj aferoj povas esti faritaj surbaze de la analizrezultoj. Estus konvene almenaŭ parte transdoni la kontrolon de ĉi tiu tuta rettrafiko kaj aplikaĵvokoj integritaj en la Servo Mesh al artefarita inteligenteco.
API Gateway Servo
Tipe, Service Mesh havas prokurojn kaj servojn, kiuj parolas inter si ene de fidinda perimetro. Sed ekzistas ankaŭ eksteraj kontraŭpartioj. La postuloj por API-oj elmontritaj al ĉi tiu grupo de konsumantoj estas multe pli severaj. Ni dividas ĉi tiun taskon en du ĉefajn partojn.
- Sekureco. Problemoj rilataj al ddos, vundebleco de protokoloj, aplikoj, operaciumoj, ktp.
- Skalo. Kiam la nombro da API-oj, kiuj devas esti servitaj al klientoj, atingas milojn aŭ eĉ centojn da miloj, necesas ia administra ilo por ĉi tiu aro de API-oj. Vi devas konstante kontroli la API: ĉu ili funkcias aŭ ne, kia estas ilia stato, kia trafiko fluas, kiaj statistikoj, ktp. API-enirejo devus trakti ĉi tiun taskon dum igante la tutan procezon regebla kaj sekura. Danke al ĉi tiu komponanto, Enterprise Service Mesh lernas facile publikigi ambaŭ internajn kaj eksterajn APIojn.
Subtena servo por specifaj protokoloj kaj datumformatoj (AS-enirejo)
Nuntempe, plej multaj solvoj de Service Mesh povas funkcii denaske nur kun HTTP kaj HTTP2-trafiko aŭ en reduktita reĝimo ĉe la TCP/IP-nivelo. La Enterprise Service Mesh aperas kun multaj aliaj tre specifaj datumtransiga protokoloj. Iuj sistemoj povas uzi mesaĝajn makleristojn, aliaj estas integritaj ĉe la datumbaza nivelo. Se la firmao havas SAP, tiam ĝi ankaŭ povas uzi sian propran integrigan sistemon. Krome, ĉio ĉi funkcias kaj estas grava parto de la komerco.
Vi ne povas simple diri: "Ni forlasu heredaĵon kaj kreu novajn sistemojn, kiuj povas uzi Service Mesh." Por konekti ĉiujn malnovajn sistemojn kun la novaj (sur mikroserva arkitekturo), sistemoj, kiuj povas uzi Service Mesh, bezonos ian adaptilon, peranton, enirejon. Konsentu, estus bone se ĝi venus en skatolo kune kun la servo. La AC-enirejo povas subteni ajnan integrigan opcion. Imagu, vi simple instalas Enterprise Service Mesh kaj ĝi pretas interagi kun ĉiuj protokoloj, kiujn vi bezonas. Ĉi tiu aliro estas tre grava por ni.
Ĉi tio estas proksimume kiel ni imagas la kompanian version de Service Mesh (Enterprise Service Mesh). La priskribita personigo solvas la plej multajn problemojn, kiuj aperas kiam oni provas uzi pretajn malfermfontajn versiojn de la integriga platformo. Enkondukita antaŭ nur kelkaj jaroj, Service Mesh-arkitekturo daŭre evoluas, kaj ni ĝojas povi kontribui al ĝia evoluo. Ni esperas, ke nia sperto estos utila al vi.
fonto: www.habr.com