2010-03-11 19 views
5

Estoy en las primeras fases de diseño de una aplicación basada en Azure. Una de las cosas que me atrae de Azure es la escalabilidad, dada la variabilidad de la demanda que probablemente esperaré. Como tal, estoy tratando de mantener las cosas juntas para que pueda agregar instancias cuando sea necesario.Mejores prácticas para (sobre) el uso de colas Azure

Las recomendaciones que he visto para diseñar una aplicación para Azure incluyen mantener la lógica de la función web al mínimo y realizar el procesamiento en roles de trabajo, usar colas para comunicarse y algún tipo de tienda back-end como SQL Azure o Azure Mesas. Esto me parece una buena idea, ya que puedo ampliar cualquiera o ambas partes de la aplicación sin ningún problema. Sin embargo, tengo curiosidad por saber si hay algunas prácticas recomendadas (o si alguien tiene alguna experiencia) para saber cuándo es mejor simplemente hacer que la función web se comunique directamente con el almacén de datos y no enviar datos por la cola.

Estoy pensando en el caso en que tengo un simple inserto para hacer desde la función web, mientras que podría configurarlo como un mensaje, enviarlo a la cola, y tener un rol de trabajador recogerlo y hacer el inserto, parece un montón de doble manejo. Sin embargo, también aprecio que este sea el caso de que esto sea mejor a largo plazo, en caso de que la función web se vea abrumada o que se requiera una lógica más compleja para la inserción.

Me doy cuenta de que este podría ser un caso en el que la respuesta es "depende completamente de la situación, revise sus parámetros de perfusión", pero si alguien tiene algún pensamiento, lo apreciaría mucho.

Gracias

John

Respuesta

3

que diría algo así como una inserción no requiere un rol de trabajo. Tendría un inserto en la cola de todos modos, por lo que no estaría guardando nada en la función web. Lo mejor sería aislar sus insertos (y todo el acceso a los datos) en una clase (o clases) separada dentro de su rol web. Esto le permitiría desacoplar el resto del código en su función web del sistema de almacenamiento de datos específico que está utilizando. Eso hace que cambiar la tienda de datos sea mucho más fácil. Si sus insertos terminan necesitando más procesamiento, puede agregar la función de cola y trabajador cuando sea necesario, pero aún diría que desea insertar directamente en el almacenamiento de tabla y luego relegar el cálculo u otra lógica comercial a una rol del trabajador Luego, esa función de trabajador puede procesar los mensajes de la cola o simplemente consultar el almacenamiento de la tabla para los registros nuevos (sin procesar).

La forma en que veo que usar la cola para comunicarme con un rol de trabajador se vuelve más afectivo es cuando hay cálculos u otros procesos que tendrían que hacerse con los datos. El que he estado utilizando más es en realidad uno de los ejemplos en Azure SDK que muestra cómo crear imágenes en miniatura. Mi función web inserta la imagen cargada en el almacenamiento de blobs de Azure y la descripción relacionada y otros campos en el almacenamiento de tablas de Azure. También coloca un mensaje en la cola que le permite al rol del trabajador saber que hay una nueva imagen que necesita miniaturas generadas. De hecho, genero algunos tamaños diferentes de cada imagen para usar en diferentes partes del sitio. El rol de trabajador solo genera esas miniaturas y no necesita enviar ningún tipo de notificación a la función web. Cualquier lugar que use las imágenes tiene lógica para usar la carga original u otros marcadores de posición cuando las miniaturas aún no están disponibles.

Este mismo proceso podría simplemente utilizar una consulta en el almacenamiento de blob para encontrar qué imágenes aún requieren procesamiento si desea omitir la cola por completo. No he tomado una decisión sobre si prefiero usar la cola o simplemente sondear los datos para buscar registros que necesiten el procesamiento de la función del trabajador. Supongo que la cola es más eficiente, pero también agrega una capa adicional de complejidad y un punto de falla potencial adicional.

Editar en respuesta al comentario: cuando publiqué esta respuesta, le dije que solo use la imagen de resolución completa en la interfaz de usuario si la miniatura no está disponible. Ahora estoy trabajando en un sitio que solo usa una imagen en miniatura predeterminada que dice "procesar" hasta que la miniatura generada esté disponible. La elección es suya y realmente depende de los requisitos de la IU de su aplicación.

Una cosa que podría hacer es usar SignalR o un poco de AJAX para notificar al navegador del usuario cuando hay una nueva miniatura disponible sin esperar una nueva carga de página.

Ver una miniatura de marcador de posición mientras se procesa la imagen en un hilo de trabajo es una experiencia de usuario mucho mejor que esperar que la página se cargue mientras se genera la miniatura.

+0

Al hacer esto, ¿qué mostrar al usuario? Muchos usuarios esperarán ver la miniatura en la IU una vez que se cargue la foto, así que mientras puedo ver el valor de separar la producción de miniaturas en una función de trabajador, ¿no te queda un problema de UX sobre qué mostrar hasta que el procesamiento sea completo, y cómo saber cuándo es? – dumbledad

5

Aquí es mi metáfora, haz lo que quieras con él

Imagínese que usted está entrando en un club nocturno, que raya en una zona cutre, pero está bien una vez que estás dentro.

La administración emplea unos grandes gorilas carnosos en la puerta para ordenar la riff raff. Si eres un idiota, no vas a entrar. Extiende la metáfora tanto como quieras aquí.

Si estás bien, entonces te dejan entrar, y te unes, sí, The Queue a pagar en la taquilla para ingresar al club real.

Dependiendo si el fútbol está encendido o algo así, es posible que desee un poco más de gorilas en la puerta, pero esto puede ser independiente del personal de la taquilla. Noche ocupada, puede abrir otra ventana para obtener el dinero más rápido, pero lo que probablemente no va a hacer es que los gorilas manejen efectivo. Ellos tienen otras cosas que hacer con sus manos.

Así:

  • gorilas - papeles web. Controle el tráfico entrante , rechace las solicitudes inválidas y agregue las solicitudes válidas a:
  • The Queue - the Queue!
  • Taquilla - papeles de los trabajadores, que realizan una función diferente a la WebRole

Por lo tanto, no hay razón por la cual sus papeles web no pueden hacer el papel de las taquillas, pero es mejor no en el largo plazo

que es mi metáfora

Toby

1

El uso de colas distribuidas (de Azure o Amazon del o de lo contrario) es sorprendentemente sutil. He publicado una entrada de blog covering frequent subtleties of Azure Queues. En pocas palabras: sugiero que se abstraiga cuidadosamente la lógica de su infraestructura (que respalda la cola) de su lógica comercial (contenido y procesamiento de la cola).

Cuestiones relacionadas