azure - resource - Ejecutar múltiples WorkerRoles por instancia
portal azure free (4)
¿Por qué un "rol múltiple" sería un desastre? Podría escribir cada implementación de rol de trabajador como un componente débilmente acoplado y luego componer un rol de trabajador a partir de todos los componentes apropiados.
Cuando más tarde necesite separar algunas de las responsabilidades a un rol de trabajador separado, puede componer un nuevo rol de trabajador con solo este componente , al mismo tiempo que lo elimina del rol de trabajador anterior .
Si quisieras, podrías emplear un enlace tardío para que esto pueda hacerse sin recompilación, pero a menudo no creo que valga la pena el esfuerzo.
Tengo varios WorkerRole que solo hacen trabajo por un corto tiempo, y sería una pérdida de dinero ponerlos en una sola instancia cada uno. Podríamos fusionarlos en uno solo, pero sería un desastre y en el futuro lejano se supone que trabajarán de forma independiente cuando aumente la carga.
¿Hay una manera de crear un rol de WorkerRole "multi rol" de la misma manera que se puede crear un WebRole web "multi sitio"?
En caso negativo, creo que puedo crear un "rol de trabajador maestro", que puede cargar los ensamblados desde una carpeta dada, buscar clases derivadas de RoleEntryPoint con reflejo, crear instancias e invocar .Run() o .OnStart() método. Esta "función de trabajador maestro" también volverá a generar excepciones inesperadas y llamará a .OnStop() en todos los sub RoleEntryPoint s cuando se .OnStop() en el maestro. ¿Funcionaría? ¿Qué debo tener en cuenta?
Como lo mencionaron otros, esta es una técnica muy común para maximizar la utilización de sus instancias. Puede haber ejemplos y "marcos" que abstraigan la infraestructura del trabajador y el trabajo real que desea realizar, incluido uno en este (nuestro) ejemplo: http://msdn.microsoft.com/en-us/library/ff966483.aspx (desplácese hacia abajo hasta "dentro de la implementación")
Las formas más comunes de desencadenar el trabajo son:
- Trabajadores programados (como trabajos "cron")
- Trabajadores basados en mensajes (trabajo activado por la presencia de un mensaje).
El ejemplo de código mencionado anteriormente implementa abstracciones adicionales para el # 2 y es fácilmente extensible para el # 1.
Tenga en cuenta, sin embargo, que todas las interacciones con las colas se basan en encuestas. El trabajador no se despertará con un nuevo mensaje en la cola. Necesitas consultar activamente la cola para nuevos mensajes. Consultar con demasiada frecuencia hará feliz a Microsoft, pero probablemente no a usted :-). Cada consulta cuenta como una transacción que se factura (10K de esos = $ 0.01). Una buena práctica es encuestar la cola en busca de mensajes con algún tipo de retroceso retrasado. Además, obtener mensajes en lotes.
Finalmente, llevando esto a un extremo, también puede combinar roles web y roles de trabajador en una sola instancia. Vea aquí un ejemplo: http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure
Los múltiples roles de los trabajadores proporcionan una implementación muy limpia. Sin embargo, la huella de costos para las instancias de roles inactivos va a ser mucho mayor que un solo rol de trabajador.
La combinación de roles es un patrón común que he visto, trabajar con ISV en sus implementaciones de Windows Azure. Puede tener un hilo de fondo que se despierta de vez en cuando y ejecuta un proceso. Otra técnica de implementación común es usar una Cola de Azure para enviar un mensaje que represente un proceso para ejecutar. Puede tener varias colas si lo desea, o una sola cola de comandos. En cualquier caso, tendría una escucha de cola ejecutándose en un subproceso en segundo plano, que se ejecutaría en cada instancia. El primero en recibir el mensaje lo procesa. Podría ir más lejos y tener un proceso cronometrado para poner esos mensajes en la cola (tal vez cada 24 horas, o cada hora).
Aparte de los límites de la CPU y la memoria, recuerde que una sola función solo puede tener un máximo de 5 puntos finales (menos si está utilizando Escritorio remoto).
EDITAR: A partir de septiembre de 2011, la configuración de roles se ha vuelto mucho más flexible, ahora que tiene 25 puntos finales de entrada (accesibles desde el mundo exterior) y 25 puntos finales internos (utilizados para la comunicación entre roles) en toda la implementación. El artículo de MSDN está here
Recientemente hice un blog sobre la sobrecarga de un rol web , que está algo relacionado.
Si bien no hay un problema real con las soluciones que se han señalado para encontrar formas de realizar múltiples componentes de trabajador dentro de un solo rol de trabajador, solo quiero que tenga en cuenta que el primer punto de tener distintos roles de trabajador definidos en primer lugar es el aislamiento. Ante las faltas. Si solo metes todo en una única instancia de rol de trabajador, solo uno de los componentes de trabajador que se comportan mal tiene la capacidad de eliminar todos los demás componentes de trabajador en ese rol. Ahora, de repente, está escribiendo una gran cantidad de infraestructura para proporcionar aislamiento y tolerancia a fallas en todos los componentes, que es prácticamente lo que Azure le ofrece.
Una vez más, no estoy diciendo que sea un absoluto hacer una cosa de manera estricta. Hay un lugar donde varios componentes bajo un solo rol de trabajador tienen sentido (especialmente en lo esencial). Simplemente diga que debe tener en cuenta por qué está diseñado de esta manera en primer lugar y debe tenerlo en cuenta al planificar su arquitectura.