2011-06-07 9 views
6

Estoy portando una gran aplicación a Windows Azure. Tendrá una interfaz de servicio web y un back-end de procesamiento. Hasta ahora, pensaba que usaría funciones web para atender las solicitudes de los clientes y las funciones de los trabajadores para el procesamiento de back-end.¿Es una buena idea reutilizar una función web de Azure para el procesamiento de back-end?

Gestionar dos tipos de funciones parece problemático: tendré que decidir cómo escalar dos tipos de funciones y también necesitaré varias (al menos dos) instancias de cada una para garantizar una tolerancia a fallos razonable y esto aumentará ligeramente Costos operativos. Además, en mi aplicación, las solicitudes de los clientes son bastante livianas y el procesamiento de fondo es pesado, por lo que espero que el procesamiento de back-end consuma mucha más potencia de procesamiento que el servicio a las solicitudes de los clientes.

Es por eso que estoy pensando en usar roles web para todo: solo genere hilos y realice tanto solicitudes de servicio como procesamiento de backend en cada instancia. Esto complicará el rol, pero supongo que simplificará la gestión. Tendré más instancias de un rol uniforme y una mejor tolerancia a las fallas.

¿Es una buena idea reutilizar las funciones web para el procesamiento de back-end? ¿Qué inconvenientes debo esperar?

Respuesta

4

Parece que ya tiene una idea bastante buena de lo que pensar cuando se utilizan varios papeles:

  • Costo por 2 casos para cumplir con SLA (aunque algunas tareas de fondo realmente no necesitan SLA si el fin usuario no ve el impacto)
  • unidades de escala separados

sin embargo: Si ejecuta todo en un papel, entonces todo escalas juntos. Si, por ejemplo, tiene un sitio web administrativo en el puerto 8000, es posible que tenga dificultades para acceder a él si su base de usuarios golpea el sitio principal en el puerto 80 con tráfico.

Escribí sobre la combinación de las funciones web y de los trabajadores, here, que detalla un poco más de lo que estamos discutiendo aquí. Además, a partir de algún momento de marzo, se eliminó la restricción de 5 puntos finales por función; consulte la publicación de mi blog here para ver qué tan lejos puede avanzar ahora en los puntos finales. Tener este modelo de punto final menos restrictivo realmente abre nuevas posibilidades para implementaciones de rol único.

2

Según tengo entendido, usted pregunta si tiene sentido consolidar las capas de servicio para que solo tenga que ocuparse de una sola capa. En un nivel alto, creo que tiene sentido. Cuanto más simple, mejor, siempre y cuando no sea tan simple que no puedas cumplir tus objetivos principales.

Si su objetivo principal es el rendimiento, y las llamadas a sus servicios están en línea (lo que significa que la persona que llama está esperando una respuesta), la consolidación de las capas puede ayudarlo a lograr un mayor rendimiento porque no tendrá que lidiar con la sobrecarga de latencia de red adicional de capas físicas adicionales. Puede usar la Biblioteca de tareas paralelas (TPL) para implementar su lógica de subprocesamiento.

Si su objetivo principal es la escalabilidad, y las llamadas a sus servicios están fuera de banda (lo que significa que la persona que llama implementa un patrón de "olvidar y olvidar"), puede ser más útil usar colas de procesamiento y roles de trabajador. Uno de los principios de la computación en la nube es la combinación de los servicios. Si bien tiene más trabajo de mantenimiento, también tiene más flexibilidad para hacer crecer sus capas independientemente. Sus roles de trabajador también podrían usar el TPL mencionado anteriormente para que pueda implementar sus roles de trabajador en máquinas virtuales más grandes (por ejemplo, con 4CPU u 8), lo que mantendría el número de instancias implementadas al mínimo.

Mis 2 centavos.:)

Cuestiones relacionadas