Высокая доступность приложения
Статический контент
Это очень быстро. А главное анонимус себя быстрее заDDoSит пока реплицированная и с балансировщиком нагрузки база данных отдыхает попивая коктейль в закрытом пляже для своих.
Заодно ограничим количество запросов с одного адреса до одного в секунду:
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_req_status 444;
server { location / { limit_req zone=one burst=5; } }Еще добавим limit_conn_zone для ограничения количества подключений с каждого IP-адреса до 10-и.
limit_conn_zone $binary_remote_addr zone=addr:10m;
server { location / { limit_conn addr 10; } }С дятлом мы разобрались теперь с улиткой (ограничим медленные запросы):
server { client_body_timeout 5s; client_header_timeout 5s; }Затем анонимус будет пытаться брутфорсить логин, врятли что-то получится за 3 попытки с увеличивающимися паузами, а затем придется менять IP.
Но не только атаки или всплеск активности пользователей, но и пользовательский опыт будет в восторге, если отдавать пользователю для веб версии готовый html, с отложенной загрузкой связанных файлов, а для роботов (клиентов API) - json .
Связанные файлы хранятся отдельно, приложение отдельно, база отдельно.
Подключаться к базе только по необходимости.
Основные данные, для быстрой отдачи пользователю без запроса к базе данных, генерируются в json при создании объекта, если json отсутствует в статическом файле для определенного вида/выборки, обращаемся к базе.
Критические страницы приложения (наиболее подверженные атакам или нагрузкам) - главная, логин, поиск, пользовательский профиль и страница, журналы, новостные ленты, чаты, заказы - первично, не подключаются к базе, используют сгенерированный (кэшированный) json (обновляются через сокет, после рендера на клиенте) .
Мультисервисная архитектура
Если коротко, то приложение можно разобрать на множество частей и все работает по отдельности. Каждая часть проверяет зависимости на доступность, если зависимости доступны, расширяет свой функционал.
Отказоустойчивость:
Балансировка серверов:
В зависимости от нагрузок и много больше относится к статическим файлам, чем к приложению или любым другим клиентам, которые их запрашивают.
Репликация Базы данных:
Добавление реплик в зависимости от нагрузок по принципу: Мастер - Мастер. В разные датацентры во избежание обстоятельств непреодолимой силы.
Сегментирование Базы данных:
1. Для чтения 2 Для сложной выборки 2. Для записи
Таблицы:
Большой полнотекстовый Контент объекта, может весить несколько мегабайт его мы храним отдельно от объекта и даже можем архивировать.
Выполненные заказы отправляются в архив и хранятся отдельно от активных заказов в работе.
Также в архив отправляются чаты, последнее сообщение в котором более месяца назад, при активировании переписки, возвращается обратно.
