Корпоративная платформа на Python, консультации по дизайну

Question

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

Система в основном представляет собой службу, которая собирает данные из различных внешних источников, причем каждый внешний источник имеет свое отдельное приложение. Эти приложения будут опрашивать центральную базу данных и получать любые запросы, которые были отправлены для выполнения на внешний источник.

Будет основной веб-сайт и REST / SOAP API, который также должен иметь доступ к центральной службе данных.

Первоначально я думал о том, чтобы использовать Django для веб-сайта, веб-службы и слоя доступа к данным (используя встроенную ORM), а затем приложения внешнего источника могут использовать веб-службы для получения необходимой информации. обработать запрос и сохранить результаты. Использование этого метода позволило бы мне иметь несколько экземпляров приложений-служб, работающих на одной или разных машинах, чтобы сбалансировать нагрузку. Есть ли более изящные средства для достижения этой цели? я слышал о системах обмена сообщениями, таких как MQ, что-то подобное будет полезно в этом сценарии?

Моя другая мысль заключалась в том, чтобы использовать совершенно отдельный сервис данных, не основанный на Django, и использовать какие-то удаленные или удаленные объекты (в том виде, в каком они существуют в Python) для взаимодействия с моделью данных. Недостатком здесь будет веб-сайт, который станет намного медленнее, если ему придется проталкивать все свои запросы данных через второй уровень.

Мне бы очень хотелось услышать, что другие разработчики придумали для достижения этих целей наиболее гибким способом.

Answer 1

Рассмотрите возможность использования сельдерея. Это позволяет вашим веб-приложениям делать как можно меньше, а затем запускать другие задачи, которые будут выполнены позже. Под ним используется AMQP (RabbitMQ), но он написан на Python и отлично работает с Django.

http://celeryproject.org/

(Если вы хотите узнать больше о AMQP, я написал несколько слайдов: http://johntellsall.blogspot.com/2009/11/message-queuing-slides-and-source-code.html )

Answer 2

Я думаю, что ваша архитектура звучит нормально. Один комментарий заключается в том, что SOAP обычно считается тяжелым в сообществе Python. Вы рассматривали JSON или что-то еще вместо этого? К настоящему времени существуют библиотеки JSON для большинства языков.

Еще одна возможность для удаленного запуска кода - pyro (удаленные объекты Python), который отлично работает в Windows и является кроссплатформенным.

В Python есть несколько сервисов написания ошибок (например, если ваш сервис всегда умирает через некоторое время, убедитесь, что он не пишет в stdout и не заполняет его буфер), но если вы рассматриваете этот маршрут, то я предполагаю, на вершине этого. :)