Diseño con la resiliencia en mente
 La carga de trabajo debe seguir funcionando con una funcionalidad completa o reducida. |
|---|
Cabe esperar que se produzcan errores en los componentes, interrupciones en la plataforma, degradaciones del rendimiento y otros problemas. Cree un sistema resistente que tolere errores y pueda degradarse correctamente.
Escenario de ejemplo
Contoso Air es una aerolínea comercial que tiene un departamento de desarrollo interno. La aplicación de línea de negocio es una solución de reserva que permite a los clientes reservar vuelos directamente con Contoso Air. La aplicación está integrada en Azure y usa Azure App Service, Cosmos DB, Azure Functions, Azure Logic Apps y Azure Service Bus.
Determinación de riesgos de error
Identifique posibles puntos de error en el sistema, especialmente para los componentes críticos, y determine el efecto en los flujos de usuario y sistema.
Analice el caso de error, el radio de explosión y la intensidad del error de cada posible punto de error. Los casos de error y su intensidad pueden variar, desde escenarios de impacto relativamente bajo —como la pérdida temporal de un proceso de back-end— a interrupciones a escala completa causadas por desastres. Realizar este análisis le ayuda a determinar el diseño de las funcionalidades de control de errores a nivel de componente.
Desafío de Contoso
- La aplicación de línea de negocio proporciona muchas funciones clave, desde el marketing hasta el comercio. El flujo de usuario de compra de vales se ha identificado como el flujo más crítico. El equipo de cargas de trabajo ha determinado que se deben implementar más medidas de fiabilidad para asegurarse de que el flujo está optimizado para ser resistente.
- Se ha asignado al equipo un tiempo limitado para hacer mejoras, como desacoplar los componentes y rediseñar los flujos, pero quiere asegurarse de que usa ese tiempo para centrarse en las mejoras de más valor.
Aplicación del enfoque y los resultados
- El equipo identifica la puerta de enlace de pago externa como un posible punto de error. La puerta de enlace es de alta disponibilidad, pero puede que los usuarios experimenten errores temporales ocasionales resultantes de problemas de red o rachas de solicitudes extremadamente altas. La puerta de enlace puede rechazar algunas solicitudes cuando se sobrecarga debido al envío de varias solicitudes a la vez.
- El equipo determina que los usuarios deben volver a enviar las solicitudes cuando la puerta de enlace rechaza sus solicitudes iniciales, lo que provoca una experiencia de usuario negativa.
Implementación de mecanismos de autoconservación
Cree funcionalidades de autoconservación mediante patrones de diseño correctos y una modularización del diseño que aísle los errores.
Al crear funcionalidades de autoconservación en el sistema, podrá evitar que un problema afecte a los componentes de bajada. El sistema podrá mitigar errores transitorios y permanentes, cuellos de botella de rendimiento y otros problemas que podrían afectar a la fiabilidad. También podrá minimizar el radio de explosión.
Desafío de Contoso
- El equipo quiere minimizar el riesgo de errores temporales que hacen que la puerta de enlace de pago rechace las solicitudes de los usuarios. Debido a la naturaleza temporal de algunas de las condiciones de error, es bastante probable que la misma solicitud se realice correctamente si se vuelve a enviarse.
Aplicación del enfoque y los resultados
- El equipo desarrolla una lógica personalizada en el flujo para reintentar la transacción después de un breve retraso, cuando se detecte una situación de error temporal que permita reintentos.
- El diseño de la solución se modificará para incorporar el patrón de reintento, lo que aumenta ligeramente el tiempo de espera entre reintentos hasta que se procesa correctamente la solicitud o se alcanza el número máximo de errores.
- El equipo también decide desacoplar la interacción del usuario y la funcionalidad de procesamiento de pagos de back-end de este flujo mediante un enfoque controlado por eventos con Azure Service Bus. Cuando se producen errores irrecuperables al procesar el mensaje (después del número máximo de reintentos), el procesador back-end abandona el procesamiento de esa solicitud, dejando el mensaje en la cola para que se pueda volver a procesar más adelante.
Creación de redundancia y resistencia exhaustivas
Cree redundancia en capas y resistencia en varios niveles de aplicación.
Intente lograr una redundancia en utilidades físicas y la replicación de datos inmediata. Además, busque una redundancia a nivel funcional que abarque los servicios, las operaciones y el personal. La redundancia ayuda a minimizar los puntos únicos de error. Por ejemplo, si hay una interrupción que afecta a uno o varios componentes, una zona de disponibilidad o una región completa, una implementación redundante (activa-activa o activa-pasiva) le permite cumplir los objetivos de tiempo de actividad.
Agregar intermediarios impide la dependencia directa entre los componentes y mejora el almacenamiento en búfer. Ambas ventajas protegen la resistencia del sistema.
Desafío de Contoso
- La implementación de reintentos y el desacoplamiento de las llamadas a la puerta de enlace de pago desde la interfaz de usuario mediante Service Bus ha aumentado considerablemente la fiabilidad de este flujo, pero las partes interesadas de la empresa siguen preocupadas por la pérdida de datos que puede producirse debido a un error catastrófico en la región primaria.
Aplicación del enfoque y los resultados
- El equipo decide actualizar al nivel Premium de Service Bus. Al hacerlo, puede aprovechar las ventajas de la funcionalidad de compatibilidad de Availability Zones de ese nivel. Con esta funcionalidad, varias copias de los datos se almacenan en tres instalaciones separadas físicamente (zonas de disponibilidad) y el servicio tiene suficientes reservas de capacidad para hacer frente inmediatamente a una pérdida completa y grave de un centro de datos.
- Además, el equipo configura la recuperación ante desastres geográfica de Azure Service Bus para replicar continuamente los datos en una región secundaria que se usará en el improbable caso de un error completo de la región primaria.