Implementación de microservicios con Azure Container Apps y Dapr
En este artículo se describe una solución para ejecutar un sistema de administración de pedidos con 10 microservicios en Azure Container Apps. La solución también usa procedimientos recomendados de microservicios mediante Distributed Application Runtime (Dapr) y el escalado controlado por eventos con el escalado automático controlado por eventos (KEDA) de Kubernetes.
Dapr y Traefik son marcas comerciales de sus respectivas empresas. El uso de estas marcas no implica ninguna aprobación.
Arquitectura
Descargue un archivo de PowerPoint de esta arquitectura.
Flujo de datos
Esta solución describe un sistema ficticio de administración de pedidos de Red Dog y su infraestructura de Azure compatible. La arquitectura se compone de un único entorno de Container Apps que hospeda 10 aplicaciones de microservicio de .NET Core. La solución usa el SDK de Dapr para integrarse con los recursos de Azure a través de los bloques de creación publish-subscribe, state y binding. Los servicios también usan reglas de escalado de KEDA para permitir el escalado en función de desencadenadores de eventos y escenarios de escalado a cero.
El siguiente flujo de datos corresponde al diagrama anterior:
Traefik: Proxy básico para enrutar las solicitudes de usuario de la interfaz de usuario a los servicios de contabilidad y Makeline para el panel interactivo.
interfaz de usuario: un panel que muestra los datos de ventas agregados y pedidos en tiempo real para el sistema de administración de pedidos de Red Dog.
Cliente virtual: Un programa de simulación de cliente que simula a los clientes que hacen pedidos a través del servicio de pedidos.
Servicio de pedidos: Una API de creación, lectura, actualización y eliminación para realizar y administrar pedidos.
Servicio de contabilidad: Un servicio que procesa, almacena y agrega datos de pedidos. Transforma los pedidos de los clientes en métricas de ventas significativas que muestra la interfaz de usuario.
Servicio de recepción: Un programa de archivado que genera y almacena recibos de pedidos para fines históricos y de auditoría.
Servicio de fidelidad: Un servicio que administra el programa de fidelidad mediante el seguimiento de puntos de recompensa del cliente en función del gasto de pedidos.
Servicio Makeline: Un servicio que administra una cola de pedidos actuales a la espera de que se complete. Realiza un seguimiento del procesamiento y finalización de los pedidos por parte del servicio de trabajo virtual.
Trabajo virtual: Un programa de simulación de trabajo que simula la finalización de pedidos de clientes.
| Servicio | Entrada | Componentes de Dapr | Reglas de escalabilidad KEDA |
|---|---|---|---|
| Traefik | Externo | Dapr no habilitado | HTTP |
| Interfaz de usuario | Interno | Dapr no habilitado | HTTP |
| Cliente virtual | Ninguno | Invocación de servicio a servicio | N/D |
| Servicio de pedido | Interno | Publicación y suscripción: Azure Service Bus | HTTP |
| Servicio de contabilidad | Interno | Publicación y suscripción: Service Bus | Longitud del tema de Service Bus, HTTP |
| Servicio de recepción | Interno | Publicación y suscripción: Service Bus Enlace: Azure Blob Storage |
Longitud del tema de Service Bus |
| Servicio de fidelidad | Interno | Publicación y suscripción: Service Bus Prueba de Azure Cosmos DB |
Longitud del tema de Service Bus |
| Servicio Makeline | Interno | Publicación y suscripción: Service Bus Estado: Azure Cache for Redis |
Longitud del tema de Service Bus, HTTP |
| Trabajador virtual | Ninguno | Invocación de servicio a servicio Enlace: Cron |
N/D |
Nota
También puede implementar Bootstrap en una aplicación contenedora. Sin embargo, este servicio se ejecuta una vez para realizar la creación de la base de datos y, a continuación, se escala a cero después de crear los objetos necesarios en Azure SQL Database.
Componentes
Application Insights es un servicio extensible de administración del rendimiento de las aplicaciones que puede usar para supervisar aplicaciones activas y detectar automáticamente anomalías en el rendimiento. En esta arquitectura, usará Application Insights con Azure Monitor para ver los registros de contenedor y recopilar métricas de los microservicios.
Blob Storage es una solución basada en la nube para almacenar grandes cantidades de datos no estructurados, como texto o archivos binarios. En esta arquitectura, un servicio de recepción usa Blob Storage a través de un enlace de salida de Dapr para almacenar los recibos de pedido.
Azure Cache for Redis es una caché de Redis administrada distribuida, en memoria y escalable. En esta arquitectura, se usa como componente de almacén de estado de Dapr para que el servicio Makeline almacene datos en los pedidos que se están procesando.
Azure Cosmos DB es un servicio de base de datos administrado de varios modelos NoSQL. En esta arquitectura, se usa como componente de almacén de estado de Dapr para el servicio de fidelidad para almacenar los datos de fidelidad de los clientes.
Azure Monitor es una plataforma unificada que permite recopilar, analizar y actuar sobre los datos de contenido del cliente de los entornos de infraestructura de Azure. En esta arquitectura, usará Azure Monitor con Application Insights para ver los registros de contenedor y recopilar métricas de los microservicios.
Service Bus es un agente de mensajes de empresa totalmente administrado que tiene colas y temas de publicación y suscripción. En esta arquitectura, se usa Service Bus para la implementación del componente publish-subscribe de Dapr. Varios servicios usan este componente. El servicio de pedidos publica mensajes en el bus, y los servicios de Makeline, contabilidad, fidelización y recepción se suscriben a estos mensajes.
Container Apps es un servicio de contenedor sin servidor totalmente administrado que se usa para compilar e implementar aplicaciones modernas a escala. En esta arquitectura, hospedará todos los 10 microservicios en Container Apps e los implementará en un único entorno de Container Apps. Este entorno actúa como límite seguro alrededor del sistema.
SQL Database es un servicio de base de datos relacional inteligente, escalable y compilado para la nube. En esta arquitectura, actúa como almacén de datos para el servicio de contabilidad, que usa Entity Framework Core para interactuar con la base de datos. El servicio de arranque es responsable de configurar las tablas SQL en la base de datos. A continuación, se ejecuta una vez antes de establecer la conexión con el servicio de contabilidad.
Traefik es un proxy inverso moderno líder y equilibrador de carga que facilita la implementación de microservicios. En esta arquitectura, use la característica de configuración dinámica de Traefik para realizar el enrutamiento basado en rutas de acceso desde la interfaz de usuario, que es una aplicación de Vue.js página única. Esta configuración también habilita las llamadas api directas a los servicios back-end para realizar pruebas.
Alternativas
En esta arquitectura, se despliega un proxy Traefik para habilitar el enrutamiento basado en rutas para la API de Vue.js. Hay muchos servidores proxy de código abierto alternativos que puede usar para este propósito. Otros dos proyectos comunes son NGINX y HAProxy.
Toda la infraestructura de Azure, excepto SQL Database, usa componentes de Dapr para la interoperabilidad. Una de las ventajas de Dapr es que se pueden intercambiar todos estos componentes cambiando la configuración de despliegue de las aplicaciones del contenedor. En este escenario, Service Bus, Azure Cosmos DB, Azure Cache for Redis y Blob Storage muestran algunos de los más de 70 componentes de Dapr disponibles. Hay disponible una lista de agentes alternativos de publicación y suscripción, almacenes de estado y enlaces de salida en los documentos de Dapr.
Detalles del escenario
Los microservicios son un estilo arquitectónico ampliamente adoptado. Proporcionan ventajas como la escalabilidad, la agilidad y las implementaciones independientes. Puede usar contenedores como mecanismo para implementar aplicaciones de microservicios y, a continuación, usar un orquestador de contenedores como Kubernetes para simplificar las operaciones. Hay muchos factores que se deben tener en cuenta para las arquitecturas de microservicios a gran escala. Normalmente, la plataforma de infraestructura requiere un conocimiento significativo de tecnologías complejas, como orquestadores de contenedores.
Container Apps es un servicio de contenedor sin servidor totalmente administrado para ejecutar aplicaciones modernas a escala. Permite implementar aplicaciones en contenedores a través de una abstracción de la plataforma subyacente. Al usar este método, no es necesario administrar una infraestructura complicada.
Esta arquitectura usa la integración de Container Apps con una versión administrada de Dapr. Dapr es un proyecto de código abierto que ayuda a los desarrolladores a superar los desafíos inherentes en las aplicaciones distribuidas, como la administración de estado y la invocación de servicios.
Container Apps también proporciona una versión administrada de KEDA. KEDA permite que los contenedores se escalen automáticamente en función de los eventos entrantes de servicios externos, como Service Bus y Azure Cache for Redis.
También puede habilitar la entrada HTTPS en Container Apps sin crear más recursos de red de Azure. Puede usar el proxy de Envoy, que también permite escenarios de división de tráfico.
Para más información, consulte Comparación de aplicaciones de contenedor con otras opciones de contenedor de Azure.
En este artículo se describe una solución para ejecutar un sistema de administración de pedidos con 10 microservicios en Container Apps. La solución también usa procedimientos recomendados de microservicios a través de Dapr y el escalado controlado por eventos con KEDA.
Posibles casos de uso
Esta solución se aplica a cualquier organización que use microservicios sin estado y con estado para sistemas distribuidos. La solución es la mejor para los productos empaquetados de consumo y las industrias manufactureras que tienen un sistema de pedidos y suministro.
Las siguientes soluciones tienen diseños similares:
- Arquitectura de microservicios en Azure Kubernetes Service (AKS)
- Arquitectura de microservicios en Azure Functions
- Arquitectura basada en eventos
Consideraciones
Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, vea Well-Architected Framework.
Confiabilidad
La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, vea Lista de comprobación de revisión de diseño para lade confiabilidad.
Container Apps se basa en una base de Kubernetes, que funciona como la infraestructura subyacente. Los mecanismos de resistencia están integrados en Kubernetes que supervisan y reinician contenedores, o pods, si hay problemas. Los mecanismos de resistencia incluyen un equilibrador de carga integrado que distribuye el tráfico entre varias réplicas de cada aplicación de contenedor. Esta redundancia permite que el sistema permanezca operativo, incluso si una réplica deja de estar disponible.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.
En la lista siguiente se describen varias características de seguridad que se omiten en esta arquitectura, junto con otras recomendaciones y consideraciones:
Esta arquitectura no usa puntos de conexión privados, lo que permite una conectividad privada más segura a los servicios de Azure mediante la asignación de una dirección IP desde la red virtual. Cuando se usan puntos de conexión privados, se puede deshabilitar el acceso a la red pública. Este enfoque mantiene el tráfico en la red troncal de Microsoft y mejora la seguridad y el cumplimiento.
La actividad de red debe supervisarse continuamente para detectar y evitar abusos. Puede lograr este enfoque mediante azure Firewall y tablas de rutas. Las tablas de rutas permiten pasar primero el tráfico que deja una red virtual a través del firewall. Este proceso es un paso importante para garantizar que la arquitectura no sea vulnerable a ataques de filtración de datos.
Use un firewall de aplicaciones web (WAF) para protegerse frente a vulnerabilidades comunes. Use Azure Front Door o Azure Application Gateway para implementar un WAF en esta arquitectura.
Considere la posibilidad de usar la característica integrada de autenticación y autorización para Container Apps, conocida como Easy Auth. Easy Auth simplifica el proceso de integración de proveedores de identidades en la aplicación web. Gestiona la autenticación fuera de su aplicación web, por lo que no tiene que realizar cambios significativos en el código.
Utiliza identidad gestionada para las identidades de carga de trabajo. La identidad administrada elimina la necesidad de que los desarrolladores administren las credenciales de autenticación. Por ejemplo, la arquitectura básica se autentica en SQL Server mediante contraseña en una cadena de conexión. Cuando sea posible, use los identificadores entra de Microsoft para autenticarse en Azure SQL Server.
Optimización de costos
La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.
Use la calculadora de precios de Azure para calcular el costo de los servicios de esta arquitectura.
Excelencia operativa
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.
Puede usar Azure Monitor y Application Insights para supervisar las aplicaciones de contenedor. Para ver los registros de contenedor, vaya en el portal al panel Registros de cada aplicación de contenedor y ejecute la siguiente consulta de Kusto. Este ejemplo muestra los registros de la aplicación de servicio Makeline.
ContainerAppConsoleLogs_CL |
where ContainerAppName_s contains "make-line-service" |
project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
order by _timestamp_d asc
El mapa de la aplicación en Application Insights también muestra cómo se comunican los servicios en tiempo real. De este modo, podrá utilizarlos para la depuración de escenarios. Vaya al mapa de la aplicación en el recurso de Application Insights para ver algo parecido al siguiente mapa.
Para obtener más información, consulte Supervisión de una aplicación en Container Apps.
Eficiencia del rendimiento
La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
Esta solución se basa en gran medida en la implementación de KEDA en Container Apps para el escalado controlado por eventos. Al implementar el servicio de atención al cliente virtual, realiza continuamente pedidos. Este escalado hace que el servicio order se escale verticalmente a través del escalador DE KEDA HTTP. A medida que el servicio de pedidos publica los pedidos en el bus de servicios, los escaladores KEDA del bus de servicios hacen que se escalen los servicios de contabilidad, recepción, Makeline y fidelización. Las aplicaciones de la interfaz de usuario y del contenedor Traefik también configuran los escaladores HTTP KEDA para que las aplicaciones escalen a medida que más usuarios acceden al tablero.
Cuando el cliente virtual no se está ejecutando, todos los microservicios de esta solución se escalan a cero, excepto los servicios de trabajo virtual y Makeline. El trabajo virtual no se reduce verticalmente porque comprueba continuamente el cumplimiento de pedidos. Para obtener más información, consulte Establecimiento de reglas de escalado en Aplicaciones de contenedor.
Colaboradores
Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.
Autor principal:
- Alice Gibbons | Cinturón negro global nativo en la nube
Otros colaboradores:
- Lynn Orrell | Especialista en soluciones principales (GBB)
- Kendall Roden | Gerente sénior del programa
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Documentación de Container Apps
- Comparación de Container Apps con otras opciones de contenedor de Azure