![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Про ЖЖ как вебприложение
Jan. 5th, 2013 12:49 pmЯ вот тут сейчас подумал про ЖЖ с технической точки зрения
Известно, что ЖЖ технически достаточно сложен был уже во времена Фицпатрика, я видел диаграму обьясняющую его начинку, это впечатляет, поверьте на слово
Конечно, Сиксапарт и Суп уже более усложнили его с тех пор. Но тут есть одно важное НО!
Дело в том, что основная часть сложности ЖЖ - не в основном модуле, а во вспомогательных. Насколько я понимаю, ЖЖ можно представить себе состоящим из 4 частей
1. Впереди стоит сложный лоуд балансер, проприетарный или жестко кастомизированный сторонний
2. За ним стоит основной модуль (core) который работает в тесной связи с
3. Свистелками-жужжалками, а так же такими неизбежным, многочисленными и муторными штуками как системы стилей, шаблоны вебстраниц и тп.
4. Сзади стоит сложная, большая база данных, со множеством проприетарных придумок для оптимизации ее работы
Все это крутится на некотором количество своих дедикейтед серверах.
Если бы ЖЖ создавался сейчас с нуля, на основе современных технологий, и если бы владельцы не имели религиозных запретов на использование внешнего хостинга, то
ВСЕ МОЖНО БЫЛО БЫ СДЕЛАТЬ ГОРАЗДО ПРОЩЕ
Дело в том, что если бы ЖЖ был изначально построен как облачное приложение, скажем, на Гугл Апп Эджине, сразу бы были бы полностью сняты проблемы с п.1, п.4, и количеством необоходимых хардварных ресурсов. У Гугла есть свой, совершенно state of the art айпи редиректор, дос митигейшен утилиты и проч. У Гугла есть своя, нереляционная, чудовищно безразмерная, адски быстрая на чтение и достаточно быстрая на запись проприетарная база (Big Table). ДОС атак вообще не было бы, потому что нет смысла ДДОСить Гугл, силенок не хватит, разве что все ботнеты мира обьединить в один удар, но это используется только для начала 3 мировой войны, не меньше. Проблема бэкапа данных вообще не стоит, ибо она спрятана на нижнем уровне в базе.
Что осталось бы ? осталось бы относительно несложная часть п.2 и сложная, но неизбежная часть п.3, вне зависимости от того, сколько там было бы свистеллок и жужжалок. Даже без свистелок, п.3 - плод долгой и кропотливой работы немалого количество людей, дизайнеров, верстальщиков, фронтэнд инженеров и т.д.
Но п.2, само ядро серверной части, мне кажется не просто простым, а совсем простым. Грубо говоря, у вас есть 3 таблицы, одна для юзеров (там же в Блоб-полях содержится их аватарки), другая для постингов, третья для комментов. Хотя можно и постенги и комменты обьединить. Юзеры логинятся, или не логинятся, запрашивают показ постингов, запрашивают показ кусочка френд ленты, юзеры добавляют новые постинги. Типа все. Это ЯДРО, core. Это уже может, без свистелок и суперсложных шаблонов станицы, обеспечить базовую функциональность. А проблемы нагрузки большого количества посетителей, как уже выше писал, решается через Гугловский лоуд балансер, через автоматическое создание стольких инстанстов вебсерверов сколько нужно, из Гугловского (практически) безграничного хардварного пула, и за счет out-of-the-box супероптимизации Big Table
Иными словами, если бы небольшой команде разработчиков поставлили задачу написать минималистический клон ЖЖ без свистеллок, стилей и т.п. на основе Гугл Апп Энджины, то они бы смогли это сделать за короткое время и результат работы уже был бы способен держать удар большого количество юзеров, за счет облачной архитектуры и гугловских ништяков описанных выше.
Известно, что ЖЖ технически достаточно сложен был уже во времена Фицпатрика, я видел диаграму обьясняющую его начинку, это впечатляет, поверьте на слово
Конечно, Сиксапарт и Суп уже более усложнили его с тех пор. Но тут есть одно важное НО!
Дело в том, что основная часть сложности ЖЖ - не в основном модуле, а во вспомогательных. Насколько я понимаю, ЖЖ можно представить себе состоящим из 4 частей
1. Впереди стоит сложный лоуд балансер, проприетарный или жестко кастомизированный сторонний
2. За ним стоит основной модуль (core) который работает в тесной связи с
3. Свистелками-жужжалками, а так же такими неизбежным, многочисленными и муторными штуками как системы стилей, шаблоны вебстраниц и тп.
4. Сзади стоит сложная, большая база данных, со множеством проприетарных придумок для оптимизации ее работы
Все это крутится на некотором количество своих дедикейтед серверах.
Если бы ЖЖ создавался сейчас с нуля, на основе современных технологий, и если бы владельцы не имели религиозных запретов на использование внешнего хостинга, то
ВСЕ МОЖНО БЫЛО БЫ СДЕЛАТЬ ГОРАЗДО ПРОЩЕ
Дело в том, что если бы ЖЖ был изначально построен как облачное приложение, скажем, на Гугл Апп Эджине, сразу бы были бы полностью сняты проблемы с п.1, п.4, и количеством необоходимых хардварных ресурсов. У Гугла есть свой, совершенно state of the art айпи редиректор, дос митигейшен утилиты и проч. У Гугла есть своя, нереляционная, чудовищно безразмерная, адски быстрая на чтение и достаточно быстрая на запись проприетарная база (Big Table). ДОС атак вообще не было бы, потому что нет смысла ДДОСить Гугл, силенок не хватит, разве что все ботнеты мира обьединить в один удар, но это используется только для начала 3 мировой войны, не меньше. Проблема бэкапа данных вообще не стоит, ибо она спрятана на нижнем уровне в базе.
Что осталось бы ? осталось бы относительно несложная часть п.2 и сложная, но неизбежная часть п.3, вне зависимости от того, сколько там было бы свистеллок и жужжалок. Даже без свистелок, п.3 - плод долгой и кропотливой работы немалого количество людей, дизайнеров, верстальщиков, фронтэнд инженеров и т.д.
Но п.2, само ядро серверной части, мне кажется не просто простым, а совсем простым. Грубо говоря, у вас есть 3 таблицы, одна для юзеров (там же в Блоб-полях содержится их аватарки), другая для постингов, третья для комментов. Хотя можно и постенги и комменты обьединить. Юзеры логинятся, или не логинятся, запрашивают показ постингов, запрашивают показ кусочка френд ленты, юзеры добавляют новые постинги. Типа все. Это ЯДРО, core. Это уже может, без свистелок и суперсложных шаблонов станицы, обеспечить базовую функциональность. А проблемы нагрузки большого количества посетителей, как уже выше писал, решается через Гугловский лоуд балансер, через автоматическое создание стольких инстанстов вебсерверов сколько нужно, из Гугловского (практически) безграничного хардварного пула, и за счет out-of-the-box супероптимизации Big Table
Иными словами, если бы небольшой команде разработчиков поставлили задачу написать минималистический клон ЖЖ без свистеллок, стилей и т.п. на основе Гугл Апп Энджины, то они бы смогли это сделать за короткое время и результат работы уже был бы способен держать удар большого количество юзеров, за счет облачной архитектуры и гугловских ништяков описанных выше.
