Как настроить архитектуру сервера?

Question

[Айдар Хаятов]

Добрый день!

Планируется разработка нагруженного проекта - и сейчас планируем архитектуру. использовать будем nginx+php fpm

Приложение можно разделить на 3 основные части (mysql база, backend api, frontend js).

Посоветуйте, как правильно организовать установку этих трех частей, учитывая что нагрузка на проект со временем будет расти и нужно будет думать о масштабировании (например репликация). Все три части ставятся на один сервер? Или лучше сразу это как то разделять?

Comments

[Модератор]

Айдар Хаятов дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац).
В противном случае, ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.

Answer 1

[stratosmi]

Архитектура не настраивается.
Архитектура создается, разрабатывается.

Присоединяюсь к DevMan

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

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

Репликация не для собственно масштабирования, а для надежности. В ответственном проекте следует сделать репликацию сразу. Даже пока нагрузки нет.

Существует 2 пути:

Горизонтальное масштабирование, и вертикальное масштабирование.

Вертикальное масштабирование гораздо эффективнее использует железо до тех пор, пока железа хватает в лице одного единственного сервера. Да, все части ставить на один сервер.

Горизонтальное масштабирование подразумевает организацию взаимодействия между разными серверами. Но на которых у вас вовсе не СУБД на одном, а бекенд на втором.

А когда у вас множество СУБД, множество бекендов, размещенных на разных серверах.

И простой репликацией вы тут не обойдетесь. Понадобится как-то организовывать взаимодействие между этими частями. Типично - через MQ.

Таким образом, если вы сразу планируете дичайшие масштабы, с которыми не сможете справится на одном-единственном сервере - то вам сразу нужно так делать, чтобы могли свободно увеличивать количество бекендов и СУБД и при этом они не мешали друг другу.

Типично:
На какой бекенд будет отправлен очередной запрос? Нужно или sticky session или полное отсутствие состояния на бекенде (а второе плохо для производительности).

Типично:
Репликации? Ха. Репликация мастер-мастер - тот еще гемморой. А репликация master-slave подразумевает, что на запись у вас нагружна ровно одна СУБД.

Далее:
Удалось справится со всем этим, горизонтально масштабируете отлично. И вот у вас уже десятки серверов. Чем больше железа - тем больше падений, тем больше service discovery. И как вы это будете разрешать? Ручками? Значит придет пора подумать об оркестрации.

И т.д. и т.п.

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

Разделять СУБД и бекенд стоит с умом. Ибо это сразу увеличивает накладные расходы на каждый вызов. Добавляется сеть между СУБД и бекендом. Если вы не понимаете еще зачем разделять - то не разделять.

Comments

[Айдар Хаятов]

Спасибо огромное за ответ - будем дальше изучать