¡Hola de nuevo!.. En vísperas del inicio del curso Hemos preparado otra traducción útil.
Una malla de servicios es una capa de infraestructura configurable y de baja latencia que se necesita para manejar grandes volúmenes de comunicaciones entre procesos basadas en red entre interfaces de programación de aplicaciones (API). Service Mesh permite una comunicación rápida, confiable y segura entre servicios de infraestructura de aplicaciones en contenedores y, a menudo, efímeros. Service Mesh proporciona capacidades como descubrimiento de servicios, equilibrio de carga, cifrado, transparencia, trazabilidad, autenticación y autorización, y compatibilidad con patrones de apagado automático (cortacircuitos).
Una malla de servicios generalmente se implementa proporcionando a cada instancia de servicio una instancia de proxy, llamada Sidecar. Sidecar manejar las comunicaciones entre servicios, monitorear y resolver problemas de seguridad, es decir, todo lo que se puede abstraer de los servicios individuales. De esta manera, los desarrolladores pueden escribir, mantener y servir código de aplicación en servicios, y los administradores del sistema pueden trabajar con Service Mesh y ejecutar la aplicación.
Istio de Google, IBM y Lyft es actualmente la arquitectura de malla de servicios más famosa. Y Kubernetes, que fue desarrollado originalmente en Google, es ahora el único marco de orquestación de contenedores compatible con Istio. Los proveedores están intentando crear versiones de Istio con soporte comercial. Será interesante ver qué cosas nuevas pueden aportar al proyecto de código abierto.
Sin embargo, Istio no es la única opción ya que se están desarrollando otras implementaciones de Service Mesh. Patrón sidecar proxy es la implementación más popular, como lo pueden juzgar los proyectos Buoyant, HashiCorp, Solo.io y otros. También existen arquitecturas alternativas: el conjunto de herramientas tecnológicas de Netflix es uno de los enfoques en los que se implementa la funcionalidad Service Mesh a través de las bibliotecas Ribbon, Hysterix, Eureka, Archaius, así como plataformas como Azure Service Fabric.
Service Mesh también tiene su propia terminología para los componentes y funciones del servicio:
- Marco de orquestación de contenedores. A medida que se agregan más y más contenedores a la infraestructura de aplicaciones, se necesita una herramienta separada para monitorear y administrar contenedores: un marco de orquestación de contenedores. Kubernetes ha ocupado firmemente este nicho, hasta el punto de que incluso sus principales competidores, Docker Swarm y Mesosphere DC/OS, ofrecen integración con Kubernetes como alternativa.
- Servicios e instancias (Kubernetes Pods). Una instancia es una única copia en ejecución de un microservicio. A veces una instancia es un contenedor. En Kubernetes, una instancia consta de un pequeño grupo de contenedores independientes llamado pod. Los clientes rara vez acceden a una instancia o pod directamente; más a menudo, acceden a un servicio, que es un conjunto de instancias o pods (réplicas) idénticos, escalables y tolerantes a fallos.
- Proxy de sidecar. Sidecar Proxy funciona con una sola instancia o pod. El objetivo de Sidecar Proxy es enrutar o proxy el tráfico procedente del contenedor con el que trabaja y devolver el tráfico. Sidecar interactúa con otros Sidecar Proxies y se gestiona mediante un marco de orquestación. Muchas implementaciones de Service Mesh utilizan Sidecar Proxy para interceptar y administrar todo el tráfico que entra y sale de una instancia o pod.
- Descubrimiento de servicios. Cuando una instancia necesita comunicarse con otro servicio, necesita encontrar (descubrir) una instancia en buen estado y disponible del otro servicio. Normalmente, la instancia realiza búsquedas de DNS. El marco de orquestación de contenedores mantiene una lista de instancias que están listas para recibir solicitudes y proporciona una interfaz para consultas DNS.
- Balanceo de carga. La mayoría de los marcos de orquestación de contenedores proporcionan equilibrio de carga en la capa 4 (transporte). Service Mesh implementa un equilibrio de carga más complejo en la capa 7 (nivel de aplicación), rico en algoritmos y más eficaz en la gestión del tráfico. La configuración del equilibrio de carga se puede cambiar mediante la API, lo que le permite organizar implementaciones azul-verde o canary.
- Cifrado. Service Mesh puede cifrar y descifrar solicitudes y respuestas, eliminando esta carga de los servicios. Service Mesh también puede mejorar el rendimiento al priorizar o reutilizar conexiones persistentes existentes, lo que reduce la necesidad de cálculos costosos para crear nuevas conexiones. La implementación más común de cifrado de tráfico es TLS mutuo (mTLS), donde una infraestructura de clave pública (PKI) genera y distribuye certificados y claves para uso de Sidecar Proxy.
- Autenticacion y autorizacion. Service Mesh puede autorizar y autenticar solicitudes realizadas desde fuera o dentro de la aplicación, enviando solo solicitudes validadas a las instancias.
- Soporte de patrón de apagado automático. Soportes de malla de servicio , que aísla las instancias en mal estado y luego las devuelve gradualmente al grupo de instancias en buen estado cuando es necesario.
La parte de una aplicación Service Mesh que gestiona el tráfico de red entre instancias se llama Plano de datos. Crear e implementar una configuración que controle el comportamiento. Plano de datos, se realiza utilizando un separado Plano de control. Plano de control Normalmente incluye o está diseñado para conectarse a una API, CLI o GUI para controlar la aplicación.
El plano de control en Service Mesh distribuye la configuración entre el Sidecar Proxy y el plano de datos.
La arquitectura Service Mesh se utiliza a menudo para resolver problemas operativos complejos mediante contenedores y microservicios. Pioneros en el campo Son empresas como Lyft, Netflix y Twitter, que brindan servicios estables a millones de usuarios en todo el mundo. (). Para aplicaciones menos exigentes, probablemente serán suficientes arquitecturas más simples.
Es poco probable que la arquitectura Service Mesh sea alguna vez la respuesta a todos los problemas de operación y entrega de aplicaciones. Los arquitectos y desarrolladores tienen un enorme arsenal de herramientas, y solo una de ellas es un martillo, que, entre muchas tareas, solo debe resolver una: clavar clavos. , por ejemplo, incluye varios modelos diferentes que proporcionan una serie de enfoques para resolver problemas mediante microservicios.
Los elementos que se combinan en una arquitectura Service Mesh, como NGINX, contenedores, Kubernetes y microservicios como enfoque arquitectónico, pueden ser igualmente productivos en implementaciones que no son Service Mesh. Por ejemplo, Istio fue diseñado como una arquitectura de malla de servicios completa, pero su modularidad significa que los desarrolladores pueden seleccionar e implementar solo los componentes tecnológicos que necesitan. Teniendo esto en cuenta, es importante desarrollar una comprensión clara del concepto de Service Mesh, incluso si no está seguro de poder implementarlo por completo en su aplicación.
Fuente: habr.com