Compartir a través de

Implementación de microservicios en Azure Container Apps

Azure Container Apps
Azure Cosmos DB
Azure Service Bus

En este escenario se muestra una carga de trabajo existente diseñada originalmente para Kubernetes, que se vuelve a ejecutar en Azure Container Apps. Container Apps admite cargas de trabajo brownfield en las que los equipos desean simplificar la infraestructura y la orquestación de contenedores.

La carga de trabajo de ejemplo es una aplicación de microservicios en contenedores. Reutiliza la misma carga de trabajo definida en la arquitectura de microservicios en Azure Kubernetes Service (AKS). Esta arquitectura reubica la carga de trabajo en Container Apps, utilizándola como plataforma de aplicaciones.

Importante

Esta arquitectura se centra en minimizar los cambios en el código de la aplicación y acercarse a la transición de AKS a Container Apps como una migración de plataforma. El objetivo es replicar la implementación existente y aplazar las optimizaciones de código o infraestructura que pueden poner en peligro la migración.

Para un nuevo proyecto, consulte Implementar microservicios mediante Container Apps y Dapr.

Sugerencia

Una implementación de ejemplo admite esta arquitectura e ilustra algunas de las opciones de diseño descritas en este artículo.

Arquitectura

Diagrama que muestra la arquitectura en tiempo de ejecución de la solución.

Descargue un archivo Visio de esta arquitectura.

Los servicios que comparten el mismo entorno se benefician de las siguientes maneras:

  • Entrada interna y detección de servicios
  • Un área de trabajo única de Log Analytics para el registro en tiempo de ejecución
  • Un método de administración seguro para secretos y certificados

Flujo de datos

  1. Servicio de ingesta: Recibe solicitudes de cliente, las almacena en búfer y las publica en Azure Service Bus. Es el único punto de entrada en la carga de trabajo.

  2. Servicio de flujo de trabajo: Consume mensajes de Service Bus y los envía a los microservicios subyacentes.

  3. Servicio de paquetes: administra paquetes. El servicio mantiene su propio estado en Azure Cosmos DB.

  4. Servicio programador de drones: programa drones y supervisa los drones en vuelo. El servicio mantiene su propio estado en Azure Cosmos DB.

  5. Servicio de entrega: Administra las entregas programadas o en tránsito. El servicio mantiene su propio estado en Azure Managed Redis.

  6. Recuperación de secretos: Dado que es una carga de trabajo existente, solo algunos componentes acceden a Azure Key Vault para obtener secretos en tiempo de ejecución. Los demás servicios reciben esos secretos del entorno de Container Apps.

  7. Registros y métricas: El entorno y todas las aplicaciones de contenedor emiten registros y métricas que muestran las características de Azure Monitor y, a continuación, recopilan y visualizan.

  8. Imágenes de contenedor: Las imágenes de contenedor se extraen de la instancia de Azure Container Registry existente que se usó anteriormente para AKS e implementadas en el entorno de Container Apps.

Componentes

La carga de trabajo usa los siguientes servicios de Azure en coordinación entre sí:

  • Container Apps es una plataforma de contenedor sin servidor que simplifica la orquestación y administración de contenedores. En esta arquitectura, Container Apps actúa como la plataforma de hospedaje principal para todos los microservicios.

    Las siguientes características reemplazan muchas de las funcionalidades de la arquitectura de AKS anterior:

    • Detección de servicios integrada
    • Puntos de conexión HTTP y HTTP/2 administrados
    • Equilibrio de carga integrado
    • Registro y supervisión
    • Escalado automático basado en el tráfico HTTP o eventos con tecnología del escalado automático basado en eventos (KEDA) basado en Kubernetes
    • Actualizaciones de aplicaciones y control de versiones

  • Container Registry es un servicio de registro administrado para almacenar y administrar imágenes de contenedor privadas. En esta arquitectura, es el origen de todas las imágenes de contenedor que se implementan en el entorno de Container Apps. El registro es el mismo que se usa en la implementación de AKS.

  • Azure Cosmos DB es un servicio de base de datos de varios modelos distribuido globalmente. En esta arquitectura, el servicio de programador de drones usa Azure Cosmos DB como almacén de datos.

  • Azure DocumentDB es un servicio de base de datos totalmente administrado compatible con MongoDB para compilar aplicaciones modernas. En esta arquitectura, el servicio de paquetes usa Azure DocumentDB como almacén de datos.

  • Service Bus es un servicio de mensajería en la nube que proporciona funcionalidades de comunicación asincrónicas e integración híbrida. En esta arquitectura, controla la mensajería asincrónica entre el servicio de ingesta y el microservicio de flujo de trabajo basado en tareas. El resto de los servicios de la aplicación existente están diseñados para que otros servicios puedan invocarlos con solicitudes HTTP.

  • Azure Managed Redis es un servicio de almacenamiento en caché en memoria. En esta arquitectura, reduce la latencia y mejora el rendimiento de los datos de entrega de drones a los que se accede con frecuencia.

  • Key Vault es un servicio en la nube para almacenar y acceder de forma segura a secretos como claves de API, contraseñas y certificados. En esta arquitectura, el programador de drones y los servicios de entrega usan identidades administradas asignadas por el usuario para autenticarse con Key Vault y recuperar secretos necesarios para sus requisitos en tiempo de ejecución.

  • Azure Monitor es una solución de supervisión completa que recopila y analiza los datos de telemetría. En esta arquitectura, recopila y almacena métricas y registros de todos los componentes de la aplicación a través de un área de trabajo de Log Analytics. Estos datos se usan para supervisar la aplicación, configurar alertas y paneles y realizar análisis de la causa principal de los errores.

    • Application Insights es un servicio de administración del rendimiento de la aplicación que proporciona funcionalidades de supervisión extensibles. En esta arquitectura, cada servicio se instrumenta con el SDK de Application Insights para supervisar el rendimiento de la aplicación.

Alternativas

La arquitectura avanzada de microservicios de AKS describe un escenario alternativo de este ejemplo que usa Kubernetes.

Detalles del escenario

Puede simplificar la implementación y administración de contenedores de microservicios mediante Container Apps, un entorno sin servidor para hospedar aplicaciones en contenedores.

Fabrikam, Inc., una empresa ficticia, implementa una carga de trabajo de entrega de drones donde los usuarios solicitan un dron para recoger productos para su entrega. Cuando un cliente programa una recogida, un sistema back-end asigna un dron y notifica al usuario un tiempo de recogida estimado.

La aplicación de microservicios se implementó en un clúster de AKS. Pero el equipo de Fabrikam no aprovechaba las características avanzadas o las específicas de la plataforma AKS. Migraron la aplicación a Container Apps, lo que les permitió realizar las siguientes acciones:

  • Utilice cambios mínimos de código al mover la aplicación de AKS a Container Apps. Los cambios de código estaban relacionados con las bibliotecas de observabilidad que aumentaban los registros y las métricas con información del nodo de Kubernetes, que no son relevantes en el nuevo entorno.

  • Implementar tanto la infraestructura como la carga de trabajo con plantillas Bicep: no se necesitaron manifiestos YAML de Kubernetes para implementar sus contenedores de aplicaciones.

  • Exponga la aplicación a través de un ingreso administrado. La compatibilidad integrada con la entrada externa basada en HTTPS para exponer el servicio de ingesta quitó la necesidad de configurar su propia entrada.

  • Extraiga imágenes de contenedor del Registro de Contenedores. Container Apps es compatible con cualquier imagen base de Linux almacenada en cualquier repositorio disponible.

  • Use la característica de revisión para admitir las necesidades del ciclo de vida de la aplicación. Podrían ejecutar varias revisiones de una aplicación de contenedor determinada y dividir el tráfico entre ellas para escenarios de implementación de A/B o azul/verde.

  • Use una identidad administrada para autenticarse con Key Vault y Container Registry.

Posibles casos de uso

Implemente una aplicación basada en microservicios brownfield en una plataforma como servicio (PaaS) para simplificar la administración y evitar la complejidad de ejecutar un orquestador de contenedores. La carga de trabajo brownfield ha ahorrado dinero mediante esta arquitectura a través de su implementación de Kubernetes por los siguientes motivos:

  • Elección de perfiles de carga de trabajo
  • Menos tiempo invertido en las tareas operativas del día 2 para el equipo de operaciones
  • La capacidad de evitar el aprovisionamiento excesivo

Nota:

No todas las cargas de trabajo producen este ahorro de costos.

Considere otros usos comunes de Container Apps:

  • Ejecute cargas de trabajo en contenedores en una plataforma sin servidor basada en el consumo.
  • Escalado automático de aplicaciones basadas en tráfico HTTP o HTTPS y desencadenadores controlados por eventos compatibles con KEDA.
  • Minimice la sobrecarga de mantenimiento para las aplicaciones en contenedores.
  • Implementación de puntos de conexión de API.
  • Hospedar aplicaciones de procesamiento en segundo plano.
  • Controlar el procesamiento controlado por eventos.

Optimizations

El objetivo del equipo de carga de trabajo es migrar la carga de trabajo existente a Container Apps con cambios mínimos de código. Pero debe realizar varias optimizaciones para mejorar la arquitectura y la implementación de cargas de trabajo después de la migración.

Mejora de la administración de secretos

La carga de trabajo usa un enfoque híbrido para administrar secretos. Las identidades administradas solo se aplican a los servicios en los que el cambio a identidades administradas no requiere modificaciones de código. Los servicios de entrega y programador de drones emplean identidades administradas asignadas por el usuario con Key Vault para acceder a secretos almacenados. Los servicios restantes requieren cambios de código para adoptar identidades administradas, por lo que esos servicios usan secretos que proporciona el entorno de Container Apps.

Un mejor enfoque es actualizar todo el código para admitir identidades administradas mediante la aplicación o la identidad de trabajo en lugar de secretos proporcionados por el entorno. Para más información sobre las identidades de carga de trabajo, consulte Identidades administradas en Container Apps.

Evitar diseños que requieran el modo de revisión única

La aplicación contenedora del servicio de flujo de trabajo se ejecuta en modo de revisión única. En el modo de revisión única, la aplicación tiene una revisión respaldada por cero o más réplicas. Una réplica se compone del contenedor de aplicaciones y de los sidecar necesarios. En este ejemplo no se usan sidecars, por lo que cada réplica es un único contenedor. El servicio de flujo de trabajo no está diseñado para la compatibilidad directa con esquemas de mensajes. Dos versiones diferentes del servicio nunca se deben ejecutar simultáneamente.

Si el esquema de mensajes de Service Bus debe cambiar, debe purgar el bus antes de implementar la nueva versión del servicio de flujo de trabajo. Un mejor enfoque es actualizar el código de servicio para la compatibilidad hacia adelante y usar el modo de revisión múltiple para reducir el tiempo de inactividad asociado a colas de drenaje.

Considere el trabajo basado en tareas

El servicio de flujo de trabajo se implementa como una aplicación contenedora de ejecución prolongada. Pero también se puede ejecutar como un trabajo en Container Apps. Un trabajo es una aplicación en contenedores que se inicia a petición, se ejecuta hasta la finalización en función del trabajo disponible y, a continuación, apaga y libera recursos. Los trabajos pueden ser más económicos que ejecutar réplicas continuamente. La migración del servicio para que se ejecute como un trabajo de Container Apps basado en el trabajo disponible en la cola podría ser una opción práctica. Depende del volumen de cola típico y de cómo se escribe el servicio de flujo de trabajo finito, paralelizable y optimizado para recursos. Experimente y compruebe para determinar el mejor enfoque.

Implementación del control de entrada

La carga de trabajo utiliza la función de entrada externa integrada de Container Apps para exponer el servicio de ingestión. El enfoque de control de entrada no proporciona la capacidad de colocar completamente el punto de entrada detrás de un firewall de aplicaciones web (WAF) o incluirlo en los planes de Azure DDoS Protection. Debe hacer frente a todas las cargas de trabajo orientadas a la web con un WAF. Para lograr esta configuración en el entorno de Container Apps, debe deshabilitar la entrada pública integrada y agregar Application Gateway o Azure Front Door.

Nota:

Las puertas de enlace requieren sondeos de estado significativos, que mantienen activo el servicio de ingreso y evitan que se escale a cero.

Modernización con Dapr

Puede modernizar aún más la carga de trabajo mediante la integración con Distributed Application Runtime (Dapr). Agrega abstracción entre el código de carga de trabajo y los almacenes de estado, los sistemas de mensajería y los mecanismos de detección de servicios. Para más información, consulte Desplegar microservicios con Aplicaciones de contenedores y Dapr. Si la carga de trabajo de Kubernetes ya usa escaladores de Dapr o KEDA comunes, la migración a Container Apps suele ser sencilla y puede conservar esa funcionalidad.

Migración a la autenticación y autorización de usuarios

La carga de trabajo no delega la autorización a una puerta de enlace. El servicio de ingestión gestiona la autorización de sus clientes. Un mejor enfoque consiste en descargar esta responsabilidad en la característica integrada de autenticación y autorización, a menudo denominada Easy Auth. Este cambio aprovecha las funcionalidades de la plataforma y reduce el código personalizado en el microservicio de ingesta.

Consideraciones

Las siguientes consideraciones implementan los pilares de Microsoft Azure Well-Architected Framework, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Azure 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 le ayuda a implementar, administrar, mantener y supervisar las aplicaciones de la carga de trabajo. Puede mejorar la confiabilidad siguiendo las recomendaciones principales. Algunas recomendaciones se implementan durante la migración desde Kubernetes.

  • Las revisiones le ayudan a implementar actualizaciones de aplicaciones sin ningún tiempo de inactividad. Puede usar revisiones para administrar la implementación de actualizaciones de aplicaciones y dividir el tráfico entre las revisiones para admitir implementaciones azules o verdes y pruebas A/B.

  • Con las características de observabilidad de Container Apps, tiene información sobre los componentes que se ejecutan en el entorno. Container Apps se integra con Application Insights y Log Analytics. Estos datos se usan para realizar un seguimiento de las operaciones y establecer alertas basadas en métricas y eventos como parte del sistema de observabilidad.

    La supervisión del rendimiento le ayuda a evaluar la aplicación bajo carga. Las métricas y los registros proporcionan datos para reconocer tendencias, investigar errores y realizar análisis de causa raíz.

  • Utilice sondeos de estado y preparación para controlar contenedores de inicio lento y evite enviar tráfico antes de que estén listos. La implementación de Kubernetes incluye estos puntos de conexión. Siga utilizándolas si proporcionan señales eficaces.

  • Cuando un servicio finaliza inesperadamente, Container Apps lo reinicia automáticamente. La detección de servicios está habilitada para que el servicio de flujo de trabajo pueda detectar sus microservicios de bajada. Use políticas de resiliencia para gestionar las expiraciones e introducir la lógica del interruptor de circuito sin necesidad de ajustar más el código.

  • Habilite las reglas de escalado automático para satisfacer la demanda a medida que aumente el tráfico y las cargas de trabajo.

  • Use las características dinámicas de equilibrio de carga y escalado de Container Apps para mejorar la disponibilidad. Sobreaprovisione la subred de su entorno para que siempre tenga suficientes direcciones IP disponibles para futuras réplicas o trabajos.

  • Evite almacenar el estado directamente en el entorno de Container Apps, ya que todo el estado se pierde cuando se cierra la réplica. Externalice el estado a un almacenamiento de estado dedicado para cada microservicio. Esta arquitectura distribuye el estado entre tres almacenes distintos: Azure Managed Redis, Azure Cosmos DB para NoSQL y Azure DocumentDB.

  • Implemente todos los recursos, incluidas las aplicaciones de contenedor, mediante una topología de varias zonas. Para más información, consulte Compatibilidad con zonas de disponibilidad en Container Apps.

    Establezca el número mínimo de réplicas para las aplicaciones no transcientes en al menos una réplica para cada zona de disponibilidad. Durante las condiciones de funcionamiento típicas, las réplicas se distribuyen y equilibran de forma confiable entre las zonas de disponibilidad de la región.

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, vea Lista de comprobación de revisión de diseño para security.

Secretos

  • La aplicación de contenedor puede almacenar y recuperar valores confidenciales como secretos. Después de definir un secreto para la aplicación contenedora, está disponible para su uso por la aplicación y las reglas de escalado asociadas. Si se ejecuta en modo de revisión múltiple, todas las revisiones comparten los mismos secretos. Dado que los secretos se consideran cambios en el ámbito de la aplicación, si cambia el valor de un secreto, no se crea una nueva revisión. Pero para que las revisiones en ejecución carguen el nuevo valor secreto, debe reiniciarlas. En este escenario, se usan los valores de la aplicación y de la variable de entorno.

  • Vuelva a escribir el código del servicio para usar la propia identidad administrada de la aplicación para autenticarse en dependencias en lugar de secretos compartidos previamente. Todas las dependencias tienen SDK que admiten la autenticación de identidad administrada.

  • Puede almacenar de forma segura valores confidenciales en variables de entorno en el nivel de aplicación. Cuando cambian las variables de entorno, la aplicación contenedora crea una nueva revisión.

Seguridad de las redes

  • Para limitar el acceso externo, solo el servicio de ingesta está configurado para la entrada externa. Solo se puede acceder a los servicios back-end a través de la red virtual interna en el entorno de Container Apps y se configuran como modo interno. Solo exponga los servicios a Internet cuando sea necesario.

    Dado que esta arquitectura usa la característica de entrada externa integrada, esta solución no proporciona la capacidad de colocar completamente el punto de entrada detrás de un WAF o incluirlo en los planes de DDoS Protection. Protege todas las cargas de trabajo web con un firewall de aplicaciones web. Para obtener más información sobre las mejoras de entrada, consulte Implementación del control de entrada.

  • Al crear un entorno, puede proporcionar una red virtual personalizada. De lo contrario, Microsoft genera y administra automáticamente una red virtual. No puede manipular esta red virtual administrada por Microsoft, como agregar grupos de seguridad de red (NSG) o forzar el tráfico de tunelización a un firewall de salida. En el ejemplo se usa una red virtual generada automáticamente, pero una red virtual personalizada mejora el control de seguridad. Una red personalizada le permite aplicar NSGs y enrutamiento mediante rutas definidas por el usuario (UDR) a través de Azure Firewall.

Para obtener más información sobre las opciones de topología de red, incluida la compatibilidad con puntos de conexión privados para la entrada, consulte Arquitectura de redes en Container Apps.

Identidades de cargas de trabajo

  • Container Apps admite identidades administradas de Microsoft Entra que permiten que la aplicación se autentique en otros recursos protegidos por el identificador de Microsoft Entra, como Key Vault, sin administrar credenciales en la aplicación contenedora. Una aplicación contenedora puede usar identidades asignadas por el sistema, identidades asignadas por el usuario o ambas. En el caso de los servicios que no admiten la autenticación de Id. de Entra de Microsoft, almacene secretos en Key Vault y use una identidad administrada para acceder a los secretos.

  • Use una identidad administrada dedicada asignada por el usuario para el acceso a Container Registry. Container Apps admite el uso de una identidad administrada diferente para la operación de carga de trabajo que para el acceso al registro de contenedor. Este enfoque proporciona un control de acceso pormenorizado. Si la carga de trabajo tiene varios entornos de Container Apps, no comparta la identidad entre instancias.

  • Utilice identidades administradas asignadas por el sistema para las identidades de carga de trabajo, con el fin de vincular el ciclo de vida de identidad al ciclo de vida del componente de carga de trabajo.

Más recomendaciones de seguridad

  • La implementación de Kubernetes de esta carga de trabajo proporciona protección mediante las funcionalidades de Microsoft Defender para contenedores. En esta arquitectura, Defender for Containers solo evalúa la vulnerabilidad de los contenedores en container Registry. Defender para contenedores no proporciona protección en tiempo de ejecución para Container Apps. Evalúe el complemento con soluciones de seguridad que no son de Microsoft si la protección en tiempo de ejecución es un requisito.

  • No ejecute la carga de trabajo en un entorno compartido de Container Apps. Segméntelo de las cargas de trabajo u otros componentes que no necesiten acceso a estos microservicios. Cree entornos independientes de Container Apps. Las aplicaciones y los trabajos que se ejecutan en un entorno de Container Apps pueden detectar y llegar a cualquier servicio que se ejecute en el entorno con la entrada interna habilitada.

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.

  • Revise una estimación de precios de ejemplo para la carga de trabajo. Use la calculadora de precios de Azure. Las configuraciones varían, por lo que debe ajustarla para que coincida con su escenario.

  • En este escenario, Azure Cosmos DB, Azure Managed Redis y Service Bus Premium son los principales factores de costo.

  • En el caso de los contenedores que normalmente consumen poca cantidad de CPU y memoria, evalúe primero el perfil de carga de trabajo de consumo. Calcule el costo del perfil de consumo en función del uso para ayudar a recopilar datos de costos de línea base y evaluar otros perfiles. Por ejemplo, puede usar un perfil de carga de trabajo dedicado para los componentes que tienen un uso muy predecible y estable y puede compartir nodos dedicados. Para la optimización de costos, mantenga un múltiplo de tres nodos para cada perfil dedicado para garantizar hosts de cómputo suficientes y la distribución de réplicas a través de zonas de disponibilidad.

  • Elimine los costos de proceso durante períodos de inactividad asegurándose de que los componentes se pueden escalar a cero, por lo que solo se paga cuando sea necesario. Este enfoque reduce los gastos de las aplicaciones que tienen un uso variable o poco frecuente. Las verificaciones de estado suelen impedir una reducción completa a cero. En la arquitectura, puede volver a implementar el servicio de flujo de trabajo como tarea para aprovechar las ventajas del escalado a cero durante los períodos de inactividad. Este enfoque se combina bien con cargas de trabajo que pueden usar un plan de consumo.

  • Para evitar cargos de red entre regiones, implemente todos los componentes, como almacenes de estado y el registro de contenedor, en la misma región.

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, vea Lista de comprobación de revisión de diseño para la excelencia operativa.

  • Usar Acciones de GitHub o la integración de Azure Pipelines para configurar canalizaciones automatizadas de integración continua e implementación continua (CI/CD).

  • Use el modo de revisión múltiple con la división de tráfico para probar los cambios en el código de carga de trabajo y las reglas de escalado.

  • Integración con Application Insights y Log Analytics para proporcionar información sobre la carga de trabajo. Usa el mismo espacio de trabajo de Log Analytics que el resto de los componentes de la carga de trabajo para reunir toda la información sobre la carga de trabajo.

  • Use la infraestructura como código (IaC), como Bicep o Terraform, para administrar todas las implementaciones de infraestructura. Las implementaciones incluyen el entorno de Container Apps, el registro de contenedor y los almacenes de estado de microservicio. Separe las canalizaciones de implementación de microservicios de las canalizaciones de infraestructura porque a menudo no comparten un ciclo de vida similar. La canalización declarativa para la infraestructura de Azure debe implementar todos los recursos, excepto los recursos de la aplicación de contenedor.

  • Use un enfoque imperativo para crear, actualizar y quitar aplicaciones de contenedor del entorno. Es especialmente importante si está ajustando dinámicamente la lógica de redireccionamiento del tráfico entre revisiones. Use una acción de GitHub o una tarea de Azure Pipelines en los flujos de trabajo de implementación. Este enfoque imperativo se puede basar en definiciones de aplicaciones YAML . Para minimizar los errores de comprobación de estado, asegúrese siempre de que la canalización rellena el registro de contenedor con la nueva imagen de contenedor antes de implementar la aplicación de contenedor.

    Un cambio importante de la implementación de Kubernetes es el cambio de administrar archivos de manifiesto de Kubernetes, como definir Deployment objetos de Kubernetes. Kubernetes proporciona un enfoque atómico tiene éxito en conjunto o fracasa en conjunto para la implementación de microservicios, a través de este objeto de manifiesto. En Container Apps, cada microservicio se implementa de forma independiente. Las canalizaciones de implementación se convierten en responsables de orquestar cualquier estrategia de secuenciación y reversión necesaria para tener una implementación segura.

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.

  • La carga de trabajo se distribuye entre varias aplicaciones de microservicios.

  • Cada microservicio es independiente y no comparte ningún estado con otros microservicios, lo que permite el escalado independiente.

  • Use trabajos de Container Apps para ejecuciones de procesos finitos para implementar tiempos de ejecución transitorios y reducir el consumo de recursos para los servicios inactivos. Evalúe las implicaciones de rendimiento de los trabajos giratorios hacia arriba y hacia abajo frente a mantener los componentes calientes y listos.

  • El escalado automático está habilitado. Se prefiere el escalado basado en eventos a través del escalado basado en métricas siempre que sea posible. Por ejemplo, el servicio de flujo de trabajo, si está diseñado para soportarlo, podría escalar según la profundidad de la cola de Service Bus. El escalador automático predeterminado se basa en solicitudes HTTP. Durante una replataformación, es importante empezar con el mismo enfoque de escalado y luego evaluar las optimizaciones de escalado más adelante.

  • Las solicitudes se equilibran dinámicamente con la carga de las réplicas disponibles de una revisión.

  • Las métricas, incluido el uso de cpu, memoria, información de ancho de banda y almacenamiento, están disponibles a través de Azure Monitor.

Implementación de este escenario

Siga los pasos del README.md en el repositorio de escenarios de ejemplo de Container Apps.

Colaboradores

Microsoft se encarga del mantenimiento de este artículo. Los colaboradores siguientes escribieron este artículo.

Colaboradores:

Pasos siguientes