Unetway
Масштабирование бэкенда (backend) приложений

Масштабирование бэкенда приложений

Backend (Бэкенд) является внутренней областью приложений,  где происходит работа с бизнес логикой и обрабатываются совершаемые действия пользователей и события в ответ на них.

Я предыдущей статье я описывал разработку высоконагруженных проектов в общем, теперь чуть подробней о бэкенде.

Масштабирование бэкенда

Бэкенд отвечает за все, что происходит на серверной части приложения. Бэкенд разделяется на набор компонентов, каждый из которых отвечает за выполнение определенной задачи. При этом, такие компоненты могут разделяться и выноситься на отдельные физические серверы. Например, на один сервер выносится работа с постами и комментариями какого-либо сайта, на другой сервер работа со статистическими данными, рекламными баннерами. И на каждом сервере может быть индивидуальный набор настроек, необходимый для конкретного компонента. Такой подход используется для простейшего масштабирования бакенда.

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

Когда некие действия над данными являются общими для всего бэкенда, то разделять его нет необходимости. Если же эти действия на данными носят разный характер работы с данными, то по росту нагрузки на эти действия, можно разделить их на независимые компоненты на отдельных серверах. У этих подходов есть свои плюсы и минусы. Поэтому нужно в индивидуальном порядке, смотреть, какой подход выбрать для того или иного проекта.

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

Структура слоистого пирога

Лучше всего строить бэкенд так, чтобы он был в виде пирога, слоистым. То есть, как уже и говорилось, разделять его на некие отдельные компоненты, кусок каждого из которых будет отвечать за обработку каких-то определенных действий. Не нужно разбрасывать действия по всему бэкенду. Например, для получения каких-либо данных, допустим, обычных постов на сайте, пользователь делает запрос к странице. В этот момент подключается входная точка - скрипт, который обрабатывает все запросы и запускает ядро нашего приложения. Адрес, по которому зашел пользователь, проверяется в слое роутинга - тот определяет, что это за страница, есть ли она вообще. Затем дело за той частью бэкенда, которая отвечает за слой бизнес-логики, проверяет входящие параметры, в нашем случае - адрес страницы. По адресу подается запрос к слою, который отвечает за доступ к данным в базе данных. Если данные по странице с таким адресом есть, слой данных возвращает всю нужную информацию, которую на экран уже выводит слой отображения данных. Таким образом, все разделено на некие слои, которые в нужный момент выполняют поставленную задачу.

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

Кэширование данных

Еще одним важным моментом масштабирования бэкенда является - кэширование. Кэш - это место, куда можно положить часто используемые данные, которые потом можно очень быстро достать и использовать, без необходимости делать повторные запросы на их получение.

Кэшировать нужно лишь тогда, когда это действительно нужно. В первом случае, когда есть явные признаки того, что база данных работает недостаточно быстро, то данные можно кэшировать. Во втором случае, когда есть какие-то данные, которые не часто изменяются, то их можно кэшировать. Например, это какой-то счетчик подсчета количества просмотров или голосов пользователей. В любом другом случае, лучше сделать запрос и получить данные обычным способом.

При работе с кэшем нужно быть внимательным, так как появляется такой вопрос, как инвалидация кэша.

Инвалидация кэша - это когда мы положили в кэш какие-то данные, но к тому моменту когда мы их взяли, оригинал данных уже поменялся и полученная информация стала неактуальной. В этом случае появляется вопрос: когда обновлять кэш? Например, вы добавляете в свой блог посты. Список с постами должен быть всегда актуален и его кэшировать не нужно и не имеет никакого смысла. А вот допустим какой-нибудь блок "Подписчики поста" или "Оценки поста" можно и закэшировать. И тут, чтобы не возникло инвалидации кэша, нужно делать проверку и обновлять кэш при запросе на эти блоки при добавлении нового подписчика или оценки.

В любом случае, прежде чем кэшировать, нужно исследовать приложение, изменить те части, которым возможно кэширование и не понадобится.

Понравился материал? Поделитесь с друзьями!

Автор

Автор сайта «Unetway», программист по образованию, работаю менеджером проектов, занимаюсь разработкой и развитием программного обеспечения.

Комментарии

Незарегистрированным пользователям запрещено комментировать.
Войдите или пройдите регистрацию