Эта статья предназначена для групп, которые используют ограниченные архитектуры и хотят выполнить обновление, чтобы обеспечить масштабируемость приложения.
Наиболее распространенное монолитное приложение выглядит примерно так:
Это наиболее распространенная архитектура для этого типа продуктов, иногда что-то может измениться, например, заменить монолитную базу данных на федеративную базу данных (или функциональное разделение). Можно использовать выделенный сервер кэширования, такой как Redis, или иметь реплики базы данных SQL.
Но основная проблема не совсем в этом, более серьезной проблемой является обновление архитектуры, если у вас есть большое количество непредвиденных пользователей, мерой безопасности, вероятно, будет обновление всех серверных машин (значительно возрастающие затраты)или просто наблюдая за падением приложения на пике доступа.
Как вы, должно быть, догадались, первым шагом к более качественной архитектуре является предоставление масштабируемости этому приложению, как именно это должно быть?
Большой отказ от ответственности
- Это не серебряная пуля для всех случаев, но должна работать в большинстве случаев(серебряная пуля — это сказка);
- Последовательность — это то, что делает проект более организованным. Не меняйте код, не спланировав изменения заранее;
- Некоторые изменения могут вызвать большие проблемы, если они сделаны без осторожности. Я настоятельно рекомендую провести автоматизированные тесты перед выходом и изменением работы системы.
Первые шаги к качественной архитектуре
Удалите все централизованные зависимости приложения. В примере приложения, если есть простая задержка в какой-либо точке, это повлияет на все приложение, и это действительно плохо!
Если в ваше приложение уже интегрирована система кэширования, лучше всего будет перейти на независимый сервер, что-то вроде внешней базы данных Redis или чего-то подобного.
Статические активы, такие как CSS, JS и изображения, которые находятся внутри пабликов/активов в основном проекте. Убедитесь, что все это передается клиенту в минимизированном виде, а затем переместите все это в службу CDN, динамические изображения, такие как изображения профиля или сообщения, могут быть перемещены в службу S3 без проблем.
На этом этапе ваше приложение, вероятно, не нуждается в центральной службе, тогда вам нужно начать рефакторинг архитектуры ваших серверов.
Пример того, как ваша архитектура должна выглядеть прямо сейчас
Копать глубже
На данный момент у вас есть приложение с минимальной масштабируемостью на сервере, но очень важная централизованная база данных, у нас есть несколько разных областей для атаки.
Работа с репликами чтения SQL
Когда вы настраиваете реплики SQL, вы можете выполнить балансировку своей базы данных без вертикального масштабирования, в этом случае все операторы выбора, которые вы отправляете на соединение с репликой, и только вставка, обновление и удаление, которые вы должны отправлять в свою основную базу данных.
В большинстве систем большая проблема заключается в операторах select, нет особых проблем, если вашей форме требуется 30 или 40 секунд для сохранения данных, но если у вас есть эта задержка на начальной странице, возможно, вы потеряете своего пользователя или, по крайней мере, он раздражать его.
Представьте панель администратора, которая имеет 30-секундную задержку на каждом экране, который вы используете, это очень плохо в использовании, если вы отправляете эти запросы на реплики, вы можете улучшить свою базу данных, чтобы этого не произошло.
Перенос медленных операций в асинхронный сервис
Это, вероятно, самая простая задача в этой статье, если вы используете хороший фреймворк, в большинстве из которых уже интегрирована система очередей. Все, что вам нужно сделать, это перенести все медленные операции в службу очереди и не задерживать пользователя во время этих операций.
Некоторые медленные операции, которые можно превратить в асинхронные:
- медленные интеграции третьей части, которые могут отправлять веб-хуки;
- Тяжелые запросы в админке;
- обновления приборной панели;
- Отправляйте уведомления по электронной почте/смс.
В этом случае вы можете вернуть только сообщение: «Наш сервер обрабатывает этот запрос, через несколько секунд он будет доступен!».
Просмотрите все API, которые можно кэшировать
Это не так просто сделать, но очень сильно влияет на использование базы данных. В приложении с большим количеством динамического контента с небольшими изменениями обязателен хороший кеш.
Представьте, что блогу при каждом поиске сообщений нужно искать данные в базе данных SQL, это довольно глупо. Правильный способ кэширования этих данных и в случае изменений сделать недействительным конкретный кеш этого поста, чтобы вы могли поддерживать нормальную работу других кешей.
Таким образом, вам нужно только найти эти «критические» точки и создать кеш для этого, ваша база данных SQL будет счастлива!
Пример того, как ваша архитектура может выглядеть
После этих шагов у вас обязательно будет масштабируемая и надежная архитектура.
