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.
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 .NET aplicaciones de microservicios. La solución utiliza el SDK de Dapr para integrarse con los recursos de Azure mediante elementos de construcción como publish-subscribe, estado y enlace. Los servicios también utilizan reglas de escalado de KEDA para permitir el escalado basado en desencadenantes de eventos y escenarios de escalado a cero.
El siguiente flujo de datos corresponde al diagrama anterior:
Traefik: El proxy básico para enrutar las solicitudes de los usuarios desde la interfaz de usuario hacia 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 | Ingreso | Componentes de Dapr | Reglas de escala de 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-suscripción: Service Bus | Longitud del tema de Service Bus, HTTP |
| Servicio de recepción | Interno | Publicación y suscripción: Service Bus Enlace: Blob Storage de Azure |
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: Redis administrado por Azure |
Longitud del tema de Service Bus, HTTP |
| Trabajador virtual | Ninguno | Invocación de servicio a servicio Vinculación: 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 recibos utiliza el Blob Storage a través de un enlace de salida de Dapr para almacenar los recibos de los pedidos.
Azure Managed Redis proporciona un almacén de datos en memoria basado en software de Redis Enterprise. En esta arquitectura, se utiliza como componente de almacenamiento de estado de Dapr para que el servicio Makeline guarde datos sobre 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 utiliza como componente de almacenamiento de estado de Dapr para que el servicio de fidelización almacene los datos de fidelización 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 intermediario de mensajes empresarial totalmente administrado que cuenta con colas y temas de publicación-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 y equilibrador de carga que se usa para enrutar el tráfico de red a los microservicios. En esta arquitectura, utilice la característica de configuración dinámica de Traefik para realizar el enrutamiento basado en rutas desde la interfaz de usuario, que es una aplicación de una sola página de Vue.js. 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 Managed Redis y Blob Storage muestran algunos de los más de 70 componentes de Dapr disponibles. En la documentación de Dapr se puede consultar una lista de intermediarios de publicación-suscripción, almacenes de estado y enlaces de salida alternativos.
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 Managed 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, consulte Lista de verificación de la revisión de diseño para la confiabilidad.
Container Apps se basa en una base de Kubernetes, que funciona como la infraestructura subyacente. Kubernetes incorpora mecanismos de resiliencia que supervisan y reinician los contenedores, o pods, si surge algún problema. 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.
Como alternativa a los puntos de conexión privados, considere la posibilidad de usar Azure perímetro de seguridad de red para restringir el acceso de red a
Microsoft.ServiceBus/namespacesyMicrosoft.Storage/storageAccounts. Un perímetro de seguridad de red permite asociar estos recursos a un perímetro compartido y definir reglas de acceso de entrada. En esta arquitectura, Container Apps no se implementa con una red virtual personalizada ni con una dirección IP de salida estática, por lo que debes limitar la regla de entrada a la suscripción que aloja el entorno de Container Apps, en lugar de a un rango de direcciones IP, ya que, para que esto sea eficaz, se necesita una dirección IP de origen estable y conocida.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 controla la integración con proveedores de identidades fuera de la aplicación web, lo que puede reducir la cantidad de código que necesita mantener.
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 de pedidos se escale hacia arriba a través del escalador 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 trabajador virtual no se reduce porque comprueba continuamente el cumplimiento de los pedidos. Para obtener más información, vea Configurar reglas de escalado en Aplicaciones de contenedores.
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