Búsqueda de sitios web

¿Qué es una malla de servicio? ¿Por qué importan?


Una red de servicios es una capa de infraestructura que facilita la comunicación entre los componentes de la aplicación. Las mallas brindan funcionalidad que incluye descubrimiento de servicios, equilibrio de carga y observabilidad.

Las mallas de servicios se encuentran generalmente en sistemas distribuidos compuestos por microservicios. La malla proporciona una forma para que diferentes servicios intercambien datos. Solo maneja el tráfico interno, transfiriéndolo a una puerta de enlace API o nodo perimetral para servir a los usuarios. Las mallas populares incluyen Linkerd e Istio.

¿Qué hay dentro de la malla?

El concepto básico de una red de servicios es bastante sencillo. La capa encapsula servidores proxy de red que enrutan el tráfico a servicios individuales. Una capa de control gestiona las llamadas de red entre los servicios y organiza el uso de los proxies.

El propósito fundamental de la malla es hacer más fácil y confiable la comunicación de los servicios. Tomemos un par simple de servicios: una API y un sistema de autenticación separado. La API deberá interactuar con el servicio de autenticación cuando reciba solicitudes.

Con una red de servicios, obtiene una comunicación confiable entre los servicios que utilizan identificadores conocidos. Su API podría enviar llamadas de red al nombre de host auth-service y estar seguro de que aún se resolverá correctamente, incluso si el servicio de autenticación se traslada a una ubicación de centro de datos diferente. La red de servicios actúa para enrutar de forma transparente las solicitudes al servicio adecuado.

El uso de una red de servicios facilita el movimiento de los servicios. La lógica de comunicación de red codificada puede volverse rápidamente restrictiva. Una malla le brinda más flexibilidad para distribuir sus cargas de trabajo en el futuro.

¿Cómo se implementan las mallas de servicio?

La mayoría de las mallas de servicios modernas se forman a partir de dos componentes: un plano de control y un plano de datos. La funcionalidad central pertenece al plano de datos, que se ocupa de los datos que fluyen a través del sistema.

Cada solicitud a la malla será procesada por el plano de datos. Descubrirá el servicio adecuado para usar, realizará cualquier acción de registro y habilitará comportamientos condicionales para filtrar y redirigir el tráfico.

Los servicios suelen ser parte de su aplicación, por lo que pueden incluir lógica de enrutamiento. El plano de datos inspecciona las reglas de configuración para determinar el punto final final en función de los encabezados HTTP, los parámetros de la solicitud y otros valores de la solicitud.

Mientras que el plano de datos bulle de actividad, el plano de control es relativamente más simple. Supervisa los servidores proxy en el plano de datos y proporciona una API para que pueda interactuar con ellos.

Este diagrama del proyecto Istio ilustra cómo encajan los componentes. Cada servicio obtiene su propio proxy. El tráfico de entrada fluye a través de los proxies. Pueden comunicarse con el plano de control para descubrir otros servicios. Los servidores proxy se denominan comúnmente sidecars, ya que se ejecutan junto con el servicio que representan.

Otras funciones de Service Mesh

Las mallas de servicios generalmente brindan funcionalidad adicional más allá del descubrimiento de servicios básicos. Por lo general, encontrará equilibrio de carga, autenticación a nivel de solicitud y soporte para el cifrado de datos. El tráfico cifrado puede pasar a través de la malla, pero se entrega a sus servicios en forma descifrada.

Su malla generalmente ofrecerá salvaguardas contra interrupciones transitorias de la red. Los reintentos automáticos, las conmutaciones por error y los disyuntores hacen que la comunicación entre servicios sea más resistente. Es menos probable que el usuario final vea un estado de error grave. Estas importantes capacidades serían difíciles y costosas de implementar a mano.

Del mismo modo, las mallas de servicios incorporan optimizaciones de rendimiento que ayudan a minimizar los gastos generales. La malla podría conservar las conexiones a los servicios para su posterior reutilización, lo que reduce la latencia en la siguiente solicitud.

Las capas de malla también proporcionan protecciones de seguridad. Puede implementar políticas de control de acceso a nivel de malla que rechacen el tráfico antes de que llegue a sus servicios. Si desea un limitador de tasa de API global, hacerlo parte de la configuración de malla lo aplicará a todos sus servicios, presentes y futuros.

¿Qué pasa con los inconvenientes?

El mayor desafío en torno a las mallas de servicios es la complejidad adicional que aportan. Si bien su objetivo es simplificar las redes de microservicios, también introducen una curva de aprendizaje propia.

Los desarrolladores deberán familiarizarse con otra capa sobre sus servicios existentes. Las terminologías de malla, como proxies y sidecars, se suman a la ya larga lista de recursos de Kubernetes que mantienen los equipos de operaciones.

Aunque las mallas agregan sus propias mejoras de rendimiento, algunas implementaciones podrían notar una reducción general en el rendimiento de la red. La malla agrega una nueva capa por la que deben pasar las solicitudes, lo que afecta la eficiencia general. Esto normalmente se nota más si almacena su malla con muchas reglas de enrutamiento.

¿Cuándo debe usar una malla de servicios?

Las mallas de servicio funcionan mejor cuando está totalmente comprometido con los contenedores y los microservicios. Están diseñados para resolver los desafíos de ejecutar sistemas distribuidos a gran escala en producción. Las implementaciones más pequeñas aún podrían beneficiarse de una malla, pero también podrían utilizar enfoques de red más simples, como los recursos de red integrados de Kubernetes.

Las mallas son más útiles cuando lanza nuevos servicios con frecuencia o los distribuye entre servidores. Una malla permite a los desarrolladores centrarse en la funcionalidad, en lugar del tedio de conectar diferentes servicios entre sí. A medida que implemente una flota de servicios en constante crecimiento, pasará más tiempo manejando la comunicación de servicio a servicio. Una malla automatiza la mayor parte de esta configuración, por lo que no necesita pensar en el enrutamiento y el descubrimiento de servicios.

El enfoque también ayuda a que su sistema sea más observable. Todas las solicitudes fluyen a través de la malla para que pueda implementar el registro y el seguimiento a nivel de infraestructura. Esto proporciona una vía más sencilla para el diagnóstico y la resolución de problemas de enrutamiento. Sin una malla, es posible que tenga docenas de servicios que transmiten información directamente entre sí. Esto hace que sea difícil encontrar el origen de un problema.

Las mallas de servicio más populares son fáciles de configurar. Istio y Linkerd tienen guías de introducción bien documentadas para ayudarlo a implementar una malla en su clúster de Kubernetes. Vale la pena experimentar incluso si aún no está seguro de que su sistema esté a escala de malla. Seguir con la comunicación directa del servicio durante demasiado tiempo podría restringir su capacidad para lanzar nuevos servicios de manera oportuna y confiable.

Artículos relacionados: