Por qué las aplicaciones empresariales necesitan una arquitectura de malla de servicio

Fecha:2021-02-10Caliente:184

A medida que las empresas cambian cada vez más de una arquitectura monolítica a una de microservicios, los equipos de TI se enfrentan al problema de orquestar eficazmente estos microservicios. Cuando tenemos una única aplicación creada con unos pocos servicios containerizados diferentes, la comunicación entre ellos se puede gestionar fácilmente. Sin embargo, las aplicaciones empresariales con 100 o 1000s de diferentes microservicios necesitan una mejor solución para el equilibrio de carga, el monitoreo, el enrutamiento del tráfico y la seguridad.

Ingrese al servicioArquitectura de malla.

Arquitectura de malla de servicio

Una malla de servicios es una capa de infraestructura que administra la comunicación de servicio a servicio y proporciona una forma de enrutar, monitorear y proteger dinámicamente las aplicaciones basadas en microservicios.

Anteriormente, la lógica que rige la comunicación entre servicios se codificaba en cada microservicio. Pero esa no es una opción factible cuando se trata de un gran volumen de Microservicios o se escalan aplicaciones mediante la adición de nuevos servicios.

La solución es tener proxies que administren la comunicación de servicio a servicio, que se ejecuten al lado de cada microservicio en lugar de dentro de él. Estos también se conocen como proxies 'sidecar' y juntos forman la arquitectura de malla abstracta que gestiona la comunicación de Microservicios.

¿Qué se necesita Por esto?

El objetivo de los microservicios era crear aplicaciones como una colección de servicios independientes que esencialmente pueden fallar sin causar interrupciones en todo el sistema. Sin embargo, en la práctica, la mayoría de las aplicaciones basadas en microservicios comenzaron a funcionar con comunicación directa entre servicios. A medida que aumentó la complejidad de las aplicaciones y el número de microservicios, esto creó una mayor interdependencia entre los servicios, reduciendo así la agilidad y la resiliencia del sistema.

Y por lo tanto, las aplicaciones empresariales complejas con una gran cantidad de Microservicios necesitan una arquitectura de malla de servicios.

¿No es eso lo que hicieron las APIs?

Sí, las API realizan una función similar a una malla de servicio, es decir, Gobernar el flujo de información. La diferencia clave radica en qué tipo de comunicación gobiernan.

Las pasarelas de API administran la comunicación entre una aplicación y otras dentro y fuera de la arquitectura empresarial.Proporciona un único punto de entrada en una aplicación, para solicitudes de todos los clientes externos, y maneja la autenticación de usuarios, el enrutamiento, la supervisión y el manejo de errores. También abstrae la complejidad subyacente de una aplicación, con sus microservicios componentes, de clientes externos.

Por otro lado, una arquitectura de malla de servicios gestiona la comunicación entre los microservicios dentro de una aplicación.

Todos los Sidecars de proxy que componen la malla de servicio se enumeran en un registro de servicios. Cada microservicio que desee solicitar información (microservicio de cliente) hará que su sidecar proxy busque el registro para encontrar los proxies disponibles asociados con el microservicio de destino. Luego utiliza el algoritmo de equilibrio de carga definido para dirigir su solicitud al proxy correcto.

¿Qué problemas resuelve una malla de servicio?

La malla de servicios resuelve principalmente las preocupaciones sobre la creciente interdependencia que se arrastra en las aplicaciones basadas en microservicios a medida que escalan en complejidad. Así es como:

Implementación de múltiples versiones de microservicio simultáneamente

Canary lanza, o la introducción de una nueva versión de un seleccionado o tipo de solicitudes a un número microservicio, es una forma estándar de facilitar la incorporación de nuevas funciones. Sin embargo, el enrutamiento efectivo de solicitudes entre versiones antiguas y nuevas puede ser difícil cuando la lógica está codificada dentro de cada servicio, porque tienden a tener interdependencias en otros servicios. De manera similar, las versiones de Microservicios de prueba A/B también requieren capacidades de enrutamiento dinámico que se proporcionan mejor mediante una malla de servicio.

La arquitectura de malla de servicios tiene las reglas de enrutamiento y puede tomar la decisión de dirigir las consultas de servicio de origen a la versión correcta de los servicios de destino. Esta capa de comunicación desacoplada reduce la cantidad de código escrito para cada microservicio, a la vez que gestiona mejor la lógica de enrutamiento entre servicios.

Visibilidad detallada de la comunicación entre servicios

En una arquitectura de Microservicios compleja, puede ser difícil señalar la ubicación exacta de una falla. Pero una vez que toda la comunicación se enruta a través de una malla de servicio, hay una manera de recopilar registros y métricas de rendimiento en todos los aspectos de los microservicios. Esto hace que sea más fácil generar informes detallados y rastrear fácilmente el punto de falla.

Los registros de la malla de servicio también se pueden usar para crear puntos de referencia estandarizados para la aplicación. Por ejemplo, cuánto tiempo esperar antes de volver a intentar un servicio fallido. Una vez que estas reglas se codifican en la malla de servicio, la operación de Microservicios se optimiza ya que el sistema no se sobrecarga con pings innecesarios a un servicio descendente fallido antes del período de tiempo de espera requerido.

Pruebas de microservicio

Probar cada microservicio de forma aislada es fundamental para garantizar la resiliencia de las aplicaciones. También hay casos en los que necesita probar el comportamiento del servicio cuando se introducen fallas en los servicios posteriores. Y eso es difícil y arriesgado si estamos forzando que esas fallas ocurran realmente en los servicios.

La malla de servicio es la forma perfecta de simular estas fallas en los sistemas y estudiar la respuesta asociada.

Tolerancia a fallas

La resiliencia es una razón clave por la que se prefiere la arquitectura de microservicios, y elementos como disyuntores, equilibrio de carga, limitación de velocidad y tiempos de espera son lo que hace posible. Estas reglas generalmente se codifican en cada microservicio, aumentando así la complejidad en el sistema, además de consumir mucho tiempo para crear.

Una vez más, la malla de servicio se puede utilizar para mejorar la tolerancia a fallas al sacar estas funcionalidades de los microservicios y agregarlas a la malla. Estos pueden implementarse a través de un conjunto de reglas que regirán todos los microservicios dentro de la aplicación, sin realmente abarrotar la implementación de Microservicios.

Así que fue un rápido descenso en la arquitectura de malla de servicios y por qué se está convirtiendo en un requisito de infraestructura crucial para las aplicaciones empresariales. Los siguientes blogs explorarán la implementación de la malla de servicio en profundidad y evaluarán las diversas herramientas como Istio, Linkerd y más para la implementación de la arquitectura de malla de servicio.