Asignación de eShopOnContainers a los servicios de Azure
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.
Aunque no es un requisito, Azure es adecuado para admitir eShopOnContainers, ya que el proyecto se creó para ser una aplicación nativa de nube. La aplicación se compila con .NET, por lo que puede ejecutarse en contenedores de Linux o Windows en función del host de Docker. La aplicación se compone de varios microservicios autónomos, cada uno con sus propios datos. Los distintos microservicios presentan diferentes enfoques, desde sencillas operaciones CRUD hasta patrones de DDD y CQRS más complejos. Los microservicios se comunican con los clientes a través de HTTP y entre sí a través de la comunicación basada en mensajes. La aplicación admite también varias plataformas para los clientes, ya que usa HTTP como protocolo de comunicación estándar e incluye ASP.NET Core y aplicaciones móviles de Xamarin que se ejecutan en plataformas Android, iOS y Windows.
La arquitectura de la aplicación se muestra en la figura 2-5. A la izquierda están las aplicaciones cliente desglosadas por aplicación móvil, aplicación web tradicional y aplicación web de página única (SPA). A la derecha están los componentes del lado servidor que componen el sistema, cada uno de los cuales se puede hospedar en contenedores Docker y clústeres de Kubernetes. La aplicación web tradicional se basa en la aplicación ASP.NET Core MVC (en amarillo). Esta aplicación y las aplicaciones web SPA y móvil se comunican con los microservicios individuales a través de una o varias puertas de enlace de API. Las puertas de enlace de API siguen el patrón "back-ends para front-ends", lo que significa que cada puerta de enlace está diseñada para admitir un cliente front-end determinado. Los microservicios individuales aparecen a la derecha de las puertas de enlace de API, e incluyen tanto la lógica de negocios como algún tipo de almacén de persistencia. Los distintos servicios usan bases de datos de SQL Server, instancias de caché de Redis y almacenes de MongoDB/CosmosDB. En el extremo derecho vemos el bus de eventos del sistema, que se usa para la comunicación entre los microservicios.
Figura 2-5. Arquitectura de eShopOnContainers
Los componentes del lado servidor de esta arquitectura tienen una correspondencia fácil con los servicios de Azure.
Orquestación y agrupación en clústeres de contenedores
Los servicios hospedados en contenedores de la aplicación (desde las aplicaciones ASP.NET Core MVC a los microservicios individuales de catálogo y pedidos) se pueden hospedar y administrar en Azure Kubernetes Service (AKS). La aplicación se puede ejecutar localmente en Docker y Kubernetes, y los mismos contenedores se pueden implementar en entornos de ensayo y producción hospedados en AKS. Este proceso se puede automatizar, como veremos en la siguiente sección.
AKS presta servicios de administración para clústeres individuales de los contenedores. La aplicación implementará contenedores independientes por cada microservicio en el clúster de AKS, como se muestra en el diagrama de arquitectura anterior. Este enfoque permite que cada servicio individual escale de forma independiente según su demanda de recursos particular. Cada microservicio también se puede implementar de forma independiente; lo ideal es que estas implementaciones no provoquen ningún tiempo de inactividad en el sistema.
API Gateway
La aplicación eShopOnContainers tiene varios clientes front-end y diferentes servicios back-end. No existe una correspondencia uno a uno entre las aplicaciones cliente y los microservicios que las admiten. En este escenario, escribir un software cliente que interactúe con los distintos servicios back-end de forma segura puede ser tremendamente complicado. Cada cliente tendría que abordar esta complejidad por sí mismo, lo que daría lugar a duplicaciones y un sinfín de ubicaciones donde implementar actualizaciones a medida que los servicios van cambiando o se implementan nuevas directivas.
Azure API Management (APIM) ayuda a las organizaciones a publicar API de forma coherente y controlable. APIM consta de tres componentes: la puerta de enlace de API, el portal de administración (Azure Portal) y un portal para desarrolladores.
La puerta de enlace de API acepta llamadas API y las enruta a la API back-end adecuada. También presta otros servicios, como la comprobación de claves de API o tokens JWT y la transformación de API sobre la marcha sin modificaciones de código (por ejemplo, para dar cabida a clientes que esperan una interfaz anterior).
Azure Portal es donde se define el esquema de API y se empaquetan diferentes API en productos. También se puede configurar el acceso de usuario, ver informes y configurar directivas de cuotas o transformaciones.
El portal para desarrolladores actúa como recurso principal para los desarrolladores. Proporciona documentación de API, una consola de pruebas interactiva e informes sobre su propio uso. Los desarrolladores también usan el portal para crear y administrar sus propias cuentas, incluida la suscripción y la compatibilidad con claves de API.
Con APIM, las aplicaciones pueden exponer diferentes grupos de servicios, cada uno de los cuales proporciona un back-end para un cliente front-end determinado. El uso de APIM es recomendable en escenarios complejos. Si las necesidades son más básicas, se puede usar la puerta de enlace de API ligera Ocelot. La aplicación eShopOnContainers usa Ocelot debido a su simplicidad y porque se puede implementar en el mismo entorno de aplicación que la propia aplicación. Obtenga más información sobre eShopOnContainers, APIM y Ocelot.
Si la aplicación usa AKS, otra opción sería implementar el controlador de entrada de puerta de enlace de Azure como pod dentro del clúster de AKS. Este enfoque permite que el clúster se integre con una Azure Application Gateway, lo que permite que la puerta de enlace equilibre la carga del tráfico a los pods de AKS. Obtenga más información sobre el controlador de entrada de puerta de enlace de Azure para AKS.
data
Los distintos servicios back-end que eShopOnContainers usa tienen requisitos de almacenamiento diferentes. Varios de ellos usan bases de datos de SQL Server. El microservicio de cesta utiliza una caché de Redis para su persistencia. El microservicio de ubicaciones espera una API de MongoDB para sus datos. Azure admite todos y cada uno de estos formatos de datos.
En cuanto a la compatibilidad con bases de datos de SQL Server, Azure tiene productos para todo, desde bases de datos únicas hasta grupos de bases de datos elásticas de SQL Database altamente escalables. Cada microservicio se puede configurar para comunicarse con su propia base datos de SQL Server de forma rápida y sencilla. Estas bases de datos pueden escalar según sea necesario para dar cabida a cada microservicio independiente según sus necesidades.
La aplicación eShopOnContainers almacena la cesta de compra actual del usuario entre solicitudes. Este aspecto lo administra el microservicio de cesta, que almacena los datos en una caché de Redis. En la fase de desarrollo, esta caché se puede implementar en un contenedor, mientras que en producción se puede usar Azure Cache for Redis. Azure Cache for Redis es un servicio totalmente administrado que ofrece un alto rendimiento y confiabilidad, sin que tenga que implementar ni administrar instancias o contenedores de Redis por su cuenta.
El microservicio de ubicaciones usa una base de datos NoSQL de MongoDB para su persistencia. Durante la fase de desarrollo, la base de datos se puede implementar en su propio contenedor, mientras que en producción el servicio puede usar la API para MongoDB de Azure Cosmos DB. Una de las ventajas de Azure Cosmos DB es su capacidad para utilizar varios protocolos de comunicación diferentes, incluida una API SQL y API NoSQL comunes como MongoDB, Cassandra, Gremlin y Azure Table Storage. Azure Cosmos DB ofrece una base de datos como servicio totalmente administrada y distribuida globalmente que puede escalar para satisfacer las necesidades de los servicios que la usan.
Los datos distribuidos en aplicaciones nativas de nube se abordan con más detalle en el capítulo 5.
Bus de eventos
La aplicación usa eventos para comunicar los cambios entre los distintos servicios. Esta funcionalidad se puede poner en marcha con varias implementaciones; localmente, la aplicación eShopOnContainers usa RabbitMQ. Si se hospedara en Azure, la aplicación usaría Azure Service Bus para la mensajería. Azure Service Bus es un agente de mensajes de integración totalmente administrado que permite que las aplicaciones y los servicios se comuniquen entre sí de una manera desacoplada, confiable y asincrónica. Azure Service Bus admite colas individuales, así como temas independientes para admitir escenarios de publicador y suscriptor. La aplicación eShopOnContainers usaría los temas de Azure Service Bus para distribuir los mensajes de un microservicio a cualquier otro microservicio necesario que deba reaccionar a un mensaje determinado.
Resistencia
Una vez implementada en producción, la aplicación eShopOnContainers podría aprovechar varios servicios de Azure disponibles para mejorar su resistencia. La aplicación publica comprobaciones de estado, que se pueden integrar con Application Insights para proporcionar informes y alertas en función de la disponibilidad de la aplicación. Entre los recursos de Azure también se encuentran los registros de diagnóstico, que se pueden usar para detectar y corregir errores y problemas de rendimiento. Los registros proporcionan información detallada sobre cuándo y cómo la aplicación usa distintos recursos de Azure. Nos adentraremos en las características de resistencia nativas de nube en el capítulo 6.
