Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Sugerencia
Este contenido es un extracto del libro electrónico, Arquitectura de aplicaciones .NET nativas de nube para Azure, disponible en .NET Docs o como un PDF descargable gratuito que se puede leer sin conexión.
A lo largo de este capítulo, hemos explorado los desafíos de la comunicación de microservicios. Hemos dicho que los equipos de desarrollo deben ser sensibles a cómo se comunican los servicios back-end entre sí. Cuanto menos sea la comunicación entre servicios, mejor. Sin embargo, la prevención no siempre es posible, ya que los servicios back-end a menudo se basan entre sí para completar las operaciones.
Hemos explorado diferentes enfoques para implementar la comunicación HTTP sincrónica y la mensajería asincrónica. En cada uno de los casos, el desarrollador se carga con la implementación de código de comunicación. El código de comunicación es complejo y requiere mucho tiempo. Las decisiones incorrectas pueden provocar problemas de rendimiento significativos.
Un enfoque más moderno para la comunicación de microservicios gira en torno a una tecnología nueva y en rápida evolución titulada Service Mesh. Una malla de servicio es una capa de infraestructura configurable con funcionalidades integradas para controlar la comunicación entre servicios, la resistencia y muchos problemas transversales. Mueve la responsabilidad de estos problemas fuera de los microservicios y a la capa de malla de servicio. La comunicación se abstrae de los microservicios.
Un componente clave de una malla de servicio es un proxy. En una aplicación nativa de la nube, una instancia de un proxy normalmente se coloca con cada microservicio. Mientras se ejecutan en procesos independientes, los dos están estrechamente vinculados y comparten el mismo ciclo de vida. Este patrón, conocido como patrón Sidecar, y se muestra en la figura 4-24.
Figura 4-24. Malla de servicio con un coche lateral
Tenga en cuenta en la ilustración anterior cómo interceptan los mensajes un proxy que se ejecuta junto con cada microservicio. Cada proxy se puede configurar con reglas de tráfico específicas del microservicio. Comprende los mensajes y puede enrutarlos a través de sus servicios y del mundo exterior.
Junto con la administración de la comunicación entre servicios, el Service Mesh proporciona soporte para la detección de servicios y el equilibrio de carga.
Una vez configurada, una malla de servicio es muy funcional. La malla recupera un grupo correspondiente de instancias de un punto de conexión de detección de servicios. Envía una solicitud a una instancia de servicio específica, registrando la latencia y el tipo de respuesta del resultado. Elige la instancia más probable que devuelva una respuesta rápida en función de distintos factores, incluida la latencia observada para las solicitudes recientes.
Una malla de servicio administra los problemas de tráfico, comunicación y redes en el nivel de aplicación. Comprende los mensajes y las solicitudes. Normalmente, una malla de servicio se integra con un orquestador de contenedores. Kubernetes admite una arquitectura extensible en la que se puede agregar una malla de servicio.
En el capítulo 6, profundizamos en las tecnologías de Service Mesh, incluida una explicación sobre su arquitectura y las implementaciones de código abierto disponibles.
Resumen
En este capítulo, analizamos los patrones de comunicación nativos de la nube. Empezamos examinando cómo se comunican los clientes front-end con microservicios back-end. En el camino, hablamos sobre las plataformas de puerta de enlace de API y la comunicación en tiempo real. A continuación, examinamos cómo se comunican los microservicios con otros servicios back-end. Hemos examinado tanto la comunicación HTTP sincrónica como la mensajería asincrónica entre servicios. Tratamos gRPC, una tecnología emergente en el mundo nativo en la nube. Por último, presentamos una tecnología nueva y en rápida evolución titulada Service Mesh que puede simplificar la comunicación de microservicios.
Se hizo especial hincapié en los servicios administrados de Azure que pueden ayudar a implementar la comunicación en sistemas nativos de la nube:
- Azure Application Gateway
- Azure API Management
- Servicio Azure SignalR
- Colas de Azure Storage
- Azure Service Bus
- Azure Event Grid
- Centro de eventos de Azure
A continuación, pasaremos a datos distribuidos en sistemas nativos de nube y las ventajas y desafíos que presenta.
Referencias
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
