Comunicación resistente
Sugerencia
Este contenido es un extracto del libro electrónico “Architecting Cloud Native .NET Applications for Azure” (Diseño de la arquitectura de aplicaciones .NET nativas en la nube para Azure), disponible en Documentos de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.
A lo largo de todo el libro hemos adoptado un enfoque arquitectónico basado en microservicios. Aunque esta arquitectura reporta ventajas importantes, plantea 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 se detectan y comunican los microservicios entre sí cuando se ejecutan en un clúster de equipos con sus direcciones IP y puertos propios?
Resistencia. ¿Cómo se administran los errores de corta duración y se mantiene estable el sistema?
Equilibrio de carga. ¿Cómo se distribuye el tráfico entrante entre varias instancias de un microservicio?
Seguridad. ¿Cómo se instauran cuestiones de seguridad como el cifrado de nivel de transporte y la administración de certificados?
Supervisión distribuida. - ¿Cómo se correlaciona y captura la rastreabilidad y supervisión de una misma solicitud en varios microservicios de consumo?
Estas cuestiones pueden abordarse con diferentes bibliotecas y marcos, pero la implementación puede ser costosa, compleja y muy lenta. Por no hablar de los problemas de infraestructura relativos a la lógica de negocios que acaban surgiendo.
Malla de servicio
Un enfoque más adecuado es una tecnología en evolución llamada mallas de servicio. 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 antes mencionados. Separa estas cuestiones trasladándolas a un proxy de servicio. El proxy se implementa en un proceso independiente (denominado sidecar) para proporcionar aislamiento del código de negocio. Pero 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 sidecar
En la imagen de arriba, fíjese en 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 distintos: un plano de datos y un plano de control. En la figura 6-8 se muestran estos componentes y sus responsabilidades.
Figura 6-8. Plano de datos y de control de la malla de servicio
Una vez configurada, una malla de servicio es muy funcional. Puede recuperar el grupo de instancias que corresponda de un punto de conexión de detección de servicios. Luego 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 más probable para devolver una respuesta rápida en función de muchos factores, incluida la latencia observada en las solicitudes recientes.
Si una instancia no responde o se produce un error, la malla reintentará la solicitud en otra instancia. Si la instancia devuelve errores, una malla la expulsará del grupo de equilibrio de carga y la volverá a restablecer cuando su estado sea correcto. Si se agota el tiempo de espera de una solicitud, una malla puede generar un error y, seguidamente, volver a intentar la solicitud. Una malla captura y envía 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 redacción del presente documento. Istio es una empresa conjunta de IBM, Google y Lyft. Se trata de 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 uniforme y muy completa para proteger, conectar y supervisar microservicios. Sus características incluyen:
- Protección de la comunicación entre servicios en un clúster con una 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 en cualquier implementación de Istio es un servicio de proxy llamado proxy Envoy. Este 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 de interruptor
- Comprobaciones de estado
- Actualizaciones graduales con implementaciones controladas
Como hemos visto antes, Envoy se implementa como sidecar en cada microservicio del clúster.
Integración con Azure Kubernetes Services
La nube de Azure adopta el uso de Istio y proporciona compatibilidad directa en Azure Kubernetes Services. Los siguientes recursos pueden servir para empezar a usar Istio:
