http://brubeck.io/

Предназначен для построения масштабируемых вэб-сервисов.
В качестве работающего примера предлагают посмотреть каталогизатор ссылок Listsurf - аналог Deliciuos.

Построен на базе вэб-сервера Mongrel2, библиотеки ZeroMQ (транспорт-уровень на сокетах), Eventlet (сетевая библиотека для параллельной обработки запросов, использующая парадигму сопрограмм) и DictShield (обработка входных данных).
Сами данные можно хранить в любой базе на ваше усмотрение.

На странице http://brubeck.io/design.html авторы дают пояснения относительно выбора инструментов.

Каково ваше мнение по поводу этого фреймворка?

Что-то я не понимаю, зачем смешивать Mongrel, ZeroMQ и eventlet. Какая польза от неблокирующих сокетов при работе с ZeroMQ (при том что фасад и так спрятан за Mongrel)?

Андрей Светлов
Какая польза от неблокирующих сокетов при работе с ZeroMQ (при том что фасад и так спрятан за Mongrel)?

Если я правильно понял, ZeroMQ используется внутри масштабируемой системы, чтобы минимизировать время передачи данных и директив, поступающих на Mongrel.
От Mongrel данные передаются на другие узлы, которые и занимаются их непосредственной обработкой.

Что касается Eventlet, авторы объяснили это в соответствующем подразделе описания структуры проекта: http://brubeck.io/design.html
С оговоркой, что это их выбор, а мы может использовать что нам больше нравится: gevent, Twisted, Node.js, Web Machine.

Да читал я их объяснение…
У нас фасад zerogw (тоже работает через ZeroMQ с питоноскими процессами).
Так вот, вообще не возникло необходимости в асинхре.
Если один синхронный обработчик не справляется — нужно завести рядом второй такой же.
Асинхронный должен быть фасад (Mongrel это умеет) — и этого достаточно.

Асинхронность обработчика запросов всегда будет плюсом. Есть 4 ядра, запустил 4 обработчика и все, следить за тем, справляются ли запущенные процессы или нет не надо, надо только добавлять новые сервера. И серверами наверное проще управлять чем отдельными процессами. В Mongrel2 это вообще должно быть просто, т.к. никто обработчиками не управляет, они сами встают в строй и если помрут - этого никто не заметит.

Кажется, сводить все к «4 процесса-обработчика на 4 ядра» совсем не правильно. Заманчиво, но не сработает.
Так или иначе придется разглядывать статистику по нагрузке и потом уже решать.
Зато писать синхронный код намного легче.
Более того, проще собирать статистику в случае мелко гранулированных процессов, а не мегамонстров «всё в себе».

Андрей Светлов
Что-то я не понимаю, зачем смешивать Mongrel, ZeroMQ и eventlet. Какая польза от неблокирующих сокетов при работе с ZeroMQ (при том что фасад и так спрятан за Mongrel)?

Давайте не отходить от темы, эта связка оправдана, код на eventlet/gevent тоже выглядит синхронным, серверов надо меньше, обслуживать их проще и дешевле, перегрузки (и атаки) не так страшны… Профит!

Андрей Светлов
У нас фасад zerogw (тоже работает через ZeroMQ с питоноскими процессами).
Так вот, вообще не возникло необходимости в асинхре.

Если не брать в расчет список TODO zerogw (понятно, что ему еще расти и расти), то у меня пока 1 вопрос.
Как у вас реализовано горячее (если оно есть) подключение в кластер новых нод, занимающихся непосредственной обработкой запросов?

Запуск процесса-обработчика, которому конфигуратор указывает все необходимые адреса для ZeroMQ sockets. Больше ничего не требуется.
Обработчик имеет верхнеуровневый класс компонента. В классе создаются объекты сокетов, редиса и т.д. Всё, естественно, обёртки над низкоуровневыми I/O.
У каждой такой обертки есть метод configure. Конфигуратор вызывает configure у всех, передавая нужные параметры (каждому свои, он знает).
Различные конфигураторы запускают систему по-боевому, для разработчика (удобно свести обработчики в один процесс и общаться через unix sockets), функциональные и нагрузочные тесты.

poltergeist, еще раз.
Мелко нарезанные компоненты, запущенные каждая в своем процессе, позволяют легко мониторить память, проц и сетевую нагрузку.
Если монолит в 500 обработчиков на гринлетах занимает 100% CPU и при этом кушает память как не в себя — трудно найти конкретного виновника.
Проблема размазана по всему коду.
Цена «падения процесса», кстати, тоже возрастает, перезапуск медленный и балансировка ресурсами сложнее.
Серверов нужно столько же — запускайте на одном физическом сервере столько компонент, сколько этот сервер вытянет.
Про перегрузки и атаки вообще не понял. Изолированный в рамках процесса проблемный компонент легче локализовать, прибить, перегрузить, сбалансировать и т.д. Если в гринлетах попадется долгоиграющий синхронный процесс, поймать его очень нелегко.

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