Comunicaciones resistentes

A lo largo de este libro, hemos adoptado un enfoque arquitectónico basado en microservicios. Aunque esta arquitectura proporciona ventajas importantes, presenta muchos desafíos:

• Comunicación de red fuera de proceso. Cada microservicio se comunica a través de un protocolo de red que introduce congestión de red, latencia y errores transitorios.

• Detección de servicios. ¿Cómo detectan y comunican los microservicios entre sí al ejecutarse en un clúster de máquinas con sus propias direcciones IP y puertos?

• Resistencia. ¿Cómo administra los errores de corta duración y mantiene el sistema estable?

• Equilibrio de carga. ¿Cómo se distribuye el tráfico entrante entre varias instancias de un microservicio?

• Seguridad. ¿Cómo se aplican los problemas de seguridad, como el cifrado de nivel de transporte y la administración de certificados?

• Supervisión distribuida. - ¿Cómo correlaciona y captura la rastreabilidad y la supervisión de una sola solicitud en varios microservicios de consumo?

Puede abordar estos problemas con diferentes bibliotecas y marcos, pero la implementación puede ser costosa, compleja y lenta. También termina con problemas de infraestructura acoplados a la lógica de negocios.

Malla de servicio

Un mejor enfoque es una tecnología en evolución titulada Service Mesh. Una malla de servicio es una capa de infraestructura configurable con funcionalidades integradas para controlar la comunicación del servicio y los otros desafíos mencionados anteriormente. Desacopla estos problemas al moverlos a un proxy de servicio. El proxy se implementa en un proceso independiente (denominado sidecar) para proporcionar aislamiento del código empresarial. Sin embargo, el sidecar está vinculado al servicio: se crea con él y comparte su ciclo de vida. En la figura 6-7 se muestra este escenario.

Figura 6-7. Malla de servicio con un coche lateral

En la ilustración anterior, observe cómo el proxy intercepta y administra la comunicación entre los microservicios y el clúster.

Una malla de servicio se divide lógicamente en dos componentes dispares: un plano de datos y un plano de control. En la figura 6-8 se muestran estos componentes y sus responsabilidades.

Figura 6-8. Control de malla de servicio y plano de datos

Una vez configurada, una malla de servicio es muy funcional. Puede recuperar un grupo de instancias correspondiente de un punto de conexión de detección de servicios. Después, la malla puede enviar una solicitud a una instancia específica, registrando la latencia y el tipo de respuesta del resultado. Una malla puede elegir la instancia con más probabilidades de devolver una respuesta rápida en función de muchos factores, incluida su latencia observada para las solicitudes recientes.

Si una instancia no responde o no responde, la malla reintentará la solicitud en otra instancia. Si devuelve errores, una malla expulsará la instancia del grupo de equilibrio de carga y la restablezará después de que se sane. Si se agota el tiempo de espera de una solicitud, se puede producir un error en una malla y, a continuación, volver a intentar la solicitud. Una malla captura y emite métricas y seguimiento distribuido a un sistema de métricas centralizado.

Istio y Envoy

Aunque actualmente existen algunas opciones de malla de servicio, Istio es la más popular en el momento de escribir este documento. Istio es una empresa conjunta de IBM, Google y Lyft. Es una oferta de código abierto que se puede integrar en una aplicación distribuida nueva o existente. La tecnología proporciona una solución coherente y completa para proteger, conectar y supervisar microservicios. Sus características incluyen:

• Protección de la comunicación entre servicios en un clúster con autenticación y autorización sólidas basadas en identidades.
• Equilibrio de carga automático para el tráfico HTTP, gRPC, WebSocket y TCP.
• Control específico del comportamiento del tráfico, con reglas de enrutamiento enriquecidas, reintentos, conmutaciones por error e inyección de errores
• Una API de configuración y capa de directiva conectable que admite controles de acceso, límites de velocidad y cuotas
• Métricas, registros y seguimientos automáticos para todo el tráfico de un clúster, incluida la entrada y salida del clúster

Un componente clave para una implementación de Istio es un servicio proxy titulado proxy proxy. Se ejecuta junto con cada servicio y proporciona una base independiente de la plataforma para las siguientes características:

• Detección dinámica de servicios.
• Equilibrio de carga.
• Terminación TLS.
• Servidores proxy HTTP y gRPC.
• Resistencia del disyuntor.
• Comprobaciones de estado.
• Actualizaciones graduales con implementaciones controladas .

Como se explicó anteriormente, Envoy se implementa como sidecar en cada microservicio del clúster.

Integración con Azure Kubernetes Services

La nube de Azure adopta Istio y proporciona compatibilidad directa con ella en Azure Kubernetes Services. Los vínculos siguientes pueden ayudarle a empezar:

• Instalación de Istio en AKS
• Uso de AKS e Istio

Referencias

• Polly

• Patrón de reintento

• Patrón Circuit Breaker

• Notas del producto sobre resistencia en Azure

• Redundancia

• replicación geográfica

• Azure Traffic Manager

• Guía de escalado automático

• Istio

• Proxy de Envoy