Привет, коллеги.
Занимаюсь проектированием достаточно специфического проекта, хотел бы послушать мнение других людей насчет того, что напроектировал.
Суть в том, что есть 2 сервера: server1 - вебморда, server2 - некий сервер с файлами. Веб пишется на Django. Пользователь может выбрать определенные опции в web-интерфейсе, после чего server1 должен отдать команду server2 заархивировать определенную директорию и дать возможность пользователю скачать этот архив. server2 недоступен извне, только по локалке, и у пользователя должна быть возможность скачать только тот архив, который он "создал". В связи с этим, у меня появилась такая мысль:
На server2 крутится TCP сервер на питоне, который принимает команды от server1 и исходя из параметров в отдельном потоке создает архив, после чего отстукивает по Web API на server1, сообщая о готовности архива. Как только пользователь захочет скачать готовый архив, server1 отдает на server2 через тот же TCP сервер команду "отдай мне архив", скачивает его (архивы небольшие, меньше 1 мб, поскольку локалка - должны передаться мгновенно) и отдает клиенту в том же http запросе.
Собственно, вопрос - все ли тут хорошо, или есть более эффективные способы реализовать такое взаимодействие?
Архитектура плохая. Через какое то время ваш tcp сервер на питоне забьется запросами и перестанет отдавать ответы (к примеру запросов будет очень много, ваша программа на питоне создаст много отдельных потоков с операциями I/O). Смотрите в сторону очередей, RabbitMQ, ZeroMQ возможно и Celery подойдет. Да и простую очередь можно на Redis сделать. Суть в том чтобы server2 принимал запросы, записывал их в очередь. С другой стороны, пусть даже та же ваша программа на питоне вытаскивает задание из очереди, делает обработку и отдает ответ.
Простой
Средний
