Patrones de comunicación nativa en la nube
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.
Al construir un sistema nativo de la nube, la comunicación se convierte en una decisión de diseño significativa. ¿Cómo se comunica una aplicación cliente de front-end con un microservicio de back-end? ¿Cómo se comunican los microservicios back-end entre sí? ¿Cuáles son los principios, patrones y procedimientos recomendados que se deben tener en cuenta al implementar la comunicación en aplicaciones nativas de la nube?
Consideraciones de comunicación
En una aplicación monolítica, la comunicación es sencilla. Los módulos de código se ejecutan juntos en el mismo espacio ejecutable (proceso) en un servidor. Este enfoque puede tener ventajas de rendimiento, ya que todo se ejecuta junto en memoria compartida, pero da como resultado código estrechamente acoplado que resulta difícil de mantener, evolucionar y escalar.
Los sistemas nativos de la nube implementan una arquitectura basada en microservicios con muchos microservicios pequeños e independientes. Cada microservicio se ejecuta en un proceso independiente y normalmente se ejecuta dentro de un contenedor que se implementa en un clúster.
Un clúster agrupa un grupo de máquinas virtuales para formar un entorno de alta disponibilidad. Se administran con una herramienta de orquestación, que es responsable de implementar y administrar los microservicios en contenedores. En la figura 4-1 se muestra un clúster de Kubernetes implementado en la nube de Azure con Azure Kubernetes Services totalmente administrado.
Figura 4-1. Un clúster de Kubernetes en Azure
En todo el clúster, los microservicios se comunican entre sí a través de las API y las tecnologías de mensajería.
Aunque proporcionan muchas ventajas, los microservicios no dan nada a cambio de nada. Las llamadas de método locales dentro de proceso entre componentes son reemplazadas por llamadas de red. Cada microservicio debe comunicarse a través de un protocolo de red, lo que agrega complejidad al sistema:
- la congestión de la red, la latencia y los errores transitorios son un problema constante.
- La resistencia (es decir, reintentar solicitudes con error) es esencial.
- Algunas llamadas deben ser idempotentes para mantener un estado coherente.
- Cada microservicio debe autenticar y autorizar llamadas.
- Cada mensaje debe serializarse y después deserializarse, lo que puede ser costoso.
- El cifrado y descifrado de mensajes se vuelve importante.
El libro ".NET Microservices: Architecture for Containerized .NET Applications" (Microservicios de .NET: Arquitectura para aplicaciones .NET contenedorizadas), disponible de forma gratuita desde Microsoft, proporciona una cobertura detallada de los patrones de comunicación para las aplicaciones de microservicios. En este capítulo se proporciona información general de alto nivel de estos patrones junto con las opciones de implementación disponibles en la nube de Azure.
En este capítulo abordaremos primero la comunicación entre las aplicaciones de front-end y los microservicios de back-end. A continuación veremos los microservicios de back-end que se comunican entre sí. Exploraremos la tecnología de comunicación up y gRPC. Por último, veremos nuevos patrones de comunicación innovadores mediante la tecnología de malla de servicio. También veremos cómo la nube de Azure proporciona diferentes tipos de servicios de respaldo para admitir la comunicación nativa de la nube.
