Pull to refresh

Всё самое модное

Reading time 3 min
Views 5.6K
Начитавшись в интернете про новые, простые, быстрые и масштабируемые технологии, захотелось их всех попробовать. Вдруг они окажутся лучше уже привычной мне связки postgresql + django + json-rpc.

Идея проекта


Так как никакой идеи не было, но был свободный домен uglyrater.org — пришлось делать рейтинг.
Суть проста: есть список пользователей, которым можно расставить + и -. Новые пользователи в рейтинг добавляются по адресу страницы ВКонтакте.


Осторожно! В статье много субъективных оценок, основанных на личном опыте!

Реализация





Архитектуру пришлось намеренно усложнить, иначе всё интересное не получилось бы попробовать. Плюс операция получения данных пользователя по vk api довольно таки долгая, и идея распаралелить её не такая уж и плохая. Для этого понадобится MQ, выбор пал на RabbitMQ. Вы, возможно, скажете AMQP «отстой», ØMQ «наше всё», но с zeromq я уже наработался, и он в данном контексте мне не интересен.
RabbitMQ использовался через pika. Для инициализации и отправки/получения сообщений потребовалось минимум кода, его можно посмотреть в в «воркере» и его тестках. После написания появилось небольшое сравнение с уже используемыми ZerocIce и ØMQ для удовлетворения данной или похожей задачи:
RabbitMQ ØMQ ZerocIce
Плюсы небольшое количество кода;
простота работы;
скорость;
пересылка нативных объектов;
не требует своего демона;
возможность работы с удалённым функциями и объектами;
отсутствие как такового сокета;
сигналы/слоты;
Минусы требуется запуск демона; требуется написание роутера;
много кода;
требуется написания slice;
требуется запуск демона(icebox);
сложность;

И так получилось, что для текущей задачи RabbitMQ и ØMQ подходят одинаково хорошо, а ZerocIce тут как пушкой по воробьям.

Теперь полученные и обработанные данные надо где-то хранить. Сейчас модно nosql, поэтому была выбрана mongodb. Для данной задачи никакой разницы относительно postgresql с orm нет, всё шустрое и удобное.

Пришла очередь web сервера. Сейчас пошла мода на асинхронность и push от сервера на клиент, поэтому был выбран tornado и tornadio2, тем более про него на хабре недавно писали. Тут сразу вылезла проблема, из tornadio2 не получилось достать куки. Поэтому пришлось городить костыль из отправки id с «секретом» от клиента через socketio, что немного усложнило реализацию. После всего этого получилось небольшое сравнение с django + json-rpc:
tornado + tornadio2 django + json-rpc
Плюсы push с сервера;
легковесность;
скорость;
простота;
стандартизированный протокол;
Минусы сложность;
«кривая» работа с куками;
монструозность;
периодические запросы для симуляции push'а;

Тут всё неоднозначно, но из-за push вариант с tornado всё-таки лучше.

Для клиентской части ничего особого придумать не получилось, поэтому использовались просто coffee script, haml и sass, что помогло сэкономить много строчек кода.

Деплой


Долго не думая, я решил разворачивать всё на сервере через nginx используя стандартную схему:



Но ни тут то было. Оказалось, что nginx не поддерживает web сокеты и было 3 варианта решения проблемы:
  1. Ставить нестабильный nginx.
    Для ubuntu есть ppa, из него я и поставил, но отвалилась http авторизация, решить проблему не получилось. А так как на сервере лежит ещё и mercurial репозиторий с такой авторизацией, вариант быстро отпал.
  2. Собирать nginx с tcp proxy.
    Найдя простую инструкцию, всё получилось собрать. Все старые проекты запустились. Но тут или я где-то ошибся, или что, но сделать нормальную работу websocket'ов не получилось. Вариант отпадает.
  3. Использовать HAProxy.
    Тут получается схема с оверхедом, которую проще показать картинкой:



    С ней всё запустилось и заработало хорошо.

Итог


Это, конечно, всё круто, удобно и быстро, но есть ещё много косяков. Основной косяк с деплоем, но конечное решение получается не таким уж плохим.

github с кодом.
В запущенном виде.
Tags:
Hubs:
+52
Comments 33
Comments Comments 33

Articles