Задать вопрос

Теория: структура высоконагруженного сервиса?

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

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

Каковы мои размышления на тему, вопросы по каждому пункту прямо в нем:

— имеется домен (имя взято с потолка) hls.com

— у регистратора у этого домена прописано максимальное количество DNS серверов (6?), которые собственные и разбросаны по миру (имеет ли это смысл?)

— DNS зона содержит в себе максимальное количество A и AAAA записей (32?) дабы получить DNS round-robin.

— На каждом адресе, указанном в DNS, висит load-balancer (аппаратный или же софтовый? как load-balancer определяет какой сервер выдать, как он определяет самый менее нагруженный сервер?)

— Каждый load-balancer заведует неким количеством ngnix-серверов (или какой-то другой софт, если да, то какой? как ngnix может выбрать сервер самый менее нагруженный?)

— ngnix-сервер заведует неким количеством web-серверов, которые собственно дают контент.

— Каждый web-сервер имеет на машине Apache HTTP, PHP или Ruby и локальный memcached (или локальный не стоит?)

— За web-серверами стоят 2 вида баз данных — там где хранятся связи между объектами и собственно сами объекты. Все из них по условию должны уметь масштабироваться горизонтально.

— В качестве распределенного хранилища объектов используем что-то вроде memcacheDB или BigTable (или какую-то другую? т.е. у каждого объекта есть уникальный ключ, несущий в себе не только ID объекта как таковой но и информацию о типе объекта)

— В качестве распределенного хранилища связей нужно использовать какую-то БД на основе графа (правильно? если да, то какую?)

— Имеется также 2 набора memcached серверов которые кешируют запросы к обоим видам БД.


Хабралюди, мыслю ли я в правильном направлении? Что я не учел? Где почитать? Кто уже делал? Помогите просветлиться в этом.
  • Вопрос задан
  • 10330 просмотров
Подписаться 30 Сложный 5 комментариев
Ответ пользователя Евгений К ответам на вопрос (9)
@immaculate
Программист-путешественник
В моем случае проект был написан «абы-как». Точнее, довольно грамотно, но без каких-либо мыслей о том, что пользователей станет много, и придется как-то масштабировать. Более-менее красивый код, куча таблиц, связанных друг-с-другом, то есть чуть ли не десятки JOIN'ов. Кэширование не использовалось вообще.

Все работало (и работает) на 3-х серверах: база PostgreSQL, nginx для статики, nginx с gunicorn для собственно приложения.

Первые два года этого хватало, но росло количество пользователей и фич, в итоге, приходится периодически садиться и переписывать куски кода: денормализовывать базу, чтобы избежать JOIN'ов и поисков в дополнительных справочных таблицах, пытаться воткнуть кэширование (самая большая головная боль — кэширование надо предусматривать в самом начале и очень-очень хорошо продумывать), и т.д. и т.п.

Просто описываю свой опыт. Мне кажется, мораль такая — не надо изначально все переусложнять. Надо думать о производительности, но не до фанатизма. Скорее всего, на первых порах хватит простого кода и одного-двух серверов. Вряд ли у вас сразу же получится вторая мордокнига по популярности. Напротив, те, кто думают, что их проект тут же захватит мир, чаще всего ошибаются.
Ответ написан