¿Cómo construir un servicio web computacionalmente intensivo?

Question

Necesito construir un servicio web que sea muy computacionalmente intensivo, y estoy tratando de orientarme sobre la mejor manera de proceder.

Espero que los usuarios se conecten a mi servicio, momento en el que se realizan algunos cálculos durante cierto tiempo, generalmente menos de 60 segundos. El usuario sabe que necesita esperar, por lo tanto, esto no es realmente un problema. Mi pregunta es, ¿cuál es la mejor manera de estructurar un servicio como este y dejarme con la menor cantidad de dolor de cabeza? ¿Puedo usar Node.js, web.py, CherryPy, etc.? ¿Necesito un equilibrador de carga sentado frente a estas piezas si se usa? No espero grandes cantidades de usuarios, quizás cientos o miles. Necesitaré un número de máquinas para alojar esta cantidad de usuarios, por supuesto, pero este es un territorio inexplorado para mí, y si alguien me puede dar algunos consejos o cosas para leer, sería genial.

Gracias.

Answer 1

Creo que puedes compilarlo como quieras, siempre que puedas convertirlo en un servicio asincrónico para que los usuarios no tengan que esperar.

A menos que, por supuesto, a los usuarios no les importe esperar en este contexto.

Answer 2

me gustaría recomendar el uso nginx, ya que puede manejar reescribir/balancing/SSL, etc, con un mínimo de esfuerzo

Answer 3

¿Puedo utilizar Node.js, web.py, CherryPy, etc.?

Sí. Elegir uno. Django es bueno, también.

¿Necesito un equilibrador de carga sentado delante de estas piezas si se usa?

Casi nunca.

Voy a necesitar un número de máquinas para acoger este número de usuarios,

dudoso.

Recuerde que cada transacción web tiene varias partes distintas (y casi no relacionadas).

1. Un front-end (Apache HTTPD o NGINX o similar) acepta la solicitud web inicial. Puede manejar archivos estáticos en servicio (.CSS, .JS, Images, etc.) para que su aplicación web principal no esté despejada por esto.

2. Un middleware razonablemente eficiente como mod_wsgi puede administrar docenas (o cientos) de procesos de back-end.

3. Si elige un componente de procesamiento de back-end inteligente como celery, debe poder distribuir el "trabajo real" a la cantidad mínima de procesadores para realizar el trabajo.

4. Los resultados se introducen en Apache HTTPD (o NGINX) a través de mod_wsgi en el navegador del usuario.

Ahora los procesos de back-end (gestionados por el apio) están separados del servidor web esencial.Se logra una gran cantidad de paralelismo con Apache HTTPD y mod_wsgi y apio, lo que le permite utilizar cada desperdicio de recursos del procesador.

Además, es posible que pueda descomponer su proceso "intensivo en cómputo" en procesos paralelos: una tubería Unix es notablemente eficiente y hace uso de todos los recursos disponibles. Tienes que descomponer tu problema en step1 | step2 | step3 y hacer que el apio administre esas tuberías.

Es posible que este tipo de descomposición genere una carga de trabajo mucho mayor de lo que originalmente se imaginaba.

Muchos frameworks web de Python mantendrán la información de la sesión del usuario en una única base de datos común. Esto significa que todos sus backends pueden, sin ningún trabajo real, mover la sesión del usuario del servidor web al servidor web, haciendo que el "equilibrio de carga" sea perfecto y automático. Solo tiene muchos frontales HTTPD/NGINX que generan Django (o web.py o lo que sea) que comparten una base de datos común. Funciona notablemente bien.

Answer 4

Si desea que sus servicios web sean asíncronos, puede probar Twisted. Es un marco orientado a tareas asincrónicas e implementa tantos protocolos de red. Es muy fácil ofrecer estos servicios a través de xml-rpc (simplemente ponga xmlrpc_ como el prefijo de su método). Por otro lado, se adapta muy bien a cientos y miles de usuarios.

El apio también es una buena opción para realizar las tareas más intensivas desde el punto de vista informático asíncronas. Se integra muy bien con Django.