Përshëndetje përsëri!.. Në prag të fillimit të kursit Ne kemi përgatitur një përkthim tjetër të dobishëm.
Një rrjetë shërbimi është një shtresë infrastrukture e konfigurueshme, me vonesë të ulët, e nevojshme për të trajtuar vëllime të mëdha të komunikimeve ndër-procesore të bazuara në rrjet ndërmjet ndërfaqeve të programimit të aplikacioneve (API). Service Mesh mundëson komunikim të shpejtë, të besueshëm dhe të sigurt midis shërbimeve të infrastrukturës së aplikimit të kontejneruar dhe shpesh kalimtar. Service Mesh ofron aftësi të tilla si zbulimi i shërbimit, balancimi i ngarkesës, enkriptimi, transparenca, gjurmueshmëria, vërtetimi dhe autorizimi dhe mbështetje për modelin e mbylljes automatike (ndërprerës).
Një rrjetë shërbimi zakonisht zbatohet duke i siguruar çdo shembull shërbimi një shembull proxy, të quajtur Karta anësore. Karta anësore trajton komunikimet ndërmjet shërbimeve, monitoron dhe zgjidh çështjet e sigurisë, domethënë gjithçka që mund të abstragohet nga shërbimet individuale. Në këtë mënyrë, zhvilluesit mund të shkruajnë, mirëmbajnë dhe shërbejnë kodin e aplikacionit në shërbime, dhe administratorët e sistemit mund të punojnë me Service Mesh dhe të ekzekutojnë aplikacionin.
Istio nga Google, IBM dhe Lyft është aktualisht arkitektura më e famshme e rrjetës së shërbimit. Dhe Kubernetes, i cili fillimisht u zhvillua në Google, tani është korniza e vetme e orkestrimit të kontejnerëve të mbështetur nga Istio. Shitësit po përpiqen të krijojnë versione të mbështetur komercialisht të Istio. Do të jetë interesante të shihet se çfarë gjërash të reja mund të sjellin në projektin me kod të hapur.
Sidoqoftë, Istio nuk është opsioni i vetëm pasi implementimet e tjera të Service Mesh janë duke u zhvilluar. Modeli sidecar proxy është zbatimi më popullor, siç mund të gjykohet nga projektet Buoyant, HashiCorp, Solo.io dhe të tjerë. Ekzistojnë gjithashtu arkitektura alternative: paketa e mjeteve të teknologjisë Netflix është një nga qasjet ku funksionaliteti Service Mesh zbatohet përmes bibliotekave Ribbon, Hysterix, Eureka, Archaius, si dhe platforma të tilla si Azure Service Fabric.
Service Mesh gjithashtu ka terminologjinë e vet për komponentët dhe funksionet e shërbimit:
- Korniza e orkestrimit të kontejnerëve. Ndërsa gjithnjë e më shumë kontejnerë shtohen në infrastrukturën e aplikacionit, ka nevojë për një mjet të veçantë për monitorimin dhe menaxhimin e kontejnerëve - një kornizë për orkestrimin e kontejnerëve. Kubernetes e ka zënë me vendosmëri këtë vend, aq sa edhe konkurrentët e tij kryesorë Docker Swarm dhe Mesosphere DC/OS ofrojnë integrim me Kubernetes si një alternativë.
- Shërbimet dhe shembujt (Kubernetes Pods). Një shembull është një kopje e vetme e funksionimit të një mikroservice. Ndonjëherë një shembull është një enë. Në Kubernetes, një shembull përbëhet nga një grup i vogël kontejnerësh të pavarur të quajtur pod. Klientët rrallë aksesojnë drejtpërdrejt një shembull ose pod; më shpesh, ata aksesojnë një shërbim, i cili është një grup instancash ose pods identike, të shkallëzuara dhe tolerante ndaj gabimeve (kopje).
- Proxy i makinës anësore. Sidecar Proxy punon me një shembull të vetëm ose pod. Qëllimi i "Sidecar Proxy" është të drejtojë ose trafikun proxy që vjen nga kontejneri me të cilin punon dhe të kthejë trafikun. Sidecar ndërvepron me përfaqësues të tjerë Sidecar dhe menaxhohet nga një kornizë orkestrimi. Shumë zbatime të Service Mesh përdorin Sidecar Proxy për të përgjuar dhe menaxhuar të gjithë trafikun brenda dhe jashtë një shembulli ose pod.
- Zbulimi i Shërbimit. Kur një shembull duhet të komunikojë me një shërbim tjetër, ai duhet të gjejë (zbulojë) një shembull të shëndetshëm dhe të disponueshëm të shërbimit tjetër. Në mënyrë tipike, shembulli kryen kërkime DNS. Korniza e orkestrimit të kontejnerit mban një listë të rasteve që janë gati për të marrë kërkesa dhe ofron një ndërfaqe për pyetjet DNS.
- Balancimi i ngarkesës. Shumica e kornizave të orkestrimit të kontejnerëve sigurojnë balancimin e ngarkesës në shtresën 4 (transport). Service Mesh zbaton balancim më kompleks të ngarkesës në shtresën 7 (niveli i aplikacionit), i pasur me algoritme dhe më efektiv në menaxhimin e trafikut. Cilësimet e balancimit të ngarkesës mund të ndryshohen duke përdorur API, duke ju lejuar të orkestroni vendosjet blu-jeshile ose kanarinë.
- encryption. Service Mesh mund të enkriptojë dhe deshifrojë kërkesat dhe përgjigjet, duke e hequr këtë barrë nga shërbimet. Service Mesh gjithashtu mund të përmirësojë performancën duke dhënë përparësi ose duke ripërdorur lidhjet ekzistuese të vazhdueshme, duke reduktuar nevojën për llogaritje të shtrenjta për të krijuar lidhje të reja. Zbatimi më i zakonshëm i kriptimit të trafikut është TLS e ndërsjellë (mTLS), ku një infrastrukturë e çelësit publik (PKI) gjeneron dhe shpërndan certifikata dhe çelësa për përdorim nga Sidecar Proxy.
- Autentifikimi dhe autorizimi. Shërbimi Mesh mund të autorizojë dhe vërtetojë kërkesat e bëra nga jashtë ose brenda aplikacionit, duke dërguar vetëm kërkesa të vërtetuara tek instancat.
- Mbështetje e modelit të mbylljes automatike. Mbështet Service Mesh , i cili izolon rastet jo të shëndetshme dhe më pas i kthen gradualisht në grupin e rasteve të shëndetshme kur është e nevojshme.
Pjesa e një aplikacioni Service Mesh që menaxhon trafikun e rrjetit ndërmjet instancave quhet Plani i të dhënave. Krijoni dhe vendosni konfigurimin që kontrollon sjelljen Plani i të dhënave, kryhet duke përdorur një të veçantë Avioni i kontrollit. Avioni i kontrollit zakonisht përfshin ose është projektuar për t'u lidhur me një API, CLI ose GUI për të kontrolluar aplikacionin.
Plani i kontrollit në rrjetën e shërbimit shpërndan konfigurimin midis Proxy-it anësor dhe planit të të dhënave.
Arkitektura Service Mesh përdoret shpesh për të zgjidhur probleme komplekse operacionale duke përdorur kontejnerë dhe mikroshërbime. Pionierë në këtë fushë janë kompani të tilla si Lyft, Netflix dhe Twitter, të cilat ofrojnë shërbime të qëndrueshme për miliona përdorues në mbarë botën. (). Për aplikacione më pak kërkuese, ka të ngjarë të mjaftojnë arkitekturat më të thjeshta.
Arkitektura e rrjetës së shërbimit nuk ka gjasa të jetë ndonjëherë përgjigja për të gjitha çështjet e funksionimit dhe shpërndarjes së aplikacionit. Arkitektët dhe zhvilluesit kanë një arsenal të madh mjetesh, dhe vetëm njëri prej tyre është një çekiç, i cili, midis shumë detyrave, duhet të zgjidhë vetëm një - goditjen e gozhdëve me çekan. , për shembull, përfshin disa modele të ndryshme që ofrojnë një vazhdimësi qasjesh për zgjidhjen e problemeve duke përdorur mikroshërbime.
Elementet që bashkohen në një arkitekturë Service Mesh, të tilla si NGINX, kontejnerët, Kubernetes dhe mikroshërbimet si një qasje arkitekturore, mund të jenë po aq produktive në implementimet jo-Service Mesh. Për shembull, Istio u projektua si një arkitekturë e plotë e rrjetës së shërbimit, por modulariteti i tij do të thotë që zhvilluesit mund të zgjedhin dhe zbatojnë vetëm komponentët e teknologjisë që u nevojiten. Duke pasur parasysh këtë, është e rëndësishme të zhvilloni një kuptim të qartë të konceptit të rrjetës së shërbimit, edhe nëse nuk jeni i sigurt se do të jeni ndonjëherë në gjendje ta zbatoni plotësisht në aplikacionin tuaj.
Burimi: www.habr.com