Exportar (0) Imprimir
Expandir todo

Patrones de mensajería asincrónica y alta disponibilidad

Actualizado: enero de 2014

La mensajería asincrónica se puede implementar de varias formas. Con colas, temas y suscripciones, denominados en conjunto entidades de mensajería, Service Bus de Windows Azure admite asincronía mediante un mecanismo de almacenamiento y reenvío. En el funcionamiento normal (sincrónico), se envían mensajes a colas y temas, y se reciben mensajes de colas y suscripciones. Las aplicaciones que usted escribe dependen de que estas entidades estén siempre disponibles. Cuando el estado de mantenimiento de la entidad cambia, debido a una gran variedad de circunstancias, necesita un modo de proporcionar una entidad de capacidad reducida que pueda satisfacer la mayor parte de las necesidades.

Las aplicaciones suelen usar patrones de mensajería asincrónica para habilitar numerosos escenarios de comunicación. Puede compilar aplicaciones en las que los clientes puedan enviar mensajes a servicios, incluso cuando un servicio no se esté ejecutando. Para las aplicaciones que experimentan una ráfaga de comunicaciones, una cola puede ayudar a equilibrar la carga proporcionando un lugar para almacenar en búfer las comunicaciones. Finalmente, puede obtener un equilibrador de carga sencillo pero eficaz que distribuya los mensajes entre varias máquinas.

Con el fin de mantener la disponibilidad de cualquiera de estas entidades, considere diferentes formas en las que estas entidades pueden aparecer como no disponibles para un sistema de mensajería durable. En términos generales, vemos que la entidad deja de estar disponible para aplicaciones que escribimos de las siguientes formas:

  1. No puede enviar mensajes.

  2. No puede recibir mensajes.

  3. No puede administrar entidades (crear, recuperar, actualizar o eliminar entidades).

  4. No puede ponerse en contacto con el servicio.

Para cada uno de estos errores, existen modos de error diferentes que permiten que una aplicación continúe funcionando con cierta reducción de su capacidad. Por ejemplo, un sistema que puede enviar mensajes pero no recibirlos puede continuar recibiendo pedidos de clientes pero no procesar esos pedidos. En este tema se tratan posibles problemas que pueden ocurrir y cómo mitigarlos. Service Bus ha introducido una serie de mitigaciones en las que debe participar y se tratan también las reglas que controlan el uso de estas mitigaciones de participación.

Fiabilidad en Service Bus

Hay varias formas de controlar los problemas de mensajería y entidades, y existen directrices que rigen el uso adecuado de esas mitigaciones. Para comprender las directrices, debe tener claro primero qué puede dar error en Service Bus. Debido al diseño de los sistemas de Windows Azure, todos estos problemas tienden a ser efímeros. En gran medida, las diferentes causas de la no disponibilidad pueden ser:

  • Limitación por un sistema externo del que depende Service Bus. La limitación tiene lugar por interacciones con los recursos de almacenamiento y proceso.

  • Un problema en un sistema del que depende Service Bus. Por ejemplo, puede haber problemas en una parte determinada del almacenamiento.

  • Error de Service Bus en un subsistema. En esta situación, un nodo de ejecución puede entrar en un estado incoherente y tener que reiniciarse, lo que da lugar a que todas las entidades a las que sirve tengan que equilibrar la carga en otros nodos. Esto a su vez puede producir un breve período de procesamiento lento de los mensajes.

  • Un error de Service Bus en un centro de datos de Windows Azure. Este es el clásico “error catastrófico” durante el cual no se puede obtener acceso al sistema durante muchos minutos o varias horas.

noteNota
El término almacenamiento puede significar tanto almacenamiento de Windows Azure como de SQL Azure.

Service Bus contiene una serie de mitigaciones para estos problemas. En las secciones siguientes se trata cada uno de estos problemas y sus mitigaciones.

Limitación

Con Service Bus, la limitación permite la administración cooperativa de la velocidad de los mensajes. Cada nodo de Service Bus alberga muchas entidades. Cada una de esas entidades demanda recursos del sistema en términos de CPU, memoria, almacenamiento y otras facetas. Cuando alguna de estas facetas detecta un uso que supera los umbrales definidos, Service Bus puede denegar una solicitud determinada. El llamador recibe ServerBusyException y lo reintenta transcurridos 10 segundos.

Como mitigación, el código debe leer el error y detener cualquier reintento del mensaje durante al menos 10 segundos. Puesto que el error puede producirse en varias partes de la aplicación del cliente, se espera que cada parte ejecute la lógica de reintento de forma independiente. El código puede reducir la probabilidad de verse limitado habilitando el particionamiento en una cola o un tema.

Problema con una dependencia de Windows Azure

Otros componentes de Windows Azure puede tener a veces problemas de servicio. Por ejemplo, cuando se actualiza un sistema que usa Service Bus, ese sistema puede tener una funcionalidad reducida temporalmente. Para solucionar estos tipos de problemas, Service Bus investiga periódicamente e implementa mitigaciones. Pero estas mitigaciones tienen efectos colaterales. Por ejemplo, para controlar problemas transitorios de almacenamiento, Service Bus implementa un sistema que permite que las operaciones de envío de mensajes funcionen de forma constante. Debido a la naturaleza de la mitigación, un mensaje enviado puede tardar hasta 15 minutos en aparecer en la cola o suscripción afectadas y estar listo para una operación de recepción. En general, la mayoría de las entidades no tendrán este problema. Sin embargo, dado el número de entidades de Service Bus en Windows Azure, esta mitigación es necesaria a veces para un reducido grupo de clientes de Service Bus.

Error de Service Bus en un único subsistema

Con cualquier aplicación, las circunstancias pueden dar lugar a que un componente interno de Service Bus adquiera un estado inestable. Cuando Service Bus lo detecta, recopila datos de la aplicación para diagnosticar lo que ha ocurrido. Una vez recopilados los datos, se reinicia la aplicación en un intento de devolverla a un estado coherente. Este proceso se lleva a cabo con bastante rapidez y tiene como resultado que una entidad aparezca como no disponible durante algunos minutos, pero los típicos períodos de inactividad son más cortos.

En estos casos, la aplicación de cliente genera una excepción TimeoutException o MessagingException. El SDK de Service Bus .NET contiene una mitigación para este problema en forma de lógica de reintento de cliente automatizado. Una vez que ha transcurrido el período de reintento y que el mensaje no se ha entregado, puede probar con otras características como los espacios de nombres emparejados. Los espacios de nombres emparejados tienen otras salvedades que se tratan más adelante en este documento.

Error de Service Bus en un centro de datos de Azure

El motivo más probable de un error en un centro de datos de Azure es un error de actualización de Service Bus o de un sistema dependiente. Conforme ha madurado la plataforma, ha disminuido la probabilidad de este tipo de error. Un error de centro de datos puede deberse también a los siguientes motivos:

  • Interrupción del suministro eléctrico (desaparecen el suministro eléctrico y la generación de energía).

  • Conectividad (interrupción de la conexión a Internet entre los clientes y Windows Azure).

En ambos casos, es un desastre natural o causado por el hombre lo que produce el problema. Para solucionarlo y asegurarse de que aún se pueden enviar mensajes, puede usar espacios de nombres emparejados para que se puedan enviar los mensajes a una segunda ubicación mientras se devuelve la ubicación principal a un estado correcto.

Espacios de nombres emparejados

La característica de espacios de nombres emparejados ayuda en los casos en que una entidad o implementación de Service Bus en un centro de datos deja de estar disponible. Si bien este evento es poco frecuente, los sistemas distribuidos deben estar preparados para controlar la situación en el peor de los casos. Normalmente, este evento se produce porque algún elemento del que depende Service Bus está teniendo un problema pasajero. Para mantener la disponibilidad de una aplicación durante una interrupción, los usuarios de Service Bus puede usar dos espacios de nombres diferentes, preferiblemente en centros de datos diferentes, para hospedar sus entidades de mensajería. En el resto de esta sección se usa la siguiente terminología:

  • Espacio de nombres principal: espacio de nombres con el que interactúa la aplicación para operaciones de envío y recepción.

  • Espacio de nombres secundario: espacio de nombres que actúa como respaldo del espacio de nombres principal. La lógica de la aplicación no interactúa con este espacio de nombres.

  • Intervalo de conmutación por error: cantidad de tiempo que se aceptan errores normales antes de que la aplicación cambie del espacio de nombres principal al espacio de nombres secundario.

Los espacios de nombres emparejados admiten disponibilidad de envío. La disponibilidad de envío se centra en mantener la capacidad de enviar mensajes. Para usar la disponibilidad de envío, la aplicación debe cumplir los siguientes requisitos:

  1. Solo se reciben mensajes del espacio de nombres principal.

  2. Los mensajes enviados a una cola o un tema determinados pueden llegar desordenados.

  3. Si la aplicación usa sesiones:

    1. Los mensajes de una sesión podrían llegar desordenados. Esta es una interrupción del funcionamiento normal de las sesiones. Significa que la aplicación usa sesiones para agrupar los mensajes de forma lógica.

    2. El estado de la sesión se mantiene únicamente en el espacio de nombres principal.

  4. La cola principal puede conectarse y comenzar a aceptar mensajes antes de que la cola secundaria entregue todos los mensajes a la cola principal.

En esta sección se trata la API, cómo se implementan las API y se muestra un ejemplo de código que usa esta característica. Tenga en cuenta que esta característica conlleva costes.

API MessagingFactory.PairNamespaceAsync

La característica de espacios de nombres emparejados incluye el nuevo método que se indica a continuación en la clase MessagingFactory:

public Task PairNamespaceAsync(PairedNamespaceOptions options)

Cuando se completa la tarea, el emparejamiento de espacios de nombres está completo también y listo para actuar para cualquier MessageReceiver, QueueClient o TopicClient creado con MessagingFactory. PairedNamespaceOptions es la clase base para los diferentes tipos de emparejamiento disponibles con MessagingFactory. Actualmente, la única clase derivada es SendAvailabilityPairedNamespaceOptions, que implementa los requisitos de disponibilidad de envío. SendAvailabilityPairedNamespaceOptions tiene un conjunto de constructores que se basan unos en otros. Mirando el constructor con la mayor parte de los parámetros, se puede comprender el comportamiento de los demás constructores.

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

Estos parámetros tienen los siguientes significados:

  • secondaryNamespaceManager: instancia de NamespaceManager inicializada para el espacio de nombres secundario que el método PairNamespaceAsync puede usar para configurar el espacio de nombres secundario. Se usará el administrador para obtener la lista de colas del espacio de nombres y asegurarse de que existen las colas de trabajo pendiente necesarias. Si esas colas no existen, se crearán. NamespaceManager requiere la capacidad para crear un token con la notificación Manage.

  • messagingFactory: instancia de MessagingFactory para el espacio de nombres secundario. MessagingFactory se usa para enviar y, si la propiedad EnableSyphon está establecida en true, para recibir mensajes de las colas de trabajo pendiente.

  • backlogQueueCount: número de colas de trabajo pendiente que se deben crear. Este valor debe ser al menos 1. Cuando se envían mensajes al trabajo pendiente, se elige una de estas colas de forma aleatoria. Si establece el valor en 1, solo se puede usar una cola. Cuando esto ocurre y la cola de trabajo pendiente genera errores, el cliente no puede probar con otra cola de trabajo pendiente y es posible que no pueda enviar el mensaje. Se recomienda establecer este valor en un número mayor y usar 10 como valor predeterminado. Puede cambiarlo a un valor mayor o menor en función de la cantidad de datos que la aplicación envíe al día. Cada cola de trabajo pendiente puede albergar hasta 5 GB de mensajes.

  • failoverInterval: período de tiempo que se aceptarán errores en el espacio de nombres principal antes de cambiar una sola entidad al espacio de nombres secundario. Las entidades conmutan por error de una en una. Las entidades de un mismo espacio de nombres a menudo residen en nodos diferentes en Service Bus. Un error en una entidad no implica un error en otra. Puede establecer este valor en Zero para realizar la conmutación por error al espacio de nombres secundario inmediatamente después del primer error no transitorio. Los errores que activan el temporizador de conmutación por error son alguna excepción MessagingException en la que la propiedad IsTransient es false, o bien una excepción TimeoutException. Otras excepciones, como UnauthorizedAccessException, no producirán una conmutación por error, porque indican que el cliente está mal configurado. Una excepción ServerBusyException no produce una conmutación por error porque el patrón correcto es esperar 10 segundos y volver a enviar el mensaje.

  • enableSyphon: indica que este emparejamiento en concreto también debe extraer con el sifón los mensajes del espacio de nombres secundario de nuevo al espacio de nombres principal. En general, las aplicaciones que envían mensajes deben establecer este valor en false; las aplicaciones que reciben mensajes deben establecer este valor en true. El motivo para esto es que, con frecuencia, hay menos receptores de mensajes que remitentes de mensajes. Dependiendo del número de receptores, puede elegir tener una sola instancia de la aplicación que controle las tareas de sifón. El uso de muchos receptores conlleva costes para cada cola de trabajo pendiente.

Para usar el código, cree una instancia principal de MessagingFactory, una instancia secundaria de MessagingFactory, una instancia secundaria de NamespaceManager y una instancia de SendAvailabilityPairedNamespaceOptions. La llamada puede ser tan simple como esta:

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

Cuando se complete la tarea devuelta por el método PairNamespaceAsync, todo estará configurado y listo para usar. Antes de que se devuelva la tarea, es posible que no haya completado todo el trabajo en segundo plano necesario para que funcione el emparejamiento. Por tanto, no deberá comenzar a enviar mensajes hasta que se devuelva la tarea. Si se produce algún error, como credenciales incorrectas o un error al crear las colas de trabajo pendiente, esas excepciones se producirán una vez que se complete la tarea. Cuando se devuelva la tarea, compruebe que se encontraron o se crearon las colas. Para ello, examine la propiedad BacklogQueueCount en la instancia de SendAvailabilityPairedNamespaceOptions. Para el código anterior, esa operación aparece del siguiente modo:

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

Adiciones de comunidad

Mostrar:
© 2014 Microsoft