Бюджетная архитектура 24x7

Рано или поздно перед любым программистом возникает задача - организовать работу какого-нибудь сервиса в режиме 24x7, т.е. он должен работать всегда. Потеря хотя бы одного запроса неприемлема и равноценна падению всей системы. Как решить "малой кровью" такую, казалось бы, сложную задачу?

Описанное далее решение не просто так является "бюджетным", оно не подходит для сервисов и систем реального времени, большие интервалы перед ответом являются нормой. Ниже рассмотрено функционирование подобной системы.

Как видно из рисунка, клиент отправляет запрос сервису с двумя параметрами - данными для обработки и адресом для обратного вызова. Через некоторое время T, когда данные будут обработаны, сервис присылает ответ на переданный ранее URL. Особенность рассматриваемой архитектуры в том, что величина T не критична для клиента и может достигать нескольких часов, основным требованием является то, что на любой отправленный запрос всегда придёт ответ.

Как можно объяснить допустимость такой задержки в работе сервиса? Специфичностью работы самой системы. Допустим, данные, переданные клиентами, будут обрабатываться людьми, а затем отправляться обратно. Это применимо к:

  • системам документооборота (подача различных заявлений, их централизованная проверка и подтверждение или отклонение);
  • системам проверки размещаемых данных (когда модераторы централизованно проверяют опубликованные сообщения, фотографии, видеоролики);
  • любым системам обработки данных, для которых нет жёсткого ограничения по времени взаимодействия.

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

Минимальная комплектация для реализации такой системы:

  • один балансировщик нагрузки;
  • два сервера с запущенным приложением;
  • сервер базы данных;

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

Рассмотрим, что происходит после того, как запрос доставлен на конкретный сервер

У запущенного приложения есть два независимых режима работы для получения запросов:

  1. Режим принятия запросов - каждый принятый запрос записывается в файл (назовём его receive mode);
  2. Режим обработки запросов - приложение обрабатывает файлы с запросами, а именно конвертирует их и записывает в базу данных (сохраняет запрос и url для ответа) (назовём его save mode).

Любой сервер может обрабатывать как свои запросы, так и файлы на соседних компьютерах, это позволяет запускать на некоторых машинах только режим "принятия запросов", а на более мощных серверах оба режима. Рассмотрим пример для системы с двумя серверами, один из которых более мощный.

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

  1. Приложение берёт из базы данных информацию и url для отправки клиенту;
  2. Делает запрос на сервер клиента и передаёт данные;
  3. Если клиент не подтвердил то, что принял данные, они записываются в файл, как неудачно отправленное уведомление. Эти файлы, аналогично файлам с запросами, будут обрабатываться всеми серверами сообща. Если клиент подтверждает принятие запроса, файл удаляется.

Теперь рассмотрим, как будет происходить процесс обновления кода приложения и структуры базы данных:

  1. Все серверы переводятся в режим receivemode. Это делается для того, чтобы прекратить обращения к базе данных, теперь запросы будут только записываться в файлы.
  2. Программно отключается первый сервер - теперь балансировщик нагрузки будет посылать все запросы на остальные серверы, в обход отключенного.
  3. На выключенный сервер устанавливается обновлённая версия приложения.
  4. Обновлённый сервер включается в режиме receive mode и снова начинает принимать запросы и сохранять их в файлы.
  5. Аналогичным образом обновляются все серверы.
  6. Затем обновляется структура базы данных.
  7. После этого на серверах, которые работали в обоих режимах, включается save mode и возобновляется обработка сохранённых запросов и запись их в базу данных.

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

Плюсы рассмотренной архитектуры:

  • работа в режиме 24х7 без потерь входящих запросов;
  • возможность свободно обновлять код приложения и менять структуру базы данных;
  • простое масштабирование системы;
  • возможность переноса всей системы на другие серверы без потерь запросов.

Минусы рассматриваемой архитектуры:

  • возможность наличия больших временных задержек между принятием запроса и отправкой ответа;
  • жёсткая привязка к формату хранения запроса в файле. Поэтому структуру файла необходимо заранее хорошо продумать и не вдаваться в детали запроса на данном уровне (например, использовать поля, точно определяющие клиента, поле с данными запроса и url для обратного вызова);
  • узким местом может стать большое количество маленьких файлов, об этом тоже лучше задуматься заранее (например, писать несколько запросов в один файл).

В целом, данное решение может подойти как мелким проектам, так и крупным масштабируемым системам, основной недостаток - временные задержки.

Никита МАНЬКО

Версия для печатиВерсия для печати

Рубрики: 

  • 1
  • 2
  • 3
  • 4
  • 5
Всего голосов: 0
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

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