Çfarë është Service Mesh?

Përshëndetje sërish!.. Para fillimit të kursit «Arkitekt i Softuerit» ne kemi përgatitur një përkthim tjetër të dobishëm.

Çfarë është Service Mesh?

Service Mesh është një nivel infrastrukture i konfiguruar me vonesë të ulët, i nevojshëm për përpunimin e një volume të madh të komunikimeve midis proceseve në rrjet mes ndërfaqeve të aplikacioneve (API). Service Mesh siguron komunikim të shpejtë, të besueshëm dhe të sigurt midis 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, autenticiteti dhe autorizimi, si dhe suport për modelin e ndalimit automatik (circuit breaker).
Service Mesh zakonisht implementohet duke ofruar çdo instancë shërbimi një instancë të proxy-t, i cili quhet Sidecar. Sidecar atojnë komunikimet midis shërbimeve, monitorojnë dhe adresojnë problemet e sigurisë, domethënë gjithçka që mund të ndahen 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ë çojnë përpara aplikacionin.

Istio nga Google, IBM dhe Lyft është aktualisht arkitektura më e njohur e Service Mesh. Kubernetes, i cili u zhvillua fillimisht në Google, tani është një strukture unike për orkestrimin e kontejnerëve që mbështetet nga Istio. Furnizuesit po përpiqen të krijojnë versione komerciale të mbështetura të Istio. Është interesante të shohim se çfarë të re do të sjellin në projektin me kod të hapur.

Megjithatë, Istio nuk është opsioni i vetëm, pasi po zhvillohen edhe implementime të tjera të Service Mesh. Modeli proxy sidecar është implementimi më i njohur, siç mund të gjykohet nga projektet Buoyant, HashiCorp, Solo.io dhe të tjerë. Ekzistojnë gjithashtu 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 të tilla si Azure Service Fabric.

Service Mesh gjithashtu ka terminologjinë e vet për komponentët e shërbimeve dhe funksionet:

  • Korniza e orkestrimit të kontejnerëve. Me sa më shumë kontejnerë që shtohen në infrastrukturën e aplikacionit, shfaqet nevoja për një mjet të veçantë për monitorimin dhe menaxhimin e kontejnerëve – kornizën e orkestrimit të kontejnerëve. Kubernetes ka mbushur këtë rreth, aq sa edhe konkurrentët e tij kryesorë Docker Swarm dhe Mesosphere DC/OS ofrojnë si alternativë integrimin me Kubernetes.
  • Shërbimet dhe instancat (pods të Kubernetes). Një instancë është një kopje e vetme e nisur e një mikroshërbimi. Ndonjëherë, një instancë është një kontejner i vetëm. Në Kubernetes, një instancë përbëhet nga një grup i vogël kontejneresh të pavarur, të quajtur pod. Klientët rrallë i drejtohen drejtpërdrejt instancës ose pod-it; më shpesh, ata i drejtohen shërbimit, i cili përfaqëson një grup të instancave ose pod-eve të identike, të shkallëzueshme dhe të qëndrueshme (replikave).
  • Sidecar Proxy. Sidecar Proxy punon me një instancë ose pod. Qëllimi i Sidecar Proxy është të drejtojë ose të proksyrojë trafikun që vjen nga kontejneri me të cilin punon, si dhe trafikun e kthyer. Sidecar interakton me Sidecar Proxy të tjerë dhe menaxhohet nga një kornizë orkestrimi. Shumica e realizimeve të Mesh-i të Shërbimeve përdorin Sidecar Proxy për të kapur dhe menaxhuar të gjithë trafikun që hyn dhe del nga instancë ose pod.
  • Zbulimi i shërbimeve. Kur një instancë duhet të bashkëpunojë me një shërbim tjetër, ajo duhet të gjejë (të zbulojë) një instancë funksionale dhe të arritshme të shërbimit tjetër. Zakonisht instanca kryen kërkimin përmes DNS. Ky raamr orkestrimi i konteinerëve mban një listë instancash që janë të gatshme për të pranuar kërkesa dhe ofron një ndërfaqe për kërkesat DNS.
  • Balancimi i ngarkesës. Shumica e framework-eve të orkestrimit të konteinerëve ofrojnë balancimin e ngarkesës në nivelin 4 (transport). Service Mesh realizon balancimin më të avancuar të ngarkesës në nivelin 7 (aplikativ), i pasur me algoritme dhe më efektiv në menaxhimin e trafikut. Parametrat e balancimit të ngarkesës mund të ndryshohen përmes API-së, duke lejuar orkestrimin e shpërndarjes së blu-jeshile ose kanarinës.
  • Shifrimi. Service Mesh mund të enkriptojë dhe dekrijpitojë kërkesat dhe përgjigjet, duke hequr këtë barrë nga shërbimet. Service Mesh gjithashtu mund të rrisë performancën duke prioritarizuar ose ripërdorur lidhjet ekzistuese, duke reduktuar nevojën për llogaritje të shtrenjta për krijimin e lidhjeve të reja. Implementimi më i zakonshëm i enkriptimit të trafikut është mutual TLS (mTLS), ku infrastruktura e çelësit publik (PKI) gjeneron dhe shpërndan certifikata dhe çelësa për t'u përdorur në Sidecar Proxy.
  • Autentikimi dhe autorizimi. Service Mesh mund të autorizojë dhe autentikojë kërkesat e bëra nga jashtë ose brenda aplikacionit, duke dërguar instancat vetëm kërkesa të verifikuar.
  • Mbështetje për modelin e fikjes automatike. Service Mesh mbështet modelin e fikjes automatike, i cili izolon instancat e papërshtatshme dhe pastaj gradualisht i kthen ato në grupin e instancave të shëndetshme kur është e nevojshme.

Pjesa e aplikacionit të Service Mesh që menaxhon trafikun rrjetëor midis instancave quhet Data Plane. Krijimi dhe implementimi i një konfiguracioni që menaxhon sjelljen Data Plane, bëhet me anë të 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.

Çfarë është Service Mesh?
Control Plane në Service Mesh shpërndan konfigurimin ndërmjet Sidecar Proxy dhe Data Plane.

Shpesh, arkitektura e Service Mesh përdoret për të adresuar probleme të ndërlikuara operative duke përdorur kontejnerë dhe mikrosherbime. Pionierët në këtë fushë mikrosherbimesh janë kompani si Lyft, Netflix dhe Twitter, të cilat ofrojnë shërbime të qëndrueshme për miliona përdorues në të gjithë botën. (Këtu mund të njiheni me një përshkrim të detajuar të disa sfidave arkitekturore me të cilat u përball Netflix). Për detyra me kërkesa më të ulëta, ndoshta do të mjaftonin arkitektura më të thjeshta.

Arkitektura e Service Mesh ndoshta nuk do të jetë kurrë zgjidhja për të gjitha pyetjet lidhur me operimin e aplikacioneve dhe shpërndarjen e tyre. Arkitektët dhe zhvilluesit kanë një arsenal të madh mjetesh, dhe vetëm një prej tyre është çekiçi, i cili në mesin e shumë detyrave duhet të zgjidhë vetëm një — të ngecë gozhdën. Arkitektura Referuese e Mikroshërbimeve nga NGINX, për shembull, përfshin disa modele të ndryshme që ofrojnë një spekter të vazhdueshëm qasje për zgjidhjen e problemeve duke përdorur mikroshërbime.

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 po aq produktivisht edhe në zbatime pa Service Mesh. Për shembull, Istio u zhvillua si një arkitekturë e plote e Service Mesh, por modularteti tregon se zhvilluesit mund të zgjedhin dhe të aplikojnë vetëm komponentët e nevojshëm të teknologjive. Duke mbajtur parasysh këtë, është e nevojshme 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 zbatoni atë plotësisht në aplikacionin tuaj.

Monolitë modularë dhe DDD

Burimi: habr.com

Bli një hosting të besueshëm për faqet me mbrojtje DDoS, VPS VDS serverë 🔥 Bli një hosting të besueshëm për faqet me mbrojtje DDoS, VPS VDS serverë | ProHoster