Посоветуйте чтиво по фреймворкам / архитектурам для масштабируемых приложений

Elgg Social Networking: Create and manage your own social network site using this free open-source tool

вот вам тезис http://spb-borodin.livejournal.com/596.html и антитезис к нему http://alexclear.livejournal.com/474580.html

«Your First Cup: An Introduction to the Java EE Platform»

Бродин производит впечатление человека, который рассказывает лохам свою историю успеха за деньги. Нам такого не надо.

Действительно хорошая книжка? В электронном виде продается?

Пока догуглился до слов PaaS, и в частности Eucalyptus. Смотрю, чего в мире происходит, ищу опенсорцные решения.

а вы там отбростье лирику и обратите внимание на техническую составляющую:

В хайлоде применяются только примитивные запросы, типа SELECT по primary key.

Неважно, какую базу данных выбрать, т.к. мы будем использовать 1% ее возможностей

Наши SQL не пишут транзакции на диск. Специально.

Т.е. это подход «key-value», антитезис к нему я привел.

мне лично более близок такой вариант: http://www.insight-it.ru/masshtabiruemost/arkhitektura-disqus/ (т.е. балансировка+кэширование)

insight-it.ru уже читали?

Почитываю время от времени. Там довольно общие вещи, хотя написано хорошо.

Прикидывал «в уме» - под мои задачи на монге довольно просто рисуются базы, которые будут нормально шардиться и мапредьюситься. Как странички напилить на независимые приложения - тоже примерно понятно.

А вот чего непонятно - как организовать взаимодействие между приложениями, не изобретая лисапеда. Тот уровень, который лежит под API фконтактега и фейсобука. Самое близкое, что нарыл - eucaliptus, c реализацией амазоновских API. Хотелось бы конкретных примеров, если такие в природе вообще есть.

мне лично более близок такой вариант:

Это никакой не вариант, горизонтальное масштабирование там очень слабенькое. Ну ясень пень, что такой подход проще. Только вот фейсбук на таком не сделаешь.

А вот чего непонятно - как организовать взаимодействие между приложениями, не изобретая лисапеда.

Ну да, ничего изобретать не надо, HTTP, т.е. REST уже изобретен. Ну и кури форматы вроде protobuf, thrift. XML только где очень нужно, ибо тяжелый.

JEE за тебя базу не пошардит. А вот кое-какая некислая современная инфраструктура будет, это да.

Мне кажется, что слишком много молодых людей пихают сейчас key-value и шардинг туда, где он не нужен. Неплохо было бы сначала построить нормальное приложение, и если он будет становиться популярным - начать оптимизацию или менять архитектуру. Когда приложение изначально строят «смасштабированным», то на это тратится то время, которое бы не помешешало вложить в функциональность приложения. И если оно(приложение) «выстрелит» - балансировка+кэширование на некоторое время позволит обеспечить работоспособность приложения.

>Your First Cup: An Introduction to the Java EE Platform

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

Монга все-таки сыровата еще, хотя для нового проекта впринципе нормально.
А для взаимодействия, например я, юзаю обычную связку oauth+rest_api. Я считаю, что нужно просто сделать нормальную клиентскую либу и предоставить нормальную документацию. Для данных я использую json, не так ынтырпрайзно как XML, но можно нормально читать и писать руками, да и по весу удобнее.

А как новые версии приложений деплоить красиво, чтобы усё без останова обновилось? Особенно когда несколько инстансов бежит на разных машинах. Или допустим надо только части юзеров новую версию сайта выкатить, с возможностью обратно отмотать.

Про такое есть где почитать?

Да собственно вот тут http://habrahabr.ru/tag/deployment/ показано откуда копать.
Я не особо много могу по этому поводу сказать, так как сам пока использую самосборные скрипты которые из гита вытягивают нужные вещи, чистят кэш и выполняют миграции для бд. А юзеры пока без деления хранятся, поэтому для всех общая функциональность.

Один из простых вариантов инкрементального деплоймента и простой архитектуры:

Лод-балансер(ы) должен(ы) поддерживать стики-сессии или имплементировать на базе Апачи. Перед залитием новой версии - один сервер (или набор серверов) выводятся из кластера (веб-фермы) на уровне балансера. Конечно, все оставшиеся юзера жёстко не дроппаются, а ждётся, когда они закончат свои сессии (деплоймент ведь не в любую минуту, а планируется, типа).
Когда на тех серверах никого нет - можно залить новую версию и протестировать независимо (не через балансер, а напрямую, по IP или домену). Можно тестировать сабкластер. Если всё нормально - сервер(а) с новой версией включается в пул в балансере. Т.е. одновременно юзера работают с обоими версиями, смотря куда их кинет. Затем, поочерёдно аналогичным образом переводятся на новую версию и остальные сервера и сабкластеры, например, скриптом.

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

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

Т.е. секрет деплоймента этой схемы - в управлении из лодбалансеров.

По реальным архитектурам - в общем об используемых ебеями, амазонами и прочими фейсбуками технологиями - можно поискать на highscalability.com (там где-то меню-список больших сайтов и их архитектур) и в обсуждениях.

То, о чем ты говоришь - очень распространенная ошибка. Дело в том, что очень сложно, а во многих случаях практически невозможно кардинально менять архитектуру работающего проекта. Сейчас вот как раз работаю над таким (балансировщик + кеширование). Его пытаются делать масштабируемым путем откалывания кусков и реализации их как масштабируемых сервисов. Однако основная часть так и остается немасштабируемым куском.

Насчет того выстрелит/не выстрелит и стоит/не стоит это уже головная боль менеджмента и тут нету универсального ответа. Риски велики, бизнес есть бизнес. Лично я бы при разработке чего то массового все же базу шардил в самом начале.

Мне в голову пришла идея попроще. Можно держать запущенными несколько версий приложения, а номер версии поставить в зависимость от группы, к которой принадлежит юзер. Например, если ему навесить группу «тестеры», то покажется новая версия.

Заодно эту фичу можно будет забацать отдельным приложением, и выводить в виде кнопки «помогите потестировать фичу XX и оставьте отзыв». Заодно юзерам меньше гимора - можно отжать кнопку, если что-то навернулось, и вернуться на стабильную конфигурацию.

Плюс ни каких проблем с синхронизацией кластера, ляпота.

Спасибо. Заценю.

> Лично я бы при разработке чего то массового все же базу шардил в самом начале.

Ага. Это особенно клево, когда почти ничего не стоит. Проект-то рабочий, и я могу вообще в потолок плевать еще десять лет, а деньги в карман класть. Просто денег все равно больше, чем трачу, а плевать в потолок скучно. Вот, развлекаюсь, под настроение.

Сейчас мне важно понять, реально ли все переписать БЫСТРО. Скажем, за год. И если реально, то на чем. А шардинг он как-то сам собой вышел. Меня больше интересует не сам шардинг, а платформы и технологии развертывания пачек мелких приложений.

Ну так а если у тебя и так есть шардинг, то собственно чего еще желать? :)

Подходов разных много, но если бы мне дали написать что-то вебовское серьезное, то как платформу взял бы: python/gevent (ибо сильно жирно в базу ходить синхронно), java (там где скорость нужна), postgresql (вертикальное и горизонтальное шардирование), memcached, nginx, deb.

Ну вот хотелось бы на халяву что-то типа фейсбучной платформы получить в личное пользование, чтобы только приложений осталось наклепать.

Все-таки, есть разница, сосредоточиться только на «виджетах», или полностью сочинять всю инфраструктуру, на которой они бегают и скейлятся.

а мне вот стало интересно, что вы называете массовым(в смысле сколько тысяч запросов в секунду к бд) и допускаете ли использование платных субд типа Oracle/RAC?

а мне вот стало интересно, что вы называете массовым

Ну это я так, чисто неформально. От нескольких сотен не слишком примитивных транзакций в секунду на запись. Со чтением проще. В пределах 10 000 запросах в секунду на чтение можно вообще не париться и юзать одну мастер базу, сильно больше уже сложнее, и надо шардить.

допускаете ли использование платных субд типа Oracle/RAC?

Смотря какая специфика. Если запросы в основном на чтение и проект без амбиций, то да, как я уже упомянул выше можно не париться и юзать свою любимую субд в штатном режиме. С ораклом конкретно не работал (из коммерческого работал только с DB2), но RAC видимо даст небольшой запас масштабируемости.

Для проектов которые «выстрелили» и адутитория стремительно растет выход один, Бородин таки прав: честная горизонтальная масштабируемость за счет пошарденой базы (тип базы не так важен, все равно в хайлоаде принято разменивать производительность на масштабируемость). Как узнать выстрелит ли проект и надо ли шардить, я уже не советчик :)

Идея хорошая, но проблему она решит только если остальной код может заливаться на «горячий» сервер одновременно с работающими юзерами, и
та кнопка потом заливается моментально, без останова сервера. Затем, изменением странички с кнопкой, моментально, атомно, следующие юзера резко увидят кнопку и пойдут уже по новому пути/коду. Сработает с простыми веб-страничками, но, боюсь, не с современными фреймвоками с богатой функциональностью. Ведь availability должна быть 24/365, т.е. юзера в системе всегда, и дроппать нельзя никого. Для заливки вот той версии, с кнопкой, либо самой кнопки (которая будет на какой-то сложной странице с функционалом) скорее всего почти всегда всё же потребуется остановка инстанса сервера, на который идёт заливка (ещё небось с перезапуском), и для прозрачности этого для юзеров - лучше сделать это с балансера (не пускать новые сессии), но дождаться, когда старые досидят до конца. Либо сразу сделать функциональность, которая будет перекидывать юзеров на другой сервер, прозрачно для них, с изменением их группы. Тогда сервера должны уметь друг с другом уметь разговаривать. Но тут можно слишком всё усложнить и погрязнуть в ошибках. Лучше проще. Простота гарантирует надёжность.

Дык код же не поверху переписывается. В отдельную папку, с номером версии. Потом мягкий перезапуск, без обрыва коннектов, как у nginx.

Можно конечно и входным балансировщиком юзеров разруливать. Но во-первых это не будет пахать когда сервер один, а во-вторых усложнит балансировщик, который в простейшем случае может быть вообще nginx-ом c round robin.

Сработает с простыми веб-страничками

Ну что б все заливалось хорошо, их приходится наворачивать

Ведь availability должна быть 24/365

Такого не бывает в природе. Нужно учиться работать с небольшими простоями.