Exportar (0) Imprimir
Expandir todo

Prácticas recomendadas para maximizar la escalabilidad y la rentabilidad de las soluciones de mensajería basadas en cola en Azure

Actualizado: marzo de 2015

Autor: Amit Srivastava y Valery Mizonov

Revisores: Brad Calder, Sidney Higa, Christian Martinez, Steve Marx, Curt Peterson, Paolo Salvatori y Trace Young

Este artículo proporciona una orientación descriptiva y prácticas recomendadas para crear soluciones escalables de mensajería basadas en cola muy eficaces y rentables en la plataforma de Azure. Entre los destinatarios de este artículo se incluyen los arquitectos y los desarrolladores de soluciones que diseñan e implementan soluciones basadas en la nube que desean aprovechar los servicios de almacenamiento de cola de la plataforma de Azure.

Una solución de mensajería basada en cola tradicional usa el concepto de ubicación de almacenamiento de mensajes conocida como cola de mensajes, que es un repositorio de los datos que se enviarán o se recibirán de uno o varios participantes, normalmente mediante un mecanismo de comunicación asincrónica.

El propósito de este artículo es examinar el modo en que los desarrolladores pueden beneficiarse de patrones concretos de diseño junto con las funciones proporcionadas por la plataforma de Azure para generar soluciones de mensajería basadas en cola optimizadas y rentables. En el artículo se profundiza en las soluciones que más se usan para implementar las interacciones basadas en cola en las soluciones de Azure y se ofrecen recomendaciones para mejorar el rendimiento, aumentar la escalabilidad y reducir los gastos de explotación.

La explicación subyacente se combina con prácticas recomendadas, sugerencias y recomendaciones relacionadas, si procede. El escenario descrito en este artículo resalta una implementación técnica que se basa en un proyecto real del cliente.

Una solución típica de mensajería que intercambia datos entre sus componentes distribuidos usando colas de mensajes incluye a los publicadores que depositan los mensajes en las colas y a uno o varios suscriptores destinados a recibir los mensajes. En la mayoría de los casos, los suscriptores, en ocasiones conocidos como agentes de escucha de cola, se implementan como procesos multiproceso o de un solo proceso y se ejecutan continuamente o se inician a petición como en un modelo de programación.

En un nivel superior, se usan dos mecanismos principales de envío para permitir que un agente de escucha de cola reciba los mensajes almacenados en una cola:

  • Sondeo (modelo basado en la extracción): un agente de escucha supervisa una cola comprobando a intervalos regulares si hay mensajes nuevos. Cuando la cola está vacía, el agente de escucha continúa sondeando la cola, retrocediendo periódicamente mientras entra en un estado en suspensión.

  • Activación (modelo basado en la inserción): un agente de escucha se suscribe a un evento desencadenado (ya sea por el propio publicador o por el administrador del servicio de cola) siempre que un mensaje llega a una cola. El agente de escucha a su vez puede iniciar el procesamiento de los mensajes, por lo que no es necesario sondear la cola para determinar si hay disponible un nuevo trabajo o no.

También conviene mencionar que hay diferentes variaciones de los dos mecanismos. Por ejemplo, el sondeo puede ser con bloqueo y sin bloqueo. Si hay bloqueo, se mantiene una solicitud en espera hasta que un mensaje nuevo aparece en una cola (o se agota un tiempo de espera) mientras que una solicitud sin bloqueo se completa inmediatamente si no hay nada en una cola. Con un modelo de activación, se puede insertar una notificación en los agentes de escucha de la cola con cada nuevo mensaje, solo cuando el primer mensaje llega a una cola vacía o cuando la profundidad de la cola alcanza un cierto nivel.

noteNota
Las operaciones de eliminación de cola que admite la API del servicio Cola de Azure son sin bloqueo. Esto significa que los métodos de la API como GetMessage o GetMessages volverán inmediatamente si no se encuentra ningún mensaje en una cola. Por el contrario, las colas de Service Bus de Azure ofrecen operaciones de recepción con bloqueo que bloquean al subproceso de llamada hasta que un mensaje llega a una cola o hasta que ha transcurrido un tiempo de espera especificado.

El enfoque más común para implementar agentes de escucha de cola en las soluciones de Azure actualmente puede resumirse de la forma siguiente:

  1. Un agente de escucha se implementa como un componente de aplicación del que se crea una instancia y se ejecuta como parte de una instancia de rol de trabajo.

  2. El ciclo de vida del componente agente de escucha de la cola con frecuencia se enlazaría al runtime de la instancia del rol que lo hospeda.

  3. La lógica de proceso principal consta de un bucle en el que los mensajes se quitan de la cola y se envían para ser procesados.

  4. Si no se recibe ningún mensaje, el subproceso que escucha entra en un estado de suspensión cuya duración suele determinarse en un algoritmo de retroceso específico de la aplicación.

  5. El bucle de recepción se ejecuta y una cola se sondea hasta que se notifica al agente de escucha para que salga del bucle y termine.

El siguiente diagrama de flujo describe la lógica más usada al implementar un agente de escucha de la cola con un mecanismo de sondeo en las aplicaciones de Azure:

Procedimientos-recomendados-Soluciones-de-mensajería-Azure2
noteNota
Dada la finalidad de este artículo, no se utilizan patrones más complejos de diseño, por ejemplo los que requieren el uso de un administrador de cola central (agente).

El uso de un agente de escucha de cola clásico con un mecanismo de sondeo puede no ser la opción óptima cuando se utilizan colas de Azure porque el modelo de precios de Azure mide las transacciones de almacenamiento en función de las solicitudes de aplicación realizadas en la cola, independientemente de si esta está vacía o no. El propósito de las secciones siguientes es explicar algunas técnicas para maximizar el rendimiento y minimizar el costo de las soluciones de mensajería basadas en cola en la plataforma de Azure.

En esta sección debemos examinar cómo mejorar los aspectos relevantes de diseño para lograr un mayor rendimiento, mejor escalabilidad y mayor rentabilidad.

Quizás, la manera más fácil de calificar un modelo de implementación como “solución más eficiente" sería a través de un diseño que cumpliera los siguientes objetivos:

  • Reducir los gastos operativos quitando una parte significativa de las transacciones de almacenamiento que no aporten ningún trabajo útil.

  • Eliminar la latencia excesiva impuesta por un intervalo de sondeo al comprobar una cola por si hay nuevos mensajes.

  • Ampliar y reducir de modo dinámico adaptando la capacidad de procesamiento a los volúmenes de trabajo volátiles.

El modelo de implementación también debe satisfacer estos objetivos sin introducir un nivel de complejidad que sobrepase en efecto los beneficios asociados.

Al evaluar el costo total de propiedad (TCO) y la rentabilidad de la inversión (ROI) de una solución implementada en la plataforma de Azure, el volumen de las transacciones de almacenamiento es una de las variables principales de la ecuación de TCO. Al reducir el número de transacciones en las colas de Azure, se reducen los gastos de explotación puesto que están relacionados con las soluciones actuales de Azure.

El coste del espacio de almacenamiento asociado con la Cola de Azure se puede calcular como:

espacio de la cola: 24 bytes + Len(QueueName) * 2 +  Para cada metadato (4 bytes + Len(QueueName) * 2 bytes + Len(Value) * 2 bytes)

Espacio del mensaje: 12 bytes + Len(Message)

En el contexto de una solución de mensajería basada en cola, el volumen de las transacciones de almacenamiento se puede reducir mediante una combinación de los métodos siguientes:

  1. Al colocar los mensajes en una cola, agrupe los mensajes relacionados en un único lote mayor, comprima y almacene la imagen comprimida en un almacén de blobs y use la cola para mantener una referencia al blob que contiene los datos reales. Este enfoque ayuda a optimizar el coste de las transacciones y el coste del espacio de almacenamiento.

  2. Al recuperar los mensajes de una cola, agrupe varios mensajes en una única transacción de almacenamiento. El método GetMessages de la API del servicio Cola permite sacar de la cola el número de mensajes especificado en una sola transacción (vea la nota a continuación).

  3. Al comprobar la presencia de elementos de trabajo en una cola, evite intervalos de sondeo demasiado largos e implemente una espera de retroceso que aumente el tiempo transcurrido entre las solicitudes de sondeo si una cola permanece continuamente vacía.

  4. Reduzca el número de agentes de escucha de cola. Al usar un modelo basado en la extracción, use solo un agente de escucha de cola por cada instancia de rol cuando una cola esté vacía. Para reducir más, a cero, el número de agentes de escucha de cola por cada instancia de rol, utilice un mecanismo de notificación para crear una instancia de los agentes de escucha de cola cuando la cola reciba elementos de trabajo.

  5. Si las colas permanecen vacías la mayor parte del tiempo, reduzca automáticamente el número de instancias de rol y continúe supervisando las métricas del sistema pertinentes para determinar si la aplicación debe aumentar proporcionalmente el número de instancias para controlar una carga de trabajo creciente y cuándo.

  6. Implemente un mecanismo para quitar los mensajes dudosos. Los mensajes dudosos suelen ser mensajes con formato incorrecto que la aplicación no puede procesar. Si se dejan sin procesar, estos mensajes podrían acumularse y generar costes transaccionales y de procesamiento repetidos. Un mecanismo sencillo de implementación podría ser quitar de la cola los mensajes más antiguos que la duración del umbral y escribirlos en un sistema de archivado para la evaluación posterior.

  7. Reduzca los errores por tiempo de espera esperado. Cuando envía una solicitud a un servicio, puede especificar su propio tiempo de espera y configurarlo para que sea menor que el tiempo de espera del SLA. En este escenario, cuando la solicitud agota el tiempo de espera, se clasifica como un tiempo de espera esperado y se cuenta como transacción facturable.

La mayoría de las recomendaciones anteriores se pueden traducir en una implementación bastante genérica que administre los lotes de mensajes y encapsule muchas de las operaciones subyacentes de almacenamiento en cola y blobs y de administración de subprocesos. Más adelante en este artículo, examinaremos cómo hacer esto.

ImportantImportante
Al recuperar los mensajes a través del método GetMessages, el tamaño de lote máximo admitido por la API del servicio Cola en una sola operación de eliminación de cola se limita a 32.

En general, el costo de las transacciones de cola de Azure aumenta linealmente a medida que el número de clientes del servicio Cola sube, por ejemplo, al incrementar el número de instancias de rol o de subprocesos de eliminación de cola. Para mostrar el posible impacto en el costo del diseño de una solución que no aprovecha las recomendaciones anteriores, suministraremos un ejemplo respaldado por cifras concretas.

Si el arquitecto de soluciones no implementa las optimizaciones pertinentes, la arquitectura del sistema de facturación descrita antes probablemente supondrá unos gastos de explotación excesivos una vez que la solución esté implementada y en ejecución en la plataforma de Azure. Los motivos de ese posible gasto excesivo se describen en esta sección.

Como se señalaba en la definición del escenario, los datos de las transacciones empresariales llegan a intervalos regulares. Sin embargo, vamos a suponer que la solución está ocupada procesando la carga de trabajo solo el 25 % del tiempo durante un día laborable estándar de ocho horas. Esto da lugar a 6 horas (8 horas * el 75 %) de “tiempo de inactividad” cuando puede no haber ninguna transacción entrando en el sistema. Además, la solución no recibirá ningún dato durante las 16 horas no laborales de cada día.

Durante el período inactivo que asciende a 22 horas, la solución sigue intentando sacar de la cola trabajos porque no conoce explícitamente cuándo llegan nuevos datos. Durante este período de tiempo, cada subproceso individual para sacar de la cola realizará hasta 79.200 transacciones (22 horas * 60 minutos * 60 transacciones/minuto) en una cola de entrada, suponiendo que el intervalo de sondeo predeterminado es de 1 segundo.

Como se mencionó anteriormente, el modelo de precios en la plataforma de Azure se basa en “transacciones individuales de almacenamiento”. Una transacción de almacenamiento es una solicitud realizada por una aplicación de usuario para agregar, leer, actualizar o eliminar datos de almacenamiento. Al redactar estas notas del producto, las transacciones de almacenamiento se facturan con una tarifa de 0,01 $ por cada 10.000 transacciones (independientemente de las ofertas promocionales o los acuerdos de precios especiales).

ImportantImportante
Al calcular el número de transacciones de la cola, tenga presente que colocar un solo mensaje en una cola se contaría como una transacción, mientras que usar un mensaje suele ser un proceso de dos pasos que implica la recuperación seguida de una solicitud para quitar el mensaje de la cola. Por tanto, una operación correcta para quitar de la cola supondrá dos transacciones de almacenamiento. Tenga en cuenta que aunque una solicitud de eliminación de cola no hace que se recuperen datos, sigue contando como una transacción facturable.

Las transacciones de almacenamiento generadas por un solo subproceso de eliminación de cola en el escenario anterior sumarán aproximadamente 2,38 $(79.200 / 10.000 * 0,01 $ * 30 días) a una cuenta mensual. En comparación, 200 subprocesos para eliminar de la cola (o bien un subproceso de eliminación de cola en 200 instancias de rol de trabajo) incrementarán el costo en 457,20 $ mensuales. Ese es el costo en que se incurría cuando la solución no realizaba cálculos, solo comprobaba las colas para ver si había elementos de trabajo disponibles. El ejemplo anterior es abstracto ya que nadie implementaría su servicio de esta manera, lo que constituye la razón por la que es importante realizar la optimización descrita a continuación.

Para optimizar el rendimiento de las soluciones de mensajería de Azure basadas en cola, un método es utilizar el nivel de mensajería de publicación/suscripción que se proporciona con Service Bus de Azure, como se describe en esta sección.

Con este método, los desarrolladores tendrán que centrarse en crear una combinación de notificaciones basadas en inserción en tiempo real y en extracción, lo que permite que los agentes de escucha se suscriban a un evento de notificación (desencadenador) que se activa con determinadas condiciones para indicar que una nueva carga de trabajo se ha puesto en una cola. Este enfoque mejora el bucle tradicional de sondeo de la cola con un nivel de mensajería de publicación/suscripción para enviar notificaciones.

En un sistema distribuido complejo, este enfoque requeriría el uso de un “bus de mensajes” o de un “software intermedio orientado a mensajes” para asegurarse de que las notificaciones se pueden retransmitir de forma confiable a uno o varios suscriptores con acoplamiento flexible. Service Bus de Azure es una opción natural para satisfacer los requisitos de mensajería entre los servicios de aplicaciones distribuidas con acoplamiento flexible que se ejecutan en Azure y en local. También es una solución perfecta para una arquitectura de ”bus de mensajes” que permita intercambiar notificaciones entre los procesos involucrados en la comunicación basada en cola.

Los procesos implicados en un intercambio de mensajes basado en cola podría emplear el modelo siguiente:

Procedimientos-recomendados-Soluciones-de-mensajería-Azure3

En concreto, dado que se trata de interactuar entre los editores del servicio Cola y los suscriptores, los mismos principios que se aplican a la comunicación entre las instancias de rol de Azure cumplirían la mayoría de los requisitos del intercambio de mensajes de notificación basado en cola.

ImportantImportante
El uso de Service Bus de Azure está sujeto a un modelo de precios que tenga en cuenta el volumen de las operaciones de mensajería en una entidad de mensajería de Service Bus como una cola o un tema.

Por lo tanto, es importante realizar un análisis de los costos y los beneficios para evaluar las ventajas y los inconvenientes de introducir Service Bus en una arquitectura determinada. Junto con eso, merece la pena evaluar si la introducción del nivel de envío de notificaciones basado en Service Bus conduciría, de hecho, a una reducción del costo que pueda justificar las inversiones y otros esfuerzos de desarrollo adicionales.

Para obtener más información sobre el modelo de precios de Service Bus, vea las secciones relacionadas de las Preguntas más frecuentes de la plataforma de Azure.

Aunque el impacto en la latencia es bastante fácil de solucionar con un nivel de mensajería de publicación/suscripción, se obtendría una reducción en el costo mayor mediante el uso de una escala dinámica (elástica), como se describe en la sección siguiente.

El almacenamiento de Azure define los objetivos de escalabilidad a un nivel por cuenta general y a un nivel por partición. Una cola en Azure es su propia partición única y, por lo tanto, puede procesar hasta 2000 mensajes por segundo. Cuando el número de mensajes supera esta cuota, el servicio de almacenamiento responde con un mensaje HTTP 503 Servidor ocupado. Este mensaje indica que la plataforma está limitando la cola. Los diseñadores de aplicaciones deben llevar a cabo una planificación de capacidades para asegurar que un número apropiado de colas pueda sostener la velocidad de solicitudes de la aplicación. Si una cola única no es capaz de manejar la velocidad de solicitudes de una aplicación, diseñe una arquitectura de cola particionada con varias colas para asegurar la escalabilidad.

Una aplicación también podría aprovechar varias colas diferentes para distintos tipos de mensajes. Esto asegura la escalabilidad de la aplicación al permitir que varias colas coexistan sin sofocar a una cola única. Esto también permite el control discreto del procesamiento de colas según la sensibilidad y la prioridad de los mensajes que se almacenan en distintas colas. Las colas de alta prioridad podrían tener más trabajadores dedicados a ellas que las colas de baja prioridad.

La plataforma de Azure permite que los clientes amplíen o disminuyan el sistema de forma más rápida y fácil que antes. La capacidad de adaptarse a cargas de trabajo volátiles y a un tráfico variable es una de las propuestas de valor principales de la plataforma de la nube. Esto significa que la “escalabilidad” ya no es un término del vocabulario de las TI relacionado con algo caro, sino que ahora es una característica lista para usar que se puede habilitar mediante programación a petición en una solución de nube bien diseñada.

La escala dinámica es la capacidad técnica de una solución dada de adaptarse a las cargas de trabajo que fluctúan aumentando y disminuyendo la capacidad de trabajo y la eficacia de procesamiento en tiempo de ejecución. La plataforma de Azure permite por sí misma una escala dinámica a través del aprovisionamiento de una infraestructura informática distribuida en la que las horas de proceso se pueden comprar según las necesidades.

Es importante distinguir entre los dos tipos siguientes de escala dinámica en la plataforma de Azure:

  • La ampliación de instancias de rol hace referencia a la incorporación y a la eliminación de instancias de rol de trabajo o web adicionales para administrar la carga de trabajo puntual. Esto suele conllevar cambiar el recuento de instancias en la configuración del servicio. Al aumentar el contador de instancias, el tiempo de ejecución de Azure inicia nuevas instancias mientras que, al reducir el contador de instancias, se cerrarán las instancias actuales.

  • La escala de proceso (subproceso) hace referencia a mantener la suficiente capacidad en lo relativo a los subprocesos de procesamiento en una instancia de rol determinada ajustando el número de subprocesos arriba o abajo en función de la carga de trabajo actual.

La escala dinámica en una solución de mensajería basada en cola conllevaría una combinación de las recomendaciones generales siguientes:

  1. Supervisar los indicadores clave de rendimiento como son el uso de la CPU, la profundidad de la cola, los tiempos de respuesta y la latencia del procesamiento de mensajes.

  2. Aumentar o disminuir dinámicamente el número de instancias de rol para hacer frente a los picos de la carga de trabajo, ya sean previsibles o no.

  3. Expandir y recortar mediante programación el número de subprocesos de procesamiento para adaptarse a las condiciones de carga variable controladas por un rol de instancia determinado.

  4. Dividir y procesar las cargas de trabajo específicas del proceso simultáneamente mediante la Biblioteca en paralelo de tareas de .NET Framework 4.

  5. Mantener una capacidad viable en las soluciones con cargas de trabajo muy volátiles como anticipación a los picos repentinos a fin de poder controlarlos sin la sobrecarga de configurar instancias adicionales.

La API Administración de servicio permite que un servicio hospedado de Azure modifique el número de sus instancias de rol en ejecución cambiando la configuración de implementación en tiempo de ejecución.

noteNota
El número máximo de instancias de proceso pequeñas de Azure (o el número equivalente de instancias de cálculo de otro tamaño en cuanto al número de núcleos) en una suscripción típica se limita a 20, de forma predeterminada. Cualquier solicitud para aumentar esta cuota se debe pasar al equipo de Soporte técnico de Azure. Para obtener más información, vea las Preguntas más frecuentes de la plataforma de Azure.

Con la introducción de Escalado automático de Azure, la plataforma puede escalar de forma ascendente o descendente el recuento de instancias según la profundidad de mensajes en la cola. Este es el proceso natural para el escalado dinámico. La ventaja adicional es que la plataforma Azure supervisa y escala las tareas de la aplicación.

La escala dinámica del recuento de instancias de rol puede no ser siempre la opción más adecuada para administrar los picos de carga. Por ejemplo, una nueva instancia de rol puede tardar segundos en activarse y que no exista ninguna métrica del SLA con respecto a la duración de la activación. En su lugar, puede que una solución simplemente tenga que aumentar el número de subprocesos de trabajo para tratar el aumento de carga de trabajo volátil. Mientras se procesa la carga de trabajo, la solución supervisará las métricas de carga pertinentes y determinará si se debe reducir o aumentar dinámicamente el número de procesos de trabajo.

ImportantImportante
Actualmente, el destino de escalabilidad de una sola cola de Azure se “limita” a 2000 transacciones/s. Si una aplicación intenta superar este destino, por ejemplo, a través de operaciones de cola desde la instancia de rol múltiple que ejecuta cientos de subprocesos de eliminación de cola, puede dar lugar a la respuesta "Servidor ocupado" HTTP 503 del servicio de almacenamiento. Cuando esto ocurre, la aplicación debe implementar un mecanismo de reintento usando un algoritmo de retraso de retroceso exponencial. Sin embargo, si los errores HTTP 503 aparecen con regularidad, se recomienda utilizar varias colas e implementar una estrategia basada en particiones para realizar la ampliación a través de varias colas.

En la mayoría de los casos, la escala automática de los procesos de trabajo es responsabilidad de una instancia de rol individual. Por el contrario, la escala de instancias de rol suele implicar a un elemento central de la arquitectura de la solución que es responsable de supervisar las métricas de rendimiento y de realizar las acciones adecuadas para la ampliación. El diagrama siguiente describe un componente de servicio denominado agente de escala dinámica que recopila y analiza la métrica de carga para determinar si necesita aprovisionar nuevas instancias o dar de baja las inactivas.

Procedimientos-recomendados-Soluciones-de-mensajería-Azure4

Hay que destacar que el servicio del agente de ampliación se puede implementar como un rol de trabajo que se ejecute en Azure o como un servicio local. Con independencia de la topología de implementación, el servicio podrá obtener acceso a las colas de Azure.

noteNota
Como alternativa al escalado dinámico manual, considere la posibilidad de usar la característica escalado automático integrado con Azure.

Ahora que hemos tratado el impacto de la latencia, los costos de las transacciones de almacenamiento y los requisitos de la escala dinámica, es un buen momento de consolidar nuestras recomendaciones en una implementación técnica.

Como ejemplo concreto, generalizaremos un escenario real del cliente de la forma siguiente.

Un proveedor de soluciones SaaS lanza un nuevo sistema de facturación implementado como una aplicación de Azure que atiende las necesidades empresariales del procesamiento de transacciones según convenga. La premisa clave de la solución se centra en la capacidad de descargar la enorme carga de trabajo de proceso a la nube y aprovechar la elasticidad de la infraestructura de Azure para realizar dicho trabajo.

El elemento local de la arquitectura de extremo a extremo consolida los grandes volúmenes de transacciones y los envía a un servicio hospedado de Azure periódicamente a lo largo del día. Los volúmenes varían de miles a centenares de miles de transacciones por cada envío, llegando a alcanzar millones de transacciones al día. Además, suponga que la solución debe satisfacer el requisito marcado por el SLA de tener una latencia máxima garantizada de procesamiento.

La arquitectura de la solución se basó en el modelo de diseño con reducción de asignaciones distribuido y consta de una capa de nube basada en roles de trabajo de varias instancias que usa el almacenamiento de cola de Azure para el envío de trabajos. Los lotes de transacciones son recibidos por la instancia del rol de trabajo Iniciador de proceso, se descomponen (por lotes) en elementos de trabajo menores y se ponen en la cola en una colección de colas de Azure con el fin de distribuir la carga.

El procesamiento de la carga de trabajo es administrado por varias instancias del rol de trabajo de procesamiento que capturan los elementos de trabajo de las colas y los pasan a través de procedimientos de cálculo. Las instancias de procesamiento emplean agentes de escucha de cola multiproceso para implementar el procesamiento de datos paralelo y lograr un rendimiento óptimo.

Los elementos de trabajo procesados se enrutan a una cola dedicada de la que los quita la instancia del rol de trabajo Controlador de proceso, se agregan a un almacén de datos y se mantienen allí para realizar la minería de datos, los informes y los análisis.

La arquitectura de la solución se puede describir como sigue:

AzureGuidance_MaxScale

El diagrama anterior describe una arquitectura típica para escalar cargas de trabajo de proceso grandes o complejas. El modelo de intercambio de mensajes basado en cola que esta arquitectura adopta también es muy típico de muchas otras aplicaciones y servicios de Azure que necesitan comunicarse entre sí a través de colas. Esto permite adoptar un enfoque canónico para examinar componentes fundamentales concretos implicados en un intercambio de mensajes basado en cola.

Para maximizar la rentabilidad y la eficacia de las soluciones de mensajería basadas en cola que se ejecutan en la plataforma de Azure, los arquitectos de soluciones y los desarrolladores deben tener en cuenta las siguientes recomendaciones.

Como arquitecto de la solución, debe:

  • Proporcionar una arquitectura de mensajería basada en cola que use el servicio de almacenamiento de cola de Azure para la comunicación asincrónica de alta escala entre los niveles y los servicios en las soluciones basadas en la nube o híbridas.

  • Recomendar que la arquitectura de puesta en cola con particiones no aumente más allá de 2000 mensajes/s.

  • Conocer los aspectos básicos del modelo de precios de Azure y optimizar la solución para reducir los costos de transacción con una serie de prácticas recomendadas y de modelos de diseño.

  • Tenga en cuenta los requisitos de escala dinámica proporcionando una arquitectura que se pueda adaptar a las cargas de trabajo volátiles y que fluctúan.

  • Emplear los métodos y las técnicas de escala automática correctos para expandir y reducir de forma elástica la capacidad de proceso para optimizar aún más el gasto de la explotación.

  • Evaluar el escalado automático de Azure para ver si se adapta a la necesidad de escalado dinámico de la aplicación.

  • Evaluar la proporción entre costos y beneficios que supone reducir la latencia a través de la dependencia de Service Bus de Azure para el envío de notificaciones basadas en inserción en tiempo real.

Como desarrollador, debe:

  • Diseñar una solución de mensajería que emplee el procesamiento por lotes al almacenar y recuperar los datos de las colas de Azure.

  • Evaluar el escalado automático de Azure para ver si se adapta a la necesidad de escalado dinámico de la aplicación.

  • Implementar un servicio eficaz de agente de escucha de la cola que garantice que, como máximo, un subproceso de eliminación de cola sondeará las colas cuando estén vacías.

  • Reducir dinámicamente el número de instancias de rol de trabajo cuando las colas permanezcan vacías durante un período prolongado.

  • Implementar un algoritmo de retroceso exponencial aleatorio específico de la aplicación para reducir el efecto del sondeo de las colas inactivas en los costos de las transacciones de almacenamiento.

  • Adoptar las técnicas correctas que impidan que se superen los destinos de escalabilidad de una sola cola al implementar publicadores y consumidores de colas de varias instancias y varios subprocesos.

  • Emplear una directiva de reintento sólida capaz de controlar diversas condiciones transitorias al publicar y usar los datos de las colas de Azure.

  • Usar la capacidad unidireccional de generación de eventos que Service Bus de Azure proporciona para admitir las notificaciones basadas en inserción a fin de reducir la latencia y mejorar el rendimiento de la solución de mensajería basada en cola.

  • Explorar las nuevas capacidades de .NET Framework 4 como TPL, PLINQ y el modelo Observer para maximizar el grado de paralelismo, mejorar la simultaneidad y simplificar el diseño de los servicios multiproceso.

El código de ejemplo adjunto puede descargarse de la galería de código de MSDN. El código de ejemplo también incluye todos los componentes de infraestructura requeridos, como la capa de abstracción con elementos genéricos para el servicio Cola de Azure, que no se proporcionaron en los fragmentos de código anteriores. Tenga en cuenta que la licencia pública de Microsoft rige todos los archivos de código fuente, según se explica en los avisos legales correspondientes.

Mostrar:
© 2015 Microsoft