Mapeo de eShopOnContainers con los Servicios de Azure

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.

Descargar PDF

Aunque no es necesario, Azure es adecuado para admitir eShopOnContainers porque el proyecto se creó para ser una aplicación nativa de la 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 muestran diferentes enfoques, desde operaciones CRUD simples hasta patrones DDD y CQRS más complejos. Los microservicios se comunican con clientes a través de HTTP y entre sí a través de la comunicación basada en mensajes. La aplicación también admite varias plataformas para clientes, ya que adopta HTTP como protocolo de comunicación estándar e incluye ASP.NET aplicaciones móviles de Core y Xamarin que se ejecutan en plataformas Android, iOS y Windows. (Xamarin deja de ser compatible a partir de mayo de 2024).

La arquitectura de la aplicación se muestra en la figura 2-5. A la izquierda se encuentran las aplicaciones cliente, divididas en tipos de aplicación de página única (SPA) móviles, tradicionales y web. A la derecha se encuentran los componentes del lado servidor que componen el sistema, cada uno de los cuales se puede hospedar en contenedores de Docker y clústeres de Kubernetes. La aplicación web tradicional se basa en la aplicación ASP.NET Core MVC que se muestra en amarillo. Esta aplicación y las aplicaciones spa móviles y web 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 se encuentra el bus de eventos del sistema, que se usa para la comunicación entre los microservicios.

Figura 2-5. La arquitectura de eShopOnContainers.

Los componentes del lado servidor de esta arquitectura se asignan fácilmente a los servicios de Azure.

Orquestación de contenedores y agrupación en clústeres

Los servicios hospedados en contenedores de la aplicación, desde aplicaciones de ASP.NET Core MVC a 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 sección siguiente.

AKS proporciona servicios de administración para clústeres individuales de contenedores. La aplicación implementará contenedores independientes para cada microservicio en el clúster de AKS, como se muestra en el diagrama de arquitectura anterior. Este enfoque permite que cada servicio individual se escale de forma independiente según sus demandas de recursos. Cada microservicio también se puede implementar de forma independiente y, idealmente, estas implementaciones deben incurrir en un tiempo de inactividad del sistema cero.

Puerta de enlace de API

La aplicación eShopOnContainers tiene varios clientes front-end y varios servicios back-end diferentes. No hay correspondencia uno a uno entre las aplicaciones cliente y los microservicios que los admiten. En este escenario, puede haber una gran complejidad al escribir software cliente para interactuar con los distintos servicios back-end de forma segura. Cada cliente tendría que abordar esta complejidad por su cuenta, lo que da lugar a la duplicación y a muchos lugares en los que realizar actualizaciones a medida que se implementan los cambios de servicios o se implementan nuevas directivas.

Azure API Management (APIM) ayuda a las organizaciones a publicar API de forma coherente y manejable. APIM consta de tres componentes: la puerta de enlace de API y el portal de administración (Azure Portal) y un portal para desarrolladores.

API Gateway acepta llamadas API y las enruta a la API de back-end adecuada. También puede proporcionar servicios adicionales, como la comprobación de claves de API o tokens JWT y transformación de API sobre la marcha sin modificaciones de código (por ejemplo, para dar cabida a los clientes que esperan una interfaz anterior).

Azure Portal es donde se definen el esquema de API y se empaquetan diferentes API en productos. También puede configurar el acceso de usuario, ver informes y configurar directivas para cuotas o transformaciones.

El portal para desarrolladores actúa como el recurso principal para los desarrolladores. Proporciona a los desarrolladores documentación de API, una consola de prueba interactiva e informes sobre su propio uso. Los desarrolladores también usan el portal para crear y administrar sus propias cuentas, incluida la compatibilidad con la suscripción y la clave de API.

Con APIM, las aplicaciones pueden exponer varios grupos de servicios diferentes, cada uno de los cuales proporciona un back-end para un cliente front-end determinado. SE recomienda APIM para escenarios complejos. Para las necesidades más sencillas, 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.

Otra opción, si tu aplicación está usando AKS, es implementar Azure Gateway Ingress Controller como un 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.

Datos

Los distintos servicios back-end usados por eShopOnContainers tienen requisitos de almacenamiento diferentes. Varios microservicios usan bases de datos de SQL Server. El microservicio Basket aprovecha una caché de Redis para su persistencia. El microservicio Locations espera una API de MongoDB para sus datos. Azure admite cada uno de estos formatos de datos.

Para la compatibilidad con bases de datos de SQL Server, Azure tiene productos para todo, desde bases de datos únicas hasta grupos elásticos de SQL Database altamente escalables. Los microservicios individuales se pueden configurar para comunicarse con sus propias bases de datos individuales de SQL Server de forma rápida y sencilla. Estas bases de datos se pueden escalar según sea necesario para admitir cada microservicio independiente según sus necesidades.

La aplicación eShopOnContainers almacena la cesta de compras actual del usuario entre solicitudes. Este aspecto se administra mediante el microservicio Basket que almacena los datos en una caché de Redis. En desarrollo, esta caché se puede implementar en un contenedor, mientras que en producción puede usar Azure Cache for Redis. Azure Cache for Redis es un servicio totalmente administrado que ofrece un alto rendimiento y confiabilidad sin necesidad de implementar y administrar instancias o contenedores de Redis por su cuenta.

El microservicio Locations usa una base de datos NoSQL de MongoDB para su persistencia. Durante el desarrollo, la base de datos se puede implementar en su propio contenedor, mientras que en producción, el servicio puede aprovechar la API de Azure Cosmos DB para MongoDB. Una de las ventajas de Azure Cosmos DB es su capacidad de aprovechar varios protocolos de comunicación diferentes, como una API de 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 lo usan.

Los datos distribuidos en aplicaciones nativas de nube se tratan con más detalle en el capítulo 5.

Bus de eventos

La aplicación usa eventos para comunicar los cambios entre distintos servicios. Esta funcionalidad se puede implementar con varias implementaciones y la aplicación eShopOnContainers usa RabbitMQ localmente. Cuando se hospeda en Azure, la aplicación aprovecharía Azure Service Bus para su 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 forma 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 aprovecharía temas con Azure Service Bus para admitir la distribución de mensajes de un microservicio a cualquier otro microservicio necesario para reaccionar a un mensaje determinado.

Resiliencia

Una vez implementada en producción, la aplicación eShopOnContainers podría aprovechar las ventajas de 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. Los recursos de Azure también proporcionan registros de diagnóstico que se pueden usar para identificar y corregir errores y problemas de rendimiento. Los registros de recursos proporcionan información detallada sobre cuándo y cómo la aplicación usa distintos recursos de Azure. Obtendrá más información sobre las características de resistencia nativas de la nube en el capítulo 6.

Siguiente anterior