Как построить вычислительно интенсивный веб-сервис?

Мне нужно построить webservice, который очень интенсивно вычисляется, и я пытаюсь понять, как лучше всего действовать.

Я ожидаю, что пользователи подключатся к моей службе, и в этот момент некоторые вычисления выполняются в течение некоторого времени, обычно менее 60 секунд. Пользователь знает, что им нужно подождать, так что это не проблема. Мой вопрос в том, что лучший способ структурировать такую ​​услугу и оставить меня с наименьшим количеством головной боли? Могу ли я использовать Node.js, web.py, CherryPy и т. Д.? Нужен ли мне балансировщик нагрузки перед этими кусками, если он используется? Я не ожидаю огромного количества пользователей, возможно, сотен или тысяч. Конечно, мне понадобится несколько машин для размещения этого количества пользователей, но для меня это не обозначенная территория, и если кто-то может дать мне несколько указателей или что-то почитать, это будет здорово.

Благодарю.

Могу ли я использовать Node.js, web.py, CherryPy и т. Д.?

Да. Выбери один. Джанго тоже приятный.

Нужен ли мне балансировщик нагрузки перед этими кусками, если он используется?

Больше никогда.

Мне понадобится несколько машин для размещения этого количества пользователей,

Сомнительно.

Помните, что каждая веб-транзакция имеет несколько отдельных (и почти несвязанных) частей.

  1. Передний интерфейс (Apache HTTPD или NGINX или аналогичный) принимает исходный веб-запрос. Он может обрабатывать сервисные статические файлы (.CSS, .JS, изображения и т. Д.), Поэтому ваше основное веб-приложение является незанятым.

  2. Достаточно эффективное промежуточное программное обеспечение, такое как mod_wsgi, может управлять десятками (или сотнями) бэкэнд-процессов.

  3. Если вы выберете умный компонент обработки бэкэнд, такой как сельдерей , вы должны иметь возможность распространять «реальную работу» на минимальное количество процессоров, чтобы выполнить работу.

  4. Результаты возвращаются в Apache HTTPD (или NGINX) через mod_wsgi в браузер пользователя.

Теперь бэкэнд-процессы (управляемые сельдереем) оторваны от основного веб-сервера. Вы достигаете большого параллелизма с Apache HTTPD и mod_wsgi и сельдереем, что позволяет использовать каждый лот ресурсов процессора.

Кроме того, вы можете разложить свой «вычислительно-интенсивный» процесс на параллельные процессы. Конвейер Unix замечательно эффективен и использует все доступные ресурсы. Вы должны разложить свою проблему на step1 | step2 | step3 step1 | step2 | step3 step1 | step2 | step3 и заставить сельдерей управлять этими трубопроводами.

Вы можете обнаружить, что такой разложение приводит к тому, что он обслуживает гораздо большую рабочую нагрузку, чем вы могли себе представить.

Многие веб-фреймы Python будут хранить информацию о сеансе пользователя в единой общей базе данных. Это означает, что все ваши серверы могут – без какой-либо реальной работы – перемещать сеанс пользователя с веб-сервера на веб-сервер, делая «балансировку нагрузки» бесшовной и автоматической. Просто у вас есть много интерфейсов HTTPD / NGINX, которые порождают Django (или web.py или что-то еще), которые имеют общую базу данных. Он работает замечательно хорошо.

Я думаю, вы можете создать его, как хотите, до тех пор, пока вы можете сделать его асинхронным сервисом, чтобы пользователям не приходилось ждать.

Если, конечно, пользователи не возражают ждать в этом контексте.

Я бы рекомендовал использовать nginx, поскольку он может обрабатывать rewrite / balancing / ssl и т. Д. С минимумом суеты

Если вы хотите, чтобы ваши веб-сервисы асинхронны, вы можете попробовать Twisted . Это структура, ориентированная на асинхронные задачи и реализующая так много сетевых протоколов. Так просто предложить эти услуги через xml-rpc (просто поставьте xmlrpc_ в качестве префикса вашего метода). С другой стороны, он очень хорошо масштабируется с сотнями и тысячами пользователей.

Сельдерей также является хорошим вариантом для асинхронности самых сложных задач. Он отлично сочетается с Django.