Ola de novo!.. Na véspera do comezo do curso Preparamos outra tradución útil.
Unha malla de servizo é unha capa de infraestrutura configurable e de baixa latencia necesaria para xestionar grandes volumes de comunicacións entre procesos baseadas en rede entre interfaces de programación de aplicacións (API). Service Mesh permite unha comunicación rápida, fiable e segura entre servizos de infraestrutura de aplicacións en contedores e moitas veces efémeros. Service Mesh ofrece capacidades como descubrimento de servizos, equilibrio de carga, cifrado, transparencia, trazabilidade, autenticación e autorización e soporte de patróns de apagado automático (interruptor).
Unha malla de servizo adoita implementarse proporcionando a cada instancia de servizo unha instancia de proxy, chamada Sidecar. Sidecar xestionar as comunicacións entre servizos, supervisar e resolver problemas de seguridade, é dicir, todo o que se pode abstraer de servizos individuais. Deste xeito, os desenvolvedores poden escribir, manter e servir código de aplicación nos servizos, e os administradores do sistema poden traballar coa malla de servizos e executar a aplicación.
Istio de Google, IBM e Lyft é actualmente a arquitectura de malla de servizos máis famosa. E Kubernetes, que foi desenvolvido orixinalmente en Google, é agora o único marco de orquestración de contedores compatible con Istio. Os provedores están tentando crear versións de Istio compatibles comercialmente. Será interesante ver que cousas novas poden aportar ao proxecto de código aberto.
Non obstante, Istio non é a única opción xa que se están a desenvolver outras implementacións de Service Mesh. Patrón sidecar proxy é a implementación máis popular, como se pode xulgar polos proxectos Buoyant, HashiCorp, Solo.io e outros. Tamén hai arquitecturas alternativas: o conxunto de ferramentas tecnolóxicas de Netflix é un dos enfoques nos que se implementa a funcionalidade Service Mesh a través das bibliotecas Ribbon, Hysterix, Eureka, Archaius, así como plataformas como Azure Service Fabric.
Service Mesh tamén ten a súa propia terminoloxía para os compoñentes e funcións do servizo:
- Marco de orquestración de contedores. A medida que se engaden máis e máis contedores á infraestrutura de aplicacións, fai falta unha ferramenta separada para supervisar e xestionar os contedores: un marco de orquestración de contedores. Kubernetes ocupou firmemente este nicho, tanto que incluso os seus principais competidores Docker Swarm e Mesosphere DC/OS ofrecen a integración con Kubernetes como alternativa.
- Servizos e instancias (Kubernetes Pods). Unha instancia é unha única copia en execución dun microservizo. Ás veces, unha instancia é un recipiente. En Kubernetes, unha instancia consiste nun pequeno grupo de contedores independentes chamado pod. Os clientes raramente acceden a unha instancia ou pod directamente; máis a miúdo acceden a un servizo, que é un conxunto de instancias ou pods (réplicas) idénticos, escalables e tolerantes a fallos.
- Proxy Sidecar. Sidecar Proxy funciona cunha única instancia ou pod. O punto de Sidecar Proxy é enrutar ou proxy o tráfico procedente do contedor co que traballa e devolver o tráfico. Sidecar interactúa con outros proxies Sidecar e está xestionado por un marco de orquestración. Moitas implementacións de Service Mesh usan Sidecar Proxy para interceptar e xestionar todo o tráfico que entra e sae dunha instancia ou pod.
- Descubrimento do servizo. Cando unha instancia precisa comunicarse con outro servizo, ten que atopar (descubrir) unha instancia sa e dispoñible do outro servizo. Normalmente, a instancia realiza buscas de DNS. O marco de orquestración de contedores mantén unha lista de instancias que están listas para recibir solicitudes e proporciona unha interface para consultas DNS.
- Equilibrio de carga. A maioría dos marcos de orquestración de contedores proporcionan equilibrio de carga na capa 4 (transporte). Service Mesh implementa un equilibrio de carga máis complexo na capa 7 (nivel de aplicación), rico en algoritmos e máis eficaz na xestión do tráfico. A configuración do equilibrio de carga pódese cambiar mediante a API, o que lle permite organizar despregamentos azul-verde ou canario.
- Cifrado. Service Mesh pode cifrar e descifrar solicitudes e respostas, eliminando esta carga dos servizos. Service Mesh tamén pode mellorar o rendemento priorizando ou reutilizando as conexións persistentes existentes, reducindo a necesidade de computación cara para crear novas conexións. A implementación máis común do cifrado de tráfico é TLS mutuo (mTLS), onde unha infraestrutura de clave pública (PKI) xera e distribúe certificados e claves para o seu uso por Sidecar Proxy.
- Autenticación e autorización. O Service Mesh pode autorizar e autenticar solicitudes feitas desde fóra ou dentro da aplicación, enviando só solicitudes validadas ás instancias.
- Soporte de patróns de apagado automático. Soportes de Service Mesh , que illa as instancias non saudables e despois devólveas gradualmente ao grupo de instancias saudables cando sexa necesario.
Chámase a parte dunha aplicación Service Mesh que xestiona o tráfico de rede entre instancias Plano de datos. Crea e implementa unha configuración que controla o comportamento Plano de datos, realízase mediante un separado Plano de control. Plano de control normalmente inclúe ou está deseñado para conectarse a unha API, CLI ou GUI para controlar a aplicación.
O plano de control na malla de servizo distribúe a configuración entre o proxy Sidecar e o plano de datos.
A arquitectura Service Mesh úsase a miúdo para resolver problemas operativos complexos mediante contedores e microservizos. Pioneiros na materia son empresas como Lyft, Netflix e Twitter, que ofrecen servizos estables a millóns de usuarios en todo o mundo. (). Para aplicacións menos esixentes, as arquitecturas máis sinxelas probablemente serán suficientes.
É improbable que a arquitectura Service Mesh sexa a resposta a todos os problemas de funcionamento e entrega das aplicacións. Arquitectos e desenvolvedores teñen un enorme arsenal de ferramentas, e só unha delas é un martelo, que, entre moitas tarefas, só debe resolver unha: bater cravos. , por exemplo, inclúe varios modelos diferentes que proporcionan un continuo de enfoques para resolver problemas mediante microservizos.
Os elementos que se unen nunha arquitectura de Service Mesh, como NGINX, contedores, Kubernetes e microservizos como enfoque arquitectónico, poden ser igualmente produtivos en implementacións que non sexan Service Mesh. Por exemplo, Istio foi deseñado como unha arquitectura de malla de servizo completa, pero a súa modularidade significa que os desenvolvedores poden seleccionar e implementar só os compoñentes tecnolóxicos que necesitan. Tendo isto en conta, é importante desenvolver unha comprensión clara do concepto de Service Mesh, aínda que non estea seguro de que nunca poderá implementalo completamente na súa aplicación.
Fonte: www.habr.com