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), que este artículo hace referencia al enfoque de Kubernetes. Esta arquitectura reubica la carga de trabajo en Container Apps como su 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 el enfoque existente tanto como sea posible, y aplazar las optimizaciones de código o infraestructura que pueden poner en peligro la migración.

Para una carga de trabajo greenfield, consulta Implementación de microservicios mediante Container Apps y Dapr.

Arquitectura

Descargue un archivo Visio de esta arquitectura.

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

Ingreso interno y detección de servicios
Un área de trabajo única de Log Analytics para registro de ejecución
Un método de administración seguro para secretos y certificados

Flujo de datos

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.
Servicio de flujo de trabajo: Consume mensajes de Service Bus y los envía a los microservicios subyacentes.
Servicio de paquetes: administra paquetes. El servicio mantiene su propio estado en Azure Cosmos DB.
Servicio programador de drones: programa drones y supervisa los drones en vuelo. El servicio mantiene su propio estado en Azure Cosmos DB.
Servicio de entrega: Administra las entregas programadas o en tránsito. El servicio mantiene su propio estado en Azure Managed Redis.
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.
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.
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 del enfoque de Kubernetes:
- 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 KEDA (Escalado Automático Basado en Eventos impulsado por 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 el enfoque de Kubernetes.
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 está instrumentado con Azure Monitor OpenTelemetry Distro 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 en el 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.
Implemente tanto la infraestructura como la carga de trabajo con archivos Bicep: no se necesitaba ningún manifiesto de YAML de Kubernetes para implementar sus contenedores de aplicaciones.
Exponer la aplicación a través de un punto de entrada administrado. La compatibilidad integrada con un punto de entrada externo basado en HTTPS para exponer el servicio de ingesta eliminó la necesidad de configurar su propio punto de 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

Implementar una aplicación existente basada en microservicios en una plataforma como servicio (PaaS) para simplificar la administración y evitar la complejidad que supone ejecutar un orquestador de contenedores. La carga de trabajo existente ahorró dinero al utilizar esta arquitectura en lugar de su implementación en Kubernetes por las siguientes razones:

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 la aplicación y de cualquier sidecar necesario. 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 resultar más económicos que ejecutar réplicas de forma continua. Migrar el servicio para que se ejecute como un trabajo de Container Apps en función del 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. Es necesario proteger 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 pasarelas requieren pruebas de estado significativas, que mantienen activo el servicio de entrada y evitan que se reduzca 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 la 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.
Utiliza pruebas de estado y disponibilidad para administrar los contenedores de arranque lento y evitar enviar tráfico antes de que estén listos. El enfoque 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. Utiliza directivas de resiliencia para administrar los tiempos de espera e introducir la lógica de circuit breaker sin necesidad de realizar ajustes adicionales en 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 seguridad.

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.
Restrinja el acceso de red a los servicios PaaS de respaldo que tienen compatibilidad disponible con carácter general para el perímetro de seguridad de red, como Microsoft.ServiceBus/namespaces y Microsoft.KeyVault/vaults, en lugar de dejar abiertos sus puntos de conexión públicos. Azure perímetro de seguridad de red permite asociar estos recursos a un perímetro compartido y definir reglas de acceso de entrada, sin necesidad de una red virtual personalizada. Dado que en este ejemplo se usa una red virtual generada automáticamente y no tiene ninguna dirección IP de salida estática para las aplicaciones de contenedor, establezca el ámbito de las reglas de acceso de entrada por suscripción (la que hospeda el entorno de Container Apps) en lugar de por intervalo IP, lo que requiere que una dirección IP de origen estable y conocida sea efectiva.

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 para 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.
Use identidades administradas asignadas por el sistema para cargas de trabajo para vincular el ciclo de vida de identidad al ciclo de vida del componente de carga de trabajo.

Más recomendaciones de seguridad

El enfoque de Kubernetes para esta carga de trabajo proporciona protección mediante el uso de Microsoft Defender para funcionalidades de 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 estimación preconfigurada en 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 optimizar los costes, mantén un múltiplo de tres nodos por cada perfil dedicado, a fin de garantizar un número suficiente de hosts de proceso y una distribución adecuada de las réplicas entre las 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 comprobaciones de estado suelen impedir la escalabilidad completa a cero. En la arquitectura, puede reimplementar el servicio de flujo de trabajo como una tarea para aprovechar la escalabilidad a cero durante los periodos 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. Su canalización declarativa para la infraestructura de Azure debe implementar todos los recursos, excepto los de la aplicación en contenedor.
Use un enfoque imperativo para crear, actualizar y quitar aplicaciones de contenedor del entorno. Esto 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 en las comprobaciones de estado, asegúrese siempre de que su canalización rellene su registro de contenedores con la nueva imagen de contenedor antes de implementar la aplicación en contenedor.

Un cambio importante con respecto al enfoque de Kubernetes es el paso de la administración de archivos de manifiesto de Kubernetes, como la definición de Deployment objetos de Kubernetes. Kubernetes proporciona un enfoque atómico se ejecuta o genera un error en su totalidad para la implementación de microservicios, a través de este objeto de manifiesto. En Container Apps, cada microservicio se implementa de forma independiente. Tus canalizaciones de implementación se encargan de orquestar cualquier estrategia de secuenciación y reversión necesaria para garantizar 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.
Utiliza los trabajos de Container Apps para ejecuciones de procesos finitas con el fin de implementar tiempos de ejecución transitorios y reducir el consumo de recursos de los servicios inactivos. Evalúa las implicaciones en el rendimiento de iniciar y detener trabajos frente a mantener los componentes activos 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 entre 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.

Colaboradores

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

Colaboradores:

Julien Strebler | Arquitecto de soluciones en la nube
Steve Caravajal | Arquitecto de soluciones en la nube
Simon Kurtz | Arquitecto de soluciones en la nube

Pasos siguientes

Documentación de Container Apps

Oharrak

Lagungarria al da orri hau?