¡Buenos días a todos!
Hoy nos complace ofrecerle una traducción de un artículo que habla brevemente sobre una nueva tendencia tecnológica llamada "Malla de servicio". La solución más interesante en esta área (en nuestra opinión) es
Istio , pero el artículo propuesto es interesante, en primer lugar, por comparación expresa de las tecnologías existentes de este tipo y una visión general de alto nivel de todo el paradigma. El autor, Tobias Kunze, también escribió un segundo artículo más práctico sobre la malla de servicios: una solicitud para expresar si vale la pena publicar su traducción
Esta publicación es la primera de las dos que hablan sobre los beneficios de las redes de servicios. Este artículo describe qué es una red de servicio, cómo funciona y cuál es su uso. La
segunda parte explora por qué, dónde y cuándo usar tales redes, y lo que se avecina.
Al descomponer una aplicación en microservicios, rápidamente queda claro que llamar a un servicio a través de la red es un proceso mucho más complejo y menos confiable de lo que se pensaba. Lo que se suponía que "simplemente funcionaba" por diseño ahora debe estar claramente articulado para cada cliente y cada servicio. Los clientes tienen que descubrir terminales de servicio, asegurarse de que sean consistentes en todas las versiones de API y empaquetar y desempaquetar mensajes. Los clientes también necesitan rastrear la ejecución de llamadas y administrar tales operaciones, detectar errores, repetir llamadas fallidas y mantener un tiempo de espera si es necesario. Los clientes también pueden necesitar verificar la autenticidad de los servicios, las llamadas de registro y las transacciones de instrumentos. Finalmente, sucede que toda la aplicación debe cumplir con las reglas de
IAM , el cifrado o los requisitos de control de acceso.
Por supuesto, la mayoría de estos problemas no son nuevos, y durante mucho tiempo tenemos a nuestra disposición tecnologías que ayudan a organizar los mecanismos de mensajería, por ejemplo, SOAP, Apache Thrift y gRPC. Pero lo que se ha observado recientemente: la rápida propagación de contenedores y el consiguiente crecimiento explosivo de las llamadas de servicio, el grado de escala horizontal y la corta duración de los terminales de servicio asociados. Cuando la complejidad y la fragilidad alcanzan un nuevo nivel, existe el deseo de encapsular la comunicación de red y llevarla a un nuevo nivel de infraestructura. El enfoque más popular para proporcionar este nivel, aplicado hoy, se llama la "red de servicios".
¿Qué es exactamente una "red de servicios"?
Una red de servicio no es una "red de servicio". Esta es una red de intermediarios API (proxies) a los que se pueden conectar (micro) servicios para abstraer completamente la red. Como
dijo William Morgan, se trata de "una capa de infraestructura dedicada que proporciona una comunicación segura, rápida y confiable entre servicios". Las redes de servicio ayudan a hacer frente a los muchos desafíos que enfrentan los desarrolladores cuando tienen que intercambiar información con terminales remotas. Sin embargo, debe tenerse en cuenta que los principales problemas operativos con la ayuda de las redes de servicios no se resuelven.
¿Cómo funcionan las redes de servicio?
Arquitectura de red de servicio típica. Los proxies en el plano de datos se implementan como acompañantes (sidecar), y el plano de control se ubica por separado.En una red de servicio típica, los servicios desplegados se modifican para que cada uno de ellos esté acompañado por su propio
"compañero" proxy . Los servicios no llaman directamente a otros servicios a través de la red, sino que recurren a sus compañeros proxy locales, que, a su vez, encapsulan la complejidad del intercambio de información entre servicios. Tal conjunto interconectado de proxies implementa el llamado plano de datos.
Por el contrario, el conjunto de API y herramientas utilizadas para controlar el comportamiento del proxy en toda la red de servicios se denomina "plano de control". Es en el plano de control que los usuarios establecen políticas y configuran el plano de datos como un todo.
Para implementar una red de servicio, se necesitan un plano de datos y un plano de control.
Jugadores principales: Envoy, Linkerd, Istio y Consul
Envoy es un servidor proxy de código abierto desarrollado por Lyft. Hoy forma un plano de datos en muchas redes de servicios, incluido Istio. Envoy reemplazó rápidamente a otros servidores proxy gracias a su conveniente API de configuración, que permite a los planos de control ajustar su comportamiento en tiempo real.
Linkerd es un proyecto de código abierto respaldado por Buoyant y, al mismo tiempo, la primera red de servicio. Originalmente se escribió en Scala, como
Finagle , de Twitter, de donde proviene, y luego se fusionó con el proyecto ligero Conduit y se reinició como
Linkerd 2.0 .
Istio es quizás la red de servicios más popular de nuestro tiempo. Fue lanzado conjuntamente por Google, IBM y Lyft; se espera que eventualmente ingrese al proyecto de la
Fundación de Computación Nativa de la
Nube (CNCF). Estrictamente hablando, Istio es un plano de control y, para formar una red de servicio, debe combinarse con el plano de datos. Istio se usa típicamente con Envoy y funciona mejor en Kubernetes.
El cónsul es un fenómeno relativamente nuevo en el ecosistema de los aviones de control. Funciona mejor con topologías que abarcan muchos centros de datos y se especializa en el descubrimiento de servicios. El cónsul trabaja con muchos planos de datos y puede usarse sin involucrar a otros planos de control, por ejemplo, sin Istio. Su apoyo es HashiCorp.
Principales ventajas y diferencias de prioridades.
Aunque el espacio de las redes de servicio continúa evolucionando, la mayoría de los proyectos, aparentemente, ya han llegado a la idea del conjunto principal de características que deberían ser compatibles en dicha red:
- Descubrimiento de servicios : descubriendo servicios y manteniendo su registro
- Enrutamiento : equilibrio de carga inteligente y enrutamiento de red, mejores pruebas de rendimiento, patrones de implementación automática, como configuraciones azul-verde y canario
- Estabilidad : reintentos, tiempos de espera y disyuntores
- Seguridad : cifrado basado en TLS, incluida la gestión de claves
- Telemetría : recopilación de métricas y seguimiento de identificadores
Además de estas capacidades (y algunas veces basadas en ellas), existe un nivel más rico de funciones en el cual comienzan serias diferencias entre las diferentes redes de servicios sobre lo que puede ser valioso para arquitectos, desarrolladores y administradores de sistemas de microservicios. Por ejemplo, Envoy admite WebSockets, pero Linkerd 2.0 (aún no). Si bien Istio y Consul son compatibles con diferentes planos de datos, Linkerd solo funciona con los suyos. El cónsul tiene su propio plano de datos incorporado, que puede reemplazarse por uno más potente cuando el problema del rendimiento se convierte en una prioridad. Istio está diseñado como un plano de control centralizado separado, mientras que Consul y Linkerd están completamente distribuidos. Finalmente, de todas las redes de servicio discutidas anteriormente, solo Istio admite la inyección de fallas. Estas son solo algunas de las diferencias clave a tener en cuenta si está considerando introducir dicha red.
Crítica de la red de servicios
A pesar de la obvia popularidad y las características prometedoras y atractivas, las redes de servicios no se usan tan ampliamente como cabría esperar. Sin lugar a dudas, esto se debe en parte a su novedad y al hecho de que toda esta industria continúa tomando forma. Pero, hablando de redes de servicios, no puede prescindir de algunas críticas.
El escepticismo asociado con las redes de servicios se relaciona principalmente con la complejidad adicional que aportan, su productividad relativamente baja y ciertas brechas que aparecen cuando se trabaja con topologías de múltiples clústeres.
Las redes de servicios son plataformas ambiguas, en la etapa inicial de implementación de las cuales se requieren inversiones serias en el ensamblaje del sistema y su equipo instrumental. Puede parecer que agregar un compañero al contenedor es bastante fácil, sin embargo, el manejo competente de fallas y el reintento requieren esfuerzos de ingeniería serios. Puede ser difícil justificar tales inversiones cuando se trabaja con aplicaciones existentes con un ciclo de vida corto o con aplicaciones de rápido desarrollo.
Además, las redes de servicio pueden degradar seriamente el rendimiento de la aplicación en comparación con el uso de llamadas de red directas. Los problemas que surgen en este caso a veces son difíciles de diagnosticar, y aún más de eliminar. Dado que la mayoría de las redes de servicio están destinadas a trabajar con aplicaciones de microservicio autónomas, y no a paisajes completos de aplicaciones relacionadas, tales redes generalmente tienen un soporte pobremente implementado para soluciones para muchos clústeres y diferentes regiones.
En resumen, las redes de servicios no son una panacea para los arquitectos y operadores que buscan adaptarse con flexibilidad para operar una flota creciente de servicios digitales. Dicha red es una solución táctica, representa una mejora técnica "fundamental" diseñada para resolver problemas que son relevantes, principalmente para los desarrolladores. A nivel empresarial, no revertirán la situación.
Tecnología relacionada
Las redes de servicio se cruzan con otros componentes arquitectónicos, pero, por supuesto, no son reducibles a ellos. Estos elementos incluyen API, puertas de enlace de aplicaciones, equilibradores de carga, controladores de tráfico entrantes y salientes (entrada y salida) o puertas de enlace de entrega de aplicaciones. El objetivo principal de la puerta de enlace API es proporcionar servicios con acceso al mundo exterior, mientras actúa como una API única para proporcionar funciones de equilibrio de carga, seguridad y administración básica. Los controladores de tráfico entrantes y salientes transmiten información entre direcciones no enrutables en la orquesta del contenedor y direcciones enrutadas fuera de ella. Finalmente, los controladores de entrega de aplicaciones son similares a las puertas de enlace API, pero su especialización es acelerar la entrega de aplicaciones web, no solo la API.