Взаимодействие сервисов LP

На схеме ниже для каждого сервиса указаны отдельные базы данных. Они приведены для наглядности. Не нужно запускать отдельный экземпляр БД для каждого сервиса. Можно запустить один экземпляр (например, PostgreSQL) и использовать его для хранения данных каждого из сервисов LP. У каждого сервиса будет своя таблица в этой базе данных.

См. раздел "Общие сведения" для подробной информации о базах данных, используемых сервисами LP.

Сервис API обеспечивает RESTful интерфейс для выполнения детекции лиц, извлечения и сравнения биометрических шаблонов.

Запросы отправляются в LP с помощью протокола HTTP. Стандартный механизм работы: внешний сервис отправляет запросы в LP, получает результаты и обрабатывает их в соответствии с заданными в запросе параметрами.

Всю информацию об основных запросах в API можно найти в спецификации OpenAPI.

Взаимодействие сервисов

Некоторые сервисы можно отключить (см. раздел "Общие сведения").

API получает запросы, обрабатывает их и проверяет авторизацию пользователя с помощью запроса к сервису Accounts (A0). Сервис Accounts проверяет наличие аутентификационных данных пользователя в базе данных Accounts (Acc1). Если данные пользователя не найдены в базе данных, то выдается ошибка авторизации. Если данные найдены, то соответствующая информация отправляется в сервис API, где тот передает исходные запросы в другие сервисы.

Основные операции (детекция, эстимация, извлечение, сравнение) выполняются нижеописанным образом.

Подход "Последовательное выполнение запросов":

• запрос "detect faces", в котором выполняется обнаружение лица, оценка параметров лица и создание биометрических образцов, отправляется из сервиса API в сервис Handlers (A1), а затем перенаправляются в сервис Remote SDK (H1);
• запрос "extract attributes", в котором выполняется извлечение временных атрибутов, отправляется из сервиса API в сервис Handlers (A1), а затем перенаправляется в сервис Remote SDK (H1);
• запрос "matching faces" отправляется из сервиса API в сервис Python Matcher (A6).

Подход "Параллельное выполнение запросов":

• запрос "create handler" с правилами детекции, эстимации, извлечения и матчинга лиц и тел отправляется из сервиса API в сервис Handlers (A1);
• запрос "generate events" отправляется из сервиса API в сервис Handlers (A1), а затем перенаправляется в сервис Remote SDK (H1)

Сервис API отправляет запросы в сервис Faces для создания/изменения новых лиц (запросы из секции "faces"), а также создания/изменения списков (запросы из секции "lists") (A2).

Сервис API получает информацию о текущих лицензионных условиях из сервиса Licenses (A3).

Сервис API отправляет биометрические образцы от внешних сервисов в сервис Image Store (запрос "save face/body sample") (A5).

Handlers создает новые обработчики и хранит их в базе данных Handlers (H2).

Также сервис перенаправляет запросы на детекцию и эстимацию в сервис Remote SDK (H1).

Сервис Handlers включается/отключается в настройке "ADDITIONAL_SERVICE_USAGE".

Remote SDK обрабатывает запросы на обнаружение лица/тела и создание атрибутов, оценивает параметры лиц/тел.

Сервис Remote SDK обрабатывает запрос на обнаружение лиц/тел и оценку параметров из сервиса Handlers (H1), отправляет результат обратно в Handlers (H1), который отправляет полученные биометрические образцы в сервис Image Store (H3).

Сервис Remote SDK обрабатывает запрос на создание атрибутов из сервиса Handlers (H1), запрашивая у сервиса Handlers существующие биометрические образцы, который тот запрашивает у сервиса Image Store (H3). Далее сервис Handlers отправляет созданные временные атрибуты в сервис Faces (H4), который хранит их в базе данных Redis (F1).

Запросы "/iso", "/sdk", "/liveness" выполняются напрямую к сервису Remote SDK (A9). В таком случае выполняется проверка лицензии с помощью взаимодействия с сервисом Licenses (RS1). Для возможности использования набора биометрических образцов, сервис Remote SDK взаимодействует с сервисом Image Store (RS2).

Image Store получает биометрические образцы из сервиса Remote SDK и хранит их на локальном накопителе или на S3-подобном облачном хранилище и предоставляет доступ к ним (Im1).

Сервис Image Store включается/отключается в настройке "ADDITIONAL_SERVICE_USAGE".

Faces отвечает за взаимодействие с базой данных Faces, которая хранит: лица, БШ лиц и списки (F2). Он дает доступ к сохраненным данным для сервисов API, Python Matcher и Tasks.

Faces также хранит созданные временные атрибуты в базе данных Redis (F1).

Каждый раз при создании нового лица, сервис Faces отправляет информацию о количестве созданных лиц с прикрепленными атрибутами в сервис Licenses (F3) (см. раздел "Максимальное количество лиц").

Events  хранит и предоставляет информацию о событиях. После создания события сервис Events получает созданное событие из сервиса Handlers (H6) и хранит его в базе данных Events (Ev1).

Использование сервиса Events можно включать и отключать в файле конфигурации сервиса API.

Python Matcher используется для сравнения биометрических шаблонов. Запрос на сравнение может быть отправлен напрямую сервисом АPI (A6). Если в обработчике указана политика сравнения, то запрос на сравнение БШ поступит из сервиса Handlers (H7). Python Matcher отправляет запросы на сравнение в базу данных Faces (M3) или Events (M1). Эти базы данных сравнивают биометрические шаблоны и отправляют результаты сравнения.

Python Matcher также может получать временные атрибуты, требуемые для сравнения, из базы данных Redis (M2).

Доступна возможность дополнительно использовать сервис Python Matcher Proxy, который может перенаправлять запросы либо сервису Python Matcher, либо плагинам сравнения. Плагины сравнения позволяют значительно ускорить выполнение запросов на сравнение (см. раздел "Плагины сравнения"). Данный сервис не отображен на схеме, но имеет те же линии связи, что и сервис Python Matcher.

Admin. Пользователь может управлять аккаунтами и выполнять другие действия через пользовательский интерфейс сервиса Admin (Adm1). Соответствующие запросы отправляются в сервис Admin (Adm2).

Сервис Admin получает информацию об аккаунтах из сервиса Accounts (Adm3).

Сервис Admin отправляет запросы в сервис Tasks (Adm4). Эти задачи выполняются для всех данных БД, а не только для отдельного ID аккаунта.

Сервис Admin получает информацию о текущих лицензионных условиях из сервиса Licenses (Adm5).

Сервис Admin получает количество лиц с привязанными атрибутами из базы данных Faces (Adm6) и подсчитывает процент заполненности базы данных.

Сервис Admin выполняет запросы ко всем сервисам LP, получая системную информацию (см. запрос "/luna_sys_info" в спецификации OpenAPI сервиса Admin) (Adm7).

Sender. Все созданные события передаются сервису Sender через канал БД Redis (H5). Внешние сторонние приложения подписываются на получение событий в соответствии с заданными фильтрами (Se2). Сервис Sender проверяет канал Redis, получает требуемую информацию и отправляет ее стороннему ПО (Se1).

Сервис Sender включается/отключается в настройке "ADDITIONAL_SERVICE_USAGE".

Configurator. Сервисы LP получают конфигурационные параметры из сервиса Configurator (Con1). Пользователь может управлять конфигурациями в сервисе Configurator посредством пользовательского интерфейса (Con2). Изменения отправляются в Configurator (Con3). Все изменения в конфигурационных файлах сохраняются в базе данных Configurator (Con4).

Сервис Configurator используется по умолчанию для каждого сервиса LUNA PLATFORM.

Tasks. Сервис Tasks получает запросы из сервиса API (A8). Далее Tasks создает и сохраняет задачу в базе данных Tasks (T1).

Далее сервис Tasks взаимодействует со своим "рабочим процессом" через Redis (T2, T3), создавая подзадачи и объединяя результаты. См. подробную информацию в разделе "Диаграммы задач".

Сервис Tasks получает данные из сервиса Faces для задач Clustering, Linker и Additional extraction (T4).

Сервис Tasks получает данные из сервиса Events для задач Clustering и Linker (T9, T10).

Сервис Tasks получает данные из сервиса Handlers для задачи Estimator (T6).

Сервис Tasks включается/отключается в настройке "ADDITIONAL_SERVICE_USAGE".

Взаимодействие "рабочих процессов" Tasks с другими сервисами зависит от типа задачи.

"Рабочие процессы" Tasks получают данные из сервиса Faces для каждой обрабатываемой задачи (T5).

"Рабочие процессы" Tasks отправляют запрос в Python Matcher (T7) для задач Clustering, Cross-matching и ROC-curve calculation.

"Рабочие процессы" Tasks хранят все отчеты в хранилище Image Store (T8). "Рабочие процессы" Tasks также хранят и получают кластеры из Image Store.

"Рабочие процессы" Tasks отправляют запрос для выполнения повторного извлечения биометрических шаблонов в сервис Handlers (T6).

Мониторинг. Система мониторинга получает запросы и ошибки от каждого сервиса (Mon1). Эти данные хранятся в базе данных Influx (Mon2). Затем данные мониторинга отправляются в Grafana для визуализации данных мониторинга (Mon3). Более подробную информацию о мониторинге можно найти в разделе "Мониторинг".

У сервисов Grafana и Influx DB есть собственные интерфейсы (см. раздел "Пользовательские интерфейсы").

Данная схема не содержит архитектуру сервисов Backport 3, Backport 4, Lambda и сервисов видеоаналитики (Video Agent и Video Manager). См. подробную архитектуру сервиса Backport 3 в разделе "Архитектура Backport 3" и сервиса Backport 4 в разделе "Архитектура Backport 4". См. диаграмму взаимодействия сервиса Lambda в разделе "Диаграммы lambda".