Кейс: за две недели разработали сервис подсчета результатов для образовательного портала

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

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

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

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

Мы обсудили с заказчиком требования к сервису и сформулировали техническое задание. Нам предстояло реализовать:

• HTTP API endpoint — для принятия и обработки веб-хуков;
• базу данных — для хранения результатов;
• обработчик очереди задач — для отправки результатов после обработки веб-хуков;
• интеграцию с Telegram — для отправки уведомлений.

Мы предложили разрабатывать сервис на Django — фреймворке Python. Он подходит по нескольким причинам:

• Сервис нужно разработать быстро, иначе клиент платформы уйдет к конкурентам. Фреймворк Django позволяет использовать готовые решения и не писать лишний код — разработка сервиса, включая согласование и тестирование, в итоге заняла у нас 2 недели.
• Сервис не требует отдельного веб-интерфейса, с которым взаимодействует пользователь. Его задача — восполнить отсутствующие функции между платформой и сервером компании-клиента. Django подходит именно для бэкенд-разработки.
• Сервису нужны стандартный API и взаимодействие с базой данных. У Django есть готовые решения для этих задач. Мы использовали библиотеку django-rest-framework для подключения REST API и инструмент Django ORM для работы с БД.

Метод 1:

• Принимает данные с сервера платформы через веб-хук. Это автоматически сгенерированный HTTP-запрос, который ускоряет обмен данными. Сервису нужно получить результаты теста пользователя от сервера платформы. Но он не знает, прошел пользователь тест или нет. При использовании стандартных запросов сервис периодически спрашивает платформу: есть результаты? Если на момент запроса тест пройден, сервер присылает в ответ данные. А веб-хук — это как подписка на событие. Как только пользователь прошел тест, сервер автоматически создает HTTP-вызов и отправляет данные сервису. Через веб-хук сервис быстрее получает данные и не нагружает сервер частыми запросами.
• Когда данные поступили, метод 1 проверяет их на соответствие требуемой структуре и сохраняет в базе данных.
• Если возникает проблема во время обработки запроса, метод 1 передает ошибку в метод 3. Если все успешно — формирует задачу на отправку результатов на сервер компании-клиента для метода 2.

Метод 2:

• Запрашивает в базе данных суммарный результат по пользователю — по всем тестам, которые он выполнил.
• Подготавливает и передает на сервер компании-клиента обновленные данные

• Если возникает ошибка при обращении к базе данных или отправке данных на сервер клиента, метод 2 передает ее методу 3.

Метод 3:

• Отправляет на сервер Telegram сообщения об ошибках, которые присылают методы 1 и 2.

Для хранения промежуточных результатов мы создали базу данных. Когда пользователь завершает тест, метод 1 передает информацию в базу. Пользователь выполняет еще задание, результаты опять поступают в базу, данные дополняются.

Метод 2 запрашивает суммарный результат по пользователю у базы и отправляет на сервер клиента платформы.

Через веб-хук сервис обработки данных получает информацию от сервера о том, что на платформе произошло событие: пользователь прошел тест. За получение веб-хука отвечает метод 1: он принимает запрос на URL сервиса.

Основные этапы работы:

1. Описали модели базы данных User и Result.

2. Добавили библиотеку DRF и описали:

• сериализаторы данных. Это объекты, описывающие структуру принимаемых данных и правила для их валидации — проверки на соответствие заданным условиям.

• метод View — метод обработки HTTP-запроса, включающий правила разграничения доступа.

3. Настроили роутинг — задали URL, по которому будут приниматься запросы, и связали его с обработчиком View.

4. Добавили отлов ошибок на ключевых этапах: запись в БД, валидация структуры данных.

Метод 2 отвечает за передачу суммарного результата пользователя на сервер компании-клиента. Для этого он запрашивает его в базе данных, формирует объект необходимой структуры и отправляет на сервер.

Отправка результатов выполняется не сразу после поступления данных, это отложенный процесс. Когда сервер платформы присылает веб-хук, метод 1 обрабатывает его и формирует для метода 2 задачу: отправить на сервер обновленный результат. Задача встает в очередь из таких же задач. Их выполнение реализовано через Celery.

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

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

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

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

Django позволяет настроить взаимодействие сервиса со сторонними программами, например с Telegram. Для отправки сообщений об ошибках мы написали бота-помощника.

Благодаря фреймворку Django мы разработали сервис обработки данных менее чем за 2 недели с начала получения ТЗ. Наши результаты:

• Сервис решает задачу заказчика: производит вычисления, сохраняет данные в БД, затем передает конечный результат на сервер компании-клиента.
• Сервис аккумулирует данные 50 000 пользователей компании-клиента. Они хранятся во внутренней базе данных и используются при обновлении информации: например, когда пользователь прошел еще один тест и сумма баллов изменилась.
• В случае ошибки в передаче данных система отправляет администратору уведомление в Telegram.