| ... | ... | @@ -19,7 +19,7 @@ |
|
|
|
|
|
|
|
> В случае, если один из сервисов не доступен, главный микросервис может отследить ошибку в отправке запроса и сформировать результат без использования данных проблемного сервиса, указав в ответе, что проблемный сервис недоступен. Это повышает степень отказоустойчивости приложения.
|
|
|
|
|
|
|
|
## 1.3 Описание алгоритма и принципа работы модулей системы
|
|
|
|
# 2 Описание алгоритма и принципа работы модулей системы
|
|
|
|
|
|
|
|
>>>
|
|
|
|
:warning: **Внимание!** :warning:
|
| ... | ... | @@ -27,7 +27,7 @@ |
|
|
|
Все ссылки с учетом строк приведены для программы на момент следующего [коммита](240/competence-search@c911531e19c93a1f7a0dc6b70b70c419284db23d). В будущем номера строк **могут быть смещены** в следствие редактирования исходного кода!
|
|
|
|
>>>
|
|
|
|
|
|
|
|
### 1.3.1 Описание алгоритма и принципа работы микросервисов-обработчиков
|
|
|
|
## 2.1 Описание алгоритма и принципа работы микросервисов-обработчиков
|
|
|
|
|
|
|
|
Алгоритм работы микросервисов-обработчиков представлен на рисунке.
|
|
|
|
|
| ... | ... | @@ -75,7 +75,7 @@ |
|
|
|
|
|
|
|
Ключами корневого объекта `JSON` являются `data` и `message`. Ключ `message` является опциональным и служит для передачи служебных сообщений (например, если запрос был выполнен, но часть данных не была загружена). По ключу `data` находится объект, хранящий префиксы почты пользователей в виде ключей объекта. Значениями этих ключей являются объекты, содержащие как минимум один ключ – имя модели (или обрабатываемого сервиса), нижнее подчеркивание и слово `score`. Значением является оценка релевантности пользователя **моделей обработки данных**. В объектах пользователей также может быть представлена любая другая дополнительная информация (например, имя пользователя в корпоративном чате **Zulip**), если в параметрах запроса был указан параметр `more` со значением `true`.
|
|
|
|
|
|
|
|
### 1.3.2 Описание алгоритма и принципа работы главного микросервиса
|
|
|
|
## 2.2 Описание алгоритма и принципа работы главного микросервиса
|
|
|
|
|
|
|
|
Алгоритм работы микросервиса **Competence Search** можно описать следующей последовательностью действий:
|
|
|
|
|
| ... | ... | @@ -143,9 +143,7 @@ |
|
|
|
|
|
|
|
В случае, если модуль-обработчик не смог обработать запрос, к корневому объекту `JSON` добавляется ключ с названием сервиса. В нем хранится объект, содержащий сообщение-предупреждение, а также `HTTP` статус ошибки `503` – «Service unavailable», «Сервис недоступен».
|
|
|
|
|
|
|
|
# 2 Интерфейс общения с пользователем и обратная связь
|
|
|
|
## 2.1 Описание работы микросервисов обратной связи и чат-бота
|
|
|
|
### 2.1.1 Описание алгоритма и принципа работы микросервиса «Gtable»
|
|
|
|
## 2.3 Описание алгоритма и принципа работы микросервиса «Gtable»
|
|
|
|
Алгоритм работы микросервиса по сбору обратной связи можно описать следующей последовательностью действий:
|
|
|
|
1) Ожидание запроса на сохранение обратной связи;
|
|
|
|
2) Получение запроса микросервисом «Gtable», отправка данных обратной связи, указанных в запросе, в заранее заготовленную таблицу Google;
|
| ... | ... | @@ -157,7 +155,7 @@ |
|
|
|
| /ping (GET) | Запрос, возвращающий пустую JSON строку. Используется в отладочных целях. Возвращает ответ HTTP со статусом 200 («Ok», «Успешно»). |
|
|
|
|
| /feedback (POST) | Запрос, сохраняющий обратную связь. В теле запроса должна находиться JSON строка. Корневой объект должен иметь ключи: «bot_answer» (ответ бота, результат поиска), «user_answer» (отзыв пользователя) и «user_info» (информация о пользователе). В случае успешного сохранения возвращает ответ HTTP со статусом 200 («Ok», «Успешно»). В случае ошибки в теле запроса возвращает ответ HTTP со статусом 400 («Bad request», «Неправильный, некорректный запрос»). |
|
|
|
|
|
|
|
|
### 2.1.2 Описание алгоритма и принципа работы микросервиса «Zulip bot»
|
|
|
|
## 2.4 Описание алгоритма и принципа работы микросервиса «Zulip bot»
|
|
|
|
Алгоритм работы чат бота представлен на рисунке.
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -165,6 +163,7 @@ |
|
|
|
В начале работы чат-бот читает файл с реквизитами. Затем запускается цикл ожидания сообщений. При поступлении сообщения чат-бот определяет тип сообщения. Если сообщение является обратной связью, бот вычленяет отзыв пользователя из сообщения, собирает информацию о пользователе и запоминает поисковой ответ. Далее бот отправляет информацию об обратной связи главному микросервису «Competence Search», а также отправляет сообщение пользователю об успешной отправке обратной связи. Если сообщение пользователя является командой, пользователю отправляется сообщение, содержащее справочную информацию. Если сообщение не является командой или сообщением обратной связи, бот классифицирует сообщение как поисковой запрос. После этого бот отправляет данное сообщение главному микросервису «Comptence Search». После получения ответа от главного микросервиса бот форматирует полученные данные и отправляет пользователю ответ. В конце всех операций бот возвращается в режим ожидания новых сообщений.
|
|
|
|
|
|
|
|
# 3 Подгрузка данных из сервисов и начальная предобработка
|
|
|
|
|
|
|
|
## 3.1 Загрузка данных Zulip и начальная предобработка
|
|
|
|
|
|
|
|
Для получения информации используется API Zulip. Полученный массив, включающий в себя темы, содержание сообщений и id авторов, записывается в текстовый файл. Далее этот файл поступает в модуль, взаимодействующий с моделью машинного обучения. В результате работы формируется рейтинг людей, которые участвовали в обсуждении определенной темы и которых сервис идентифицирует как экспертов в заданной области.
|
| ... | ... | @@ -227,14 +226,13 @@ |
|
|
|
В модель передаются три типа документов: текстовый массив с описанием каждого проекта, JSON-файл, в котором помещены данные с id проекта и соответствующему ему списком id участников, а также файл с информацией о компетенциях каждого пользователя Личного кабинета.
|
|
|
|
|
|
|
|
# 4 Размещение приложения на сервере
|
|
|
|
## 4.1 Описание различных конфигураций запуска
|
|
|
|
Для запуска программы необходимо перейти в корневую директорию проекта. В корневой директории находятся два файла: «docker-compose.yml» и «docker-compose.prod.yml». Для запуска приложения необходимо ввести команду **«docker-compose -f <имя_конфигурационного_файла> up --build -d»** в консоли, указав нужное имя файла в параметре.
|
|
|
|
|
|
|
|
Первый файл является конфигурационным файлом запуска приложения в тестовом режиме. В этом режиме извне доступны все микросервисы. Уровень логирования всех микросервисов установлен на режим DEBUG (показываются сообщения всех уровней логирования). В данной конфигурации логи печатаются как в консоль, так и в файл в директорию logs. Установлена ротация файлов – максимальное количество лог-файлов равно 5, а размер каждого файла не превышает 10 миллионов байт.
|
|
|
|
Второй файл является конфигурационным файлом запуска приложения в финальном режиме. В этом режиме извне доступен только главный микросервис «Competence Search», а также чат-бот. Уровень логирования всех микросервисов установлен на режим DEFAULT. В данной конфигурации в консоль печатаются логи уровня INFO и выше, а в файл в директории logs – сообщения уровня INFO и выше. Также установлена ротация файлов – максимальное количество лог-файлов равно 5, а размер каждого файла не превышает 10 миллионов байт.
|
|
|
|
|
|
|
|
О размещении приложения на сервере подробно описано [здесь](Руководство-администратора#3-запуск-приложения).
|
|
|
|
|
|
|
|
# 5 Описание процесса работы модели обработки данных Zulip и Wiki МИЭМ
|
|
|
|
# 5 Описание процесса работы тематических моделей
|
|
|
|
|
|
|
|
## 5.1 Описание работы тематической модели обработки данных Zulip и Wiki МИЭМ
|
|
|
|
|
|
|
|
Далее будут описаны основные методы и составляющие части библиотеки в том порядке, в котором они используются при инициализации модели и обработке данных.
|
|
|
|
|
|
|
|
Первым по порядку идет метод инициализации, выполняемый при создании модели. На этом этапе задаются основные параметры модели, её свойства и создаются важные внутренние переменные.
|
| ... | ... | |
