Pershendetje përsëri!.. Në prag të fillimit të kursit kemi përgatitur një përkthim të dobishëm.
Service Mesh është një nivel infrastrukture i konfiguroshëm me vonesë të ulët, i nevojshëm për trajtimin e volumit të madh të komunikimeve ndër-procesore në rrjet mes pikave të ndërfaqeve të aplikacionit (API). Service Mesh siguron komunikim të shpejtë, të besueshëm dhe të sigurt mes shërbimeve të kontenjerizuara dhe shpesh efemere të infrastrukturës së aplikacioneve. Service Mesh ofron mundësi si zbulimi i shërbimeve, balancimi i ngarkesës, enkriptimi, transparenca, gjurmimi, autentifikimi dhe autorizimi, si dhe mbështetje për modelin e fikjes automatike (circuit breaker).
Service Mesh zakonisht realizohet duke ofruar një instancë proxy për çdo instancë shërbimi, e quajtur Sidecar. Sidecar trajton komunikimin mes shërbimeve, monitoron dhe zgjidh problemet e sigurisë, pra, gjithçka që mund të abstrahohet nga shërbimet individuale. Kështu, zhvilluesit mund të shkruajnë, mbështesin dhe mirëmbajnë kodin e aplikacionit në shërbime, ndërsa administratorët e sistemeve mund të punojnë me Service Mesh dhe të ekzekutojnë aplikacionin.
Istio nga Google, IBM dhe Lyft, aktualisht është arkitektura më e njohur Service Mesh. Kubernetes, i cili fillimisht u zhvillua në Google, tani është një nga kornizat e vetme për orkestrimin e kontenjerëve që mbështetet nga Istio. Disa furnizues përpiqen të krijojnë versionet komerciale të mbështetura të Istio. Është interesante të shohim se çfarë të re do të sjellin ata në projektin me burim të hapur.
Megjithatë, Istio nuk është opsioni i vetëm, pasi po zhvillohen edhe implementime të tjera të Service Mesh. Modeli sidecar proxy është implementimi më i popullarizuar, siç mund të gjykohet nga projektet Buoyant, HashiCorp, Solo.io dhe të tjerët. Ka edhe arkitektura alternative: mjeti teknologjik i Netflix është një nga qasjet, ku funksionaliteti i Service Mesh realizohet përmes bibliotekave Ribbon, Hysterix, Eureka, Archaius, si dhe platformave si Azure Service Fabric.
Service Mesh ka gjithashtu terminologjinë e saj për komponentët e shërbimeve dhe funksionet:
- Korniza e orkestrimit të kontenjerëve. Ndërsa gjithnjë e më shumë kontejnerë shtohen në infrastrukturën e aplikacionit, shfaqet nevojat për një mjet të veçantë për monitorimin dhe menaxhimin e kontejnerëve – një strukturë orkestrimi të kontejnerëve. Kubernetes ka zënë fort këtë nišë, aq shumë sa që madje competitorët e tij kryesorë Docker Swarm dhe Mesosphere DC/OS ofrojnë si alternativë integrimin me Kubernetes.
- Shërbimet dhe instancat (podet e Kubernetes). Instanca është një kopje e vetme e aktivizuar e një mikroshërbimi. Ndonjëherë një instancë është një kontejner i vetëm. Në Kubernetes instanca përbëhet nga një grup i vogël kontejnerësh të pavarur, të njohur si pod. Klientët rrallëherë i drejtohen direkt një instance ose podi, më shumë i drejtohen një shërbimi që përfaqëson një grup identik instancash ose podësh (replikash) të skalueshme dhe të qëndrueshme ndaj dështimeve.
- Proxy Sidecar. Proxy Sidecar punon me një instancë ose pod. Qëllimi i Proxy Sidecar është të drejtojë ose të proksojë trafikun që vjen nga kontejneri, me të cilin punon, si dhe trafikun e kthyer. Sidecar bashkëvepron me Proxy të tjerë Sidecar dhe menaxhohet nga struktura orkestrimi. Shumë implementime të Service Mesh përdorin Proxy Sidecar për të kapur dhe menaxhuar të gjithë trafikun që vjen dhe ikën nga instanca ose podi.
- Zbulimi i shërbimeve. Kur një instancë ka nevojë të ndërveprojë me një shërbim tjetër, ajo duhet të gjejë (zbulojë) një instancë të shëndoshë dhe të disponueshme të shërbimit tjetër. Zakonisht, instanca kryen një kërkim përmes DNS. Struktura orkestrimi i kontejnerëve ruan një listë të instancave që janë të gatshme për të marrë kërkesa dhe ofron një ndërfaqe për kërkesa DNS.
- Balancimi i ngarkesës. shumica e strukturave orkestrimi të kontejnerëve ofrojnë ngarkesë balancimi në nivelin 4 (transportues). Service Mesh implementon një ngarkesë balancimi më të komplikuar në nivelin 7 (aplikativ), të pasur me algoritme dhe më efikase në menaxhimin e trafikut. Parametrat e ngarkesë balancimi mund të ndryshohen përmes API, duke lejuar orkestrimin e implementimit të gjelbër-të kaltër ose kanadez.
- Kriptimi. Service Mesh mund të enkriptojë dhe dekriptojë 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 prioritarizuar ose ripërdorur lidhjet ekzistuese të përhershme, duke ulur nevojën për llogaritje të kushtueshme për krijimin e lidhjeve të reja. Zbatimi më i zakonshëm i enkriptimit të trafikut është mutual TLS (mTLS), ku infrastruktura e çelsave publik (PKI) gjeneron dhe përhap certifikata dhe çelësa për t'i përdorur në Sidecar Proxy.
- Autentifikimi dhe autorizimi. Service Mesh mund të autorizojë dhe autentifikojë kërkesat e bëra nga jashtë ose brenda aplikacionit, duke dërguar instancave vetëm kërkesat e verifikuara.
- Mbështetje për modelin e automatikut. Service Mesh mbështet , i cili izolon instancat e pa shëndetshme dhe pastaj gradualisht i kthen ato në grupin e instancave të shëndetshme kur është e nevojshme.
Ajo pjesë e aplikacionit Service Mesh që menaxhon trafikun në rrjet mes instancave quhet Data Plane. Krijimi dhe shpërndarja e konfigurimit që menaxhon sjelljen Data Plane, realizohet me një Control Plane. Control Plane zakonisht përfshin ose është projektuar për t'u lidhur me API, CLI ose GUI për menaxhimin e aplikacionit.
Planin e Kontrollit në Service Mesh shpërndan konfigurimin midis Sidecar Proxy dhe Data Plane.
Shpesh, arkitektura e Service Mesh aplikohen për të zgjidhur probleme komplekse operacionale duke përdorur konteinerë dhe mikroshërbime. Pionierët në këtë fushë janë kompani si Lyft, Netflix dhe Twitter, të cilat ofrojnë shërbime që funksionojnë në mënyrë të qëndrueshme për miliona përdorues në të gjithë botën. (). Për detyra aplikative më pak kërkuese, ka shumë mundësi që një arkitekturë më e thjeshtë do të ishte e mjaftueshme.
Arkitektura e Service Mesh është e pabesueshme kur do të jetë përgjigjja për të gjitha pyetjet e lidhura me funksionimin e aplikacioneve dhe shpërndarjen e tyre. Arkitektët dhe zhvilluesit kanë një arsenale të madhe mjetesh, dhe vetëm një prej tyre është hammer, i cili në mes të shumë detyrave duhet të zgjidhë vetëm një – të godasë gozhdën. , për shembull, përfshin disa modele të ndryshme që ofrojnë një spektër të vazhdueshëm qasjeje për zgjidhjen e problemeve me ndihmën e mikroshërbimeve.
Elementët që bashkohen në arkitekturën e Service Mesh, si NGINX, kontejnerët, Kubernetes dhe mikroshërbimet si një qasje arkitekturore, mund të përdoren me të njëjtin produktivitet edhe në realizime pa Service Mesh. Për shembull, Istio u zhvillua si një arkitekturë e plotë e Service Mesh, por modulariteti tregon se zhvilluesit mund të zgjedhin dhe aplikojnë vetëm komponentët e nevojshëm të teknologjive. Duke mbajtur këtë në mend, është e domosdoshme të formohet një kuptim i qartë i konceptit të Service Mesh, edhe nëse nuk jeni të sigurt se do të jeni ndonjëherë në gjendje ta realizoni atë plotësisht në aplikacion.
Burimi: habr.com
