Hola de nou!.. A la vigília de l'inici de curs Hem preparat una altra traducció útil.
Una malla de servei és una capa d'infraestructura configurable i de baixa latència necessària per gestionar grans volums de comunicacions entre processos basades en xarxa entre interfícies de programació d'aplicacions (API). Service Mesh permet una comunicació ràpida, fiable i segura entre serveis d'infraestructura d'aplicacions en contenidors i sovint efímers. Service Mesh ofereix capacitats com ara la descoberta de serveis, l'equilibri de càrrega, el xifratge, la transparència, la traçabilitat, l'autenticació i l'autorització i el suport de patrons d'apagada automàtica (tallacircuits).
Una malla de servei normalment s'implementa proporcionant a cada instància de servei una instància de proxy, cridada Sidecar. Sidecar gestionar les comunicacions entre serveis, supervisar i resoldre problemes de seguretat, és a dir, tot allò que es pot abstraure dels serveis individuals. D'aquesta manera, els desenvolupadors poden escriure, mantenir i publicar codi d'aplicació als serveis, i els administradors del sistema poden treballar amb Service Mesh i executar l'aplicació.
Istio de Google, IBM i Lyft és actualment l'arquitectura de malla de servei més famosa. I Kubernetes, que es va desenvolupar originalment a Google, ara és l'únic marc d'orquestració de contenidors compatible amb Istio. Els venedors estan intentant crear versions d'Istio amb suport comercial. Serà interessant veure quines coses noves poden aportar al projecte de codi obert.
Tanmateix, Istio no és l'única opció, ja que s'estan desenvolupant altres implementacions de Service Mesh. Patró sidecar proxy és la implementació més popular, com es pot jutjar pels projectes Buoyant, HashiCorp, Solo.io i altres. També hi ha arquitectures alternatives: el conjunt d'eines tecnològiques de Netflix és un dels enfocaments on s'implementa la funcionalitat Service Mesh a través de les biblioteques Ribbon, Hysterix, Eureka, Archaius, així com plataformes com Azure Service Fabric.
Service Mesh també té la seva pròpia terminologia per als components i funcions del servei:
- Marc d'orquestració de contenidors. A mesura que s'afegeixen cada cop més contenidors a la infraestructura d'aplicacions, es necessita una eina separada per supervisar i gestionar els contenidors: un marc d'orquestració de contenidors. Kubernetes ha ocupat fermament aquest nínxol, tant és així que fins i tot els seus principals competidors Docker Swarm i Mesosphere DC/OS ofereixen la integració amb Kubernetes com a alternativa.
- Serveis i instàncies (Kubernetes Pods). Una instància és una còpia única en execució d'un microservei. De vegades, una instància és un contenidor. A Kubernetes, una instància consisteix en un petit grup de contenidors independents anomenat pod. Els clients rarament accedeixen a una instància o pod directament, més sovint, accedeixen a un servei, que és un conjunt d'instàncies o pods (rèpliques) idèntics, escalables i tolerants a errors;
- Sidecar Proxy. Sidecar Proxy funciona amb una sola instància o pod. L'objectiu de Sidecar Proxy és dirigir o enviar el trànsit procedent del contenidor amb el qual treballa i retornar el trànsit. Sidecar interactua amb altres servidors intermediaris Sidecar i està gestionat per un marc d'orquestració. Moltes implementacions de Service Mesh utilitzen Sidecar Proxy per interceptar i gestionar tot el trànsit d'entrada i sortida d'una instància o pod.
- Descobriment de serveis. Quan una instància necessita comunicar-se amb un altre servei, ha de trobar (descobrir) una instància sana i disponible de l'altre servei. Normalment, la instància realitza cerques de DNS. El marc d'orquestració de contenidors manté una llista d'instàncies que estan preparades per rebre sol·licituds i proporciona una interfície per a consultes DNS.
- Equilibri de càrrega. La majoria dels marcs d'orquestració de contenidors proporcionen equilibri de càrrega a la capa 4 (transport). Service Mesh implementa un equilibri de càrrega més complex a la capa 7 (nivell d'aplicació), ric en algorismes i més eficaç en la gestió del trànsit. La configuració de l'equilibri de càrrega es pot canviar mitjançant l'API, la qual cosa us permet orquestrar desplegaments de color blau-verd o canari.
- Xifrat. Service Mesh pot xifrar i desxifrar sol·licituds i respostes, eliminant aquesta càrrega dels serveis. Service Mesh també pot millorar el rendiment prioritzant o reutilitzant les connexions persistents existents, reduint la necessitat de càlculs costosos per crear connexions noves. La implementació més comuna del xifratge de trànsit és TLS mutu (mTLS), on una infraestructura de clau pública (PKI) genera i distribueix certificats i claus per utilitzar-los per Sidecar Proxy.
- Autenticació i Autorització. El Service Mesh pot autoritzar i autenticar les sol·licituds fetes des de fora o dins de l'aplicació, enviant només sol·licituds validades a les instàncies.
- Suport de patró d'apagat automàtic. Suports de Service Mesh , que aïlla les instàncies no saludables i després les torna gradualment al conjunt d'instàncies saludables quan sigui necessari.
S'anomena la part d'una aplicació Service Mesh que gestiona el trànsit de xarxa entre instàncies Pla de dades. Creeu i desplegueu una configuració que controli el comportament Pla de dades, es realitza mitjançant una separació Plànol de control. Plànol de control normalment inclou o està dissenyat per connectar-se a una API, CLI o GUI per controlar l'aplicació.
El pla de control de la malla de servei distribueix la configuració entre el servidor intermediari Sidecar i el pla de dades.
L'arquitectura Service Mesh s'utilitza sovint per resoldre problemes operatius complexos mitjançant contenidors i microserveis. Pioners en el camp són empreses com Lyft, Netflix i Twitter, que ofereixen serveis estables a milions d'usuaris a tot el món. (). Per a aplicacions menys exigents, probablement n'hi haurà prou amb arquitectures més senzilles.
És poc probable que l'arquitectura Service Mesh sigui la resposta a tots els problemes d'operació i lliurament de l'aplicació. Els arquitectes i desenvolupadors tenen un gran arsenal d'eines, i només una d'elles és un martell, que, entre moltes tasques, només ha de resoldre una: picar claus. , per exemple, inclou diversos models diferents que proporcionen un continu d'enfocaments per resoldre problemes mitjançant microserveis.
Els elements que s'ajunten en una arquitectura de Service Mesh, com ara NGINX, contenidors, Kubernetes i microserveis com a enfocament arquitectònic, poden ser igualment productius en implementacions que no siguin Service Mesh. Per exemple, Istio es va dissenyar com una arquitectura de malla de servei completa, però la seva modularitat significa que els desenvolupadors només poden seleccionar i implementar els components tecnològics que necessiten. Tenint això en compte, és important desenvolupar una comprensió clara del concepte de malla de servei, fins i tot si no esteu segur de poder implementar-lo completament a la vostra aplicació.
Font: www.habr.com
