Cómo una malla de servicios ayuda a gestionar microservicios distribuidos

Uno de los cambios que se están produciendo en TI bajo el estandarte de la transformación digital es el desglose de grandes aplicaciones monolíticas en microservicios.Unidades de funcionalidad pequeñas y discretas que se ejecutan en contenedorespaquetes de software que incluyen todos los códigos y dependencias del servicio que se pueden aislar y mover fácilmente de un servidor a otro.

Las arquitecturas en contenedores como estas son fáciles de escalar y ejecutar en la nube, y los microservicios individuales pueden implementarse e iterarse rápidamente. Sin embargo, la comunicación entre estos microservicios se vuelve cada vez más compleja a medida que las aplicaciones se hacen más grandes y se ejecutan simultáneamente múltiples instancias del mismo servicio. Una malla de servicios es una forma de arquitectura arquitectónica emergente que apunta a conectar dinámicamente estos microservicios de manera que se reduzcan los gastos administrativos y de programación.

¿Qué es una malla de servicio?

En el sentido más amplio, una malla de servicios es, como lo describe Red Hat, “una manera de controlar cómo las diferentes partes de una aplicación comparten datos con una

Sin embargo, esta descripción podría abarcar muchas cosas diferentes, sin embargo. De hecho, suena muy parecido al middleware con el que la mayoría de los desarrolladores están familiarizados con las aplicaciones cliente-servidor.

Lo que hace que una malla de servicios sea única es que está diseñada para adaptarse a la naturaleza única de los entornos de microservicio distribuidos. En una aplicación a gran escala creada a partir de microservicios, puede haber varias instancias de cualquier servicio dado, ejecutándose en varios servidores locales o en la nube. Todas estas partes móviles obviamente dificultan que los microservicios individuales encuentren los otros servicios con los que necesitan comunicarse. Una malla de servicios se encarga automáticamente de descubrir y conectar los servicios en cada momento para que los desarrolladores humanos y los microservicios individuales no tengan que hacerlo.

Piense en una malla de servicios como el equivalente de una red definida por software (SDN) para el nivel 7 del modelo de red OSI. Al igual que SDN crea una capa de abstracción para que los administradores de red no tengan que lidiar con las conexiones de red físicas, una malla de servicios desacopla la infraestructura subyacente de la aplicación de la arquitectura abstracta con la que interactúa.

La idea de una malla de servicios surgió orgánicamente cuando los desarrolladores comenzaron a lidiar con los problemas de arquitecturas distribuidas verdaderamente enormes. Linkerd, el primer proyecto en esta área, nació como una rama de un proyecto interno en Twitter. Istio, otro servicio popular con gran respaldo corporativo, se originó en Lyft. (Veremos con más detalle estos dos proyectos en un momento).

Balance de carga de malla de servicio

Una de las características clave que proporciona una malla de servicios es el equilibrio de carga. Por lo general, pensamos que el equilibrio de carga es una función de red: desea evitar que un servidor o enlace de red se vea abrumado por el tráfico, por lo que enruta sus paquetes en consecuencia. Las mallas de servicio hacen algo similar en el nivel de la aplicación, como lo describe Twain Taylor, y la comprensión le da una idea de lo que queremos decir cuando decimos que una malla de servicio es como una red definida por software para la capa de aplicación.

En esencia, uno de los trabajos de la malla de servicios es hacer un seguimiento de qué instancias de varios microservicios distribuidos en toda la infraestructura son "más saludables". Puede encuestarlos para ver cómo se están desempeñando o hacer un seguimiento de qué instancias responden lentamente. para atender solicitudes y enviar solicitudes posteriores a otras instancias. La malla de servicios puede realizar un trabajo similar para las rutas de red, notando cuando los mensajes tardan demasiado en llegar a su destino y otras rutas para compensar. Esta desaceleración puede deberse a problemas con el hardware subyacente, o simplemente a los servicios que están sobrecargados con solicitudes o trabajando en su capacidad de procesamiento. Lo importante es que la malla de servicios puede encontrar otra instancia del mismo servicio y enrutarla, haciendo así el uso más eficiente de la capacidad de la aplicación en general.

Servicio de malla vs Kubernetes

Si está familiarizado con las arquitecturas basadas en contenedores, es posible que se esté preguntando dónde encaja Kubernetes, la popular plataforma de orquestación de contenedores de código abierto, en esta imagen. Después de todo, ¿no es el punto central de Kubernetes que administre la forma en que sus contenedores se comunican entre sí? Como el equipo de Kublr. señala en su blog corporativo, podría pensar en el recurso de "servicio" de Kubernetes como un tipo muy básico de malla de servicios, ya que proporciona el descubrimiento de servicios y el balanceo de solicitudes. Pero las mallas de servicios con todas las funciones ofrecen mucha más funcionalidad, como la administración de políticas de seguridad y el cifrado, la "interrupción de circuitos" para suspender las solicitudes a instancias de respuesta lenta, el equilibrio de carga como describimos anteriormente y mucho más.

Tenga en cuenta que la mayoría de las mallas de servicio realmente requieren un sistema de orquestación como Kubernetes para estar en su lugar. Las mallas de servicio ofrecen funcionalidad extendida, no un reemplazo.

Malla de servicio vs. puertas de enlace API

Cada microservicio proporcionará una interfaz de programación de aplicaciones (API) que sirve como medio por el cual otros servicios se comunican con él. Esto plantea la cuestión de las diferencias entre una malla de servicios y otras formas más tradicionales de administración de API, como las puertas de enlace API. Como lo explica IBM, una puerta de enlace API se encuentra entre un grupo de microservicios y el mundo "externo", enrutando las solicitudes de servicio según sea necesario para que el solicitante no sepa que se trata de una aplicación basada en microservicios. Una malla de servicios, por otro lado, media solicitudes "dentro" de la aplicación de microservicios, con los distintos componentes conscientes de su entorno.

Otra forma de pensarlo, como Justin Warren escribe en Forbes, es que una malla de servicio es para el tráfico de este a oeste dentro de un clúster y una puerta de enlace API es para el tráfico de norte a sur que entra y sale del clúster. Pero toda la idea de una malla de servicios es todavía temprana y está en proceso de cambio. Muchas mallas de servicio, incluidas Linkerd e Istio, ahora también ofrecen funcionalidad norte-sur.

Arquitectura de malla de servicio

La idea de una malla de servicios surgió solo en los últimos dos años, y existen varios enfoques diferentes para resolver el problema de la "malla de servicios", es decir, administrar las comunicaciones para microservicios. Andrew Jenkins de Aspen Mesh identifica tres opciones posibles con respecto a dónde podría vivir la capa de comunicación creada por la malla de servicio:

El patrón basado en sidecar es uno de los patrones de malla de servicio más populares que existen, tanto que en general se ha convertido en sinónimo de mallas de servicio. Si bien eso no es estrictamente hablando, el enfoque de sidecar ha recibido tanta atención que esta es la arquitectura que veremos con más detalle.

Sidecars en una malla de servicios

¿Qué significa decir que un contenedor sidecar "corre junto con" su contenedor de aplicación? Red Hat tiene una buena explicación. Cada contenedor de microservicios en una malla de servicios de este tipo tiene otro contenedor proxy correspondiente. Toda la lógica requerida para la comunicación de servicio a servicio se extrae del microservicio y se coloca en el sidecar.

Esto puede parecer complicado: después de todo, ¡está duplicando la cantidad de contenedores en su aplicación! Pero también estás usando un patrón de diseño que es clave para simplificar las aplicaciones distribuidas. Al colocar todo ese código de redes y comunicaciones en un contenedor separado, lo ha hecho parte de la infraestructura y ha liberado a los desarrolladores para que no lo implementen como parte de la aplicación.

En esencia, lo que queda es un microservicio que puede centrarse en el láser en su lógica empresarial. El microservicio no necesita saber cómo comunicarse con todos los demás servicios en el entorno salvaje y loco en el que operan. Solo necesita saber cómo comunicarse con el sidecar, que se encarga del resto.

Mallas de servicio: Linkerd, Envio, Istio, Cónsul

Entonces, ¿cuáles son las mallas de servicio disponibles para su uso? Bueno, no hay productos comerciales exactamente disponibles en el mercado. La mayoría de las mallas de servicios son proyectos de código abierto que requieren cierta implementación. Los grandes nombres son:

¿Qué malla de servicio es adecuada para usted? Una comparación está más allá del alcance de este artículo, pero vale la pena señalar que todos los productos anteriores han sido probados en entornos grandes y exigentes. Linkerd e Istio tienen los conjuntos de funciones más extensos, pero todos están evolucionando rápidamente. Es posible que desee consultar el desglose de las características de Linkerd, Envoy e Istio de George Miranda, aunque tenga en cuenta que su artículo se escribió antes de que Conduit y Linkerd unieran fuerzas.

También tenga en cuenta que este espacio es nuevo y que podrían surgir nuevos competidores en cualquier momento. Por ejemplo, en noviembre de 2018, Amazon comenzó a ofrecer una vista previa pública de una malla de servicios de AWS. Teniendo en cuenta el número de tiendas que utilizan la nube pública de Amazon, AWS App Mesh debería tener un gran impacto.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *