Digitable/Программная реализация некоторых сервисов в рамках создания роботизированной системы

Created Sat, 21 May 2022 22:23:06 +0300 Modified Mon, 01 Jun 2026 00:45:26 +0000
4196 Words

Программная реализация некоторых сервисов в рамках создания роботизированной системы

Содержание

  1. Введение
  2. Сбор функциональных требований
  3. Реализация системы
    3.1. Абстракция
    Постановка задачи
    Соотнесение задачи с абстракцией
    3.2. Реализация
    Маршрутизатор с технологией единого входа (single sign-on) Сервис распознавания лиц
    Сервис обработки пользовательских данных
  4. Производительность и развёртывание
  5. Заключение

Введение

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

Сбор функциональных требований

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

  1. Frontend (визуальная часть, пользовательский интерфейс) Для взаимодействия пользователя (клиента) с системой, предположительно на первых этапах, потребуется реализация пользовательского WEB-интерфейса в качестве альтернативной точки входа и регистрации в системе, а также для управления некоторыми настройками аккаунта.

Этот сервис реализует средства для взаимодействия с серверной частью по средствам протокола WebSocket.

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

  1. Маршрутизатор микросервисов

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

  1. Технология единого входа

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

  1. Face Recognition

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

Далее рассмотрим некоторые из этих сервисов с практической точки зрения и представим возможную их реализацию.

Реализация системы 1

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

Абстракция 2 3

Для понимания модели системы обратимся к облачным решениям и их моделям.

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

Посмотрим на некоторые из них:

IaaS (Infrastructure as a Service-Инфраструктура как Услуга)

Данная услуга является одной из самых распространенных в мире. Заключается она в предоставлении заказчику в аренду вычислительных ресурсов, в виде виртуальной инфраструктуры. В нее могут входить серверы, системы хранения данных, виртуальные коммутаторы и маршрутизаторы. Такая ИТ-инфраструктура является полноценной копией физической среды.

PaaS (Platform as a Service-Платформа как Услуга)

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

SaaS (Software as a Service-Программное обеспечение как Услуга)

Данная облачная услуга на данный момент считается самой распространенной в мире, так как пользуются ей практически все люди имеющие доступ в интернет. Заключается такая услуга в том, что клиент получает в свое распоряжение какие либо программные продукты посредством сети интернет. В качестве примера можно привести почтовый сервис Gmail, или, например, облачную версию 1С.

CaaS (Communications as a Service-Коммуникация как Услуга)

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

CaaS (Container as a Service-Контейнер как Услуга)

Данная услуга позволяет клиентам работать с контейнерами с помощью API облачного провайдера или специальной веб-панели.

DRaaS (Disaster Recovery as a Service-Аварийное Восстановление как Услуга)

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

BaaS (Backup as a Service-Резервное Копирование как Услуга)

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

BaaS (Backend as a Service-Бэкэнд как услуга)

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

DBaaS (Data Base as a Service-База Данных как Услуга)

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

MaaS (Monitoring as a Service-Мониторинг как Услуга)

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

DaaS (Desktop as a Service-Рабочий стол как Услуга)

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

STaaS (Storage as a Service-Хранилище как Услуга)

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

NaaS (Network as a Service-Сеть как Услуга)

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

ДИТ (Депортамент информационных технологий, традиционная IT модель)

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

В данном контексте модель нашей системы наиболее полно описывается SaaS моделью.

Постановка задачи

Постановка задачи состоит из составления технического задания и отправки его на реализацию.

Техническое задание — это результат обработки исходных (организационных, бизнес-) требований, их уточнения и перевода на системный/технический уровень.

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

Постановка на реализацию выполняется в рамках проектирования перед реализацией.

Техническое задание на разработку пользовательского интерфейса 4

  • Главная страница содержит

    • Шапка

      • Логотип (при клике должен весте на главную страницу)
      • Иконка пользователя (кнопка авторизации и аутентификации, если пользователь не опознан)
      • Кнопка меню (для мобильной версии)
      • Навигационное меню

    • Навигационное меню

      • Сервис распознавания лиц

    • Тело страницы

      • Контейнер для отображения страниц сервисов

    • Подвал страницы

      • Раздел авторов
      • Ссылки на репозитории проекта

    • Страница сервиса распознавания лиц

      • Специальный файловый инпут для загрузки фотографии
      • Информационный блок, в котором выводится статус обработки загруженного изображения

На стороне фронтенда используются технологии:

  • React.js - библиотека для написания фронтенда
  • TypeScript - язык, добавляющий типизацию и в целом расширяющий возможности языка JavaScript

Серверная часть:

  • Node.js - фреймворк для написания серверной части на языке JavaScript
  • TypeScript
  • Webpack - технология для сборки модулей приложения
Техническое задание на разработку сервиса распознавания лиц
  • Алгоритм
    • Распознавать человека по фотографии лица
  • Ввод/вывод
    • Загружать фотографию
    • Использовать камеру переферийного устройства

Сервис состоит только из серверной части. Основная технология базируется на языке Python3 и библиотеках для машинного обучения.

Техническое задание на разработку маршрутизатора для переключения между микросервисами приложения

Сценарий взаимодействия пользователя с маршрутизатором:

  1. Пользователь пытается получить доступ к защищённому ресурсу системы («sso-consumer» или SSO потребитель). Потребитель выясняет то, что пользователь не вошёл в систему, и перенаправляет пользователя на «сервер SSO» используя, в качестве параметра запроса, собственный адрес. На этот адрес будет перенаправлен пользователь, успешно прошедший проверку.
  2. SSO-сервер выясняет то, что пользователь в систему не вошёл, и перенаправляет его на страницу входа в систему
  3. Пользователь вводит имя пользователя и пароль, которые отправляются SSO-серверу в запросе на вход в систему.
  4. SSO-сервер аутентификации проверяет информацию пользователя и создает глобальную сессию между собой и пользователем. Тут же создаётся и токен авторизации. Токен представляет собой строку, состоящую из случайных символов. То, как именно генерируется эта строка, значения не имеет. Главное — это чтобы подобные строки у разных пользователей не повторялись, и чтобы такую строку сложно было бы подделать.
  5. SSO-сервер берёт токен авторизации и передаёт его туда, откуда к нему пришёл только что авторизовавшийся пользователь (то есть — передаёт токен потребителю SSO).
  6. Потребитель SSO получает токен и обращается к серверу SSO для проверки токена. Сервер проверяет токен и возвращает ещё один токен с информацией о пользователе. Этот токен используется потребителем SSO для создания сессии с пользователем. Такая сессия называется локальной.

Для реализации используем технологии:

  • Node.js
  • Express.js
  • JavaScript

Соотнесение задачи с абстракцией

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

Архитектура описывает видимую пользователем часть приложения и маршрутизатор в качестве связующего звена, которое передает управление внутренним сервисам системы. Описание внутренней части приложения позволяет создать потенциально неограниченное количество микросевисов. Мы представим реализацию сервиса распознавания лиц как внутреннюю часть системы. Каждый из возможных сервисов будет выглядеть в точности так же, поэтому реализация является достаточной.

Реализация

В этой главе рассмотрим реализацию сервисов по составленному ранее техническому заданию.

Маршрутизатор с использованием SSO (Single Sign-On)

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

SSO

Как и упоминалось ранее, технология единого входа (англ. Single Sign-On) — технология, при использовании которой пользователь переходит из одного раздела портала в другой, либо из одной системы в другую, не связанную с первой системой, без повторной аутентификации.

Single Sign-On можно разделить на два основных вида технологий единого входа:

  1. Корпоративный (Enterprise) Single Sign-on, подразумевающий установку агента на рабочие станции пользователей, который обеспечивает автоматическую подстановку в аутентификационные окна приложений логина и пароля пользователя.

  2. Web Single Sign-on, обеспечивающий функции аутентификации в web-приложениях. Эта технология предоставляет единый сервис аутентификации (провайдер) для подключенных приложений организации с поддержкой таких протоколов, как SAML, OAuth и OpenID. При этом для доступа ко всем приложениям используется одна учетная запись.

Существует несколько реализаций данной технологии, например:

Kerberos 5

После успешной первичной аутентификации центр распределения ключей (Key Distribution Center, KDC) выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). В качестве примера реализации протокола Kerberos можно отметить доменную аутентификацию пользователей в операционных системах Microsoft, начиная с Windows 2000.

Смарт-карты и токены

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

OpenID Connect 6

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

К основным преимуществам технологии единого входа относятся:

  • уменьшение парольного хаоса между различными комбинациями имени пользователя и пароля
  • уменьшение времени на повторный ввод пароля для одной и той же учётной записи
  • поддержка традиционных механизмов аутентификации, таких как имя пользователя и пароль
  • снижение расходов на IT-службу за счёт уменьшения количества запросов по восстановлению забытых паролей
  • обеспечение безопасности на каждом уровне входа/выхода/доступа к системе без причинения неудобств пользователям

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

Среди недостатков можно выделить следующие:

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

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

Реализуем сценарий, описанный в ТЗ.

Шаг 1
const isAuthenticated = (request, response, next) => {
  const redirectURL = `${req.protocol}://${req.headers.host}${req.path}`;
  if (req.session.user == null) {
    return res.redirect(
      `https://exampleurl.ru:3000/sso/login?serviceURL=${redirectURL}`
    );
  }
  next();
};

module.exports = isAuthenticated;

На данном этапе представлена функция проверки того, аутентифицирован ли пользователь. Если пользователь прошел проверку успешно, серверу передается текущий URL в качестве того, на который должен быть перенаправлен пользователь. В противном случае, пользователь будет перенаправлен на SSO-сервер для аутентификации.

Шаг 2
const login = (request, response, next) => {
  const { serviceURL } = req.query;

  if (serviceURL != null) {
    const url = new URL(serviceURL);
    if (alloweOrigin[url.origin] !== true) {
      return res
        .status(400)
        .json({ message: "Your are not allowed to access the sso-server" });
    }
  }
  if (req.session.user != null && serviceURL == null) {
    return res.redirect("/");
  }

  if (req.session.user != null && serviceURL != null) {
    const url = new URL(serviceURL);
    const intrmid = encodedId();
    storeApplicationInCache(url.origin, req.session.user, intrmid);
    return res.redirect(`${serviceURL}?ssoToken=${intrmid}`);
  }

  return res.render("login", {
    title: "SSO-Server | Login"
  });
};

SSO-сервер определяет, что пользователь не зашел в систему и перенаправляет его на страницу входа.

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

const alloweOrigin = {
"https://exampleurl.ru:3001": true,
"https://exampleurl.ru:3002": true,
"https://exampleurl.ru:3003": true,
"https://exampleurl.ru:3004": fasle,
};
Шаг 3

Пользователь вводит имя пользователя и пароль, которые отправляются SSO-серверу в запросе на вход в систему.

Шаг 4

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

Шаг 5

SSO-сервер передает токен от пользователя потребителю SSO.

const doLogin = (request, response, next) => {
  const { email, password } = req.body;
  if (!(userDB[email] && password === userDB[email].password)) {
    return res.status(404).json({ message: "Invalid email and password" });
  }

  const { serviceURL } = req.query;
  const id = encodedId();
  req.session.user = id;
  sessionUser[id] = email;
  if (serviceURL == null) {
    return res.redirect("/");
  }
  const url = new URL(serviceURL);
  const intrmid = encodedId();
  storeApplicationInCache(url.origin, id, intrmid);
  return res.redirect(`${serviceURL}?ssoToken=${intrmid}`);
};

Выполняем проверку адреса электронной почты и пароля. В даннос случае userDB есть условный объект пользовательской базы данных. Не будем заострять на этом внимание, так как этот объект выполняет роль интерфейса.

  • Данный токен является промежуточным, он используется для получения другого токена.
  • Если использовать JWT(JSON Web Token) в роли промежуточного токена, то не нужно включать в его состав важные или секретные данные, так как это может повлечь за собой утечку данных.
Шаг 6

Потребитель SSO получает токен и обращается к серверу SSO для проверки токена, после чего получает токен с информацией пользователя для создания локальной сессии между потребителем SSO и пользователем.

Опишем промежуточный слой, используемый потребителем SSO. Построим на основе библиотеки Express.

const ssoRedirect = () => {
  return async function(request, response, next) {
    const { ssoToken } = req.query;
    if (ssoToken != null) {
      const redirectURL = url.parse(req.url).pathname;
      try {
        const response = await axios.get(
          `${ssoServerJWTURL}?ssoToken=${ssoToken}`,
          {
            headers: {
              Authorization: "Authorization header"
            }
          }
        );
        const { token } = response.data;
        const decoded = await verifyJwtToken(token);
        req.session.user = decoded;
      } catch (err) {
        return next(err);
      }

      return res.redirect(`${redirectURL}`);
    }

    return next();
  };
};

Если токен проходит проверку сервером SSO, то он считается действительным.

В данном случае сервер SSO при положительном сценарии возвращает подписанный JWT с информацией о пользователе.

const verifySsoToken = async (request, response, next) => {
  const appToken = appTokenFromRequest(req);
  const { ssoToken } = req.query;
  if (
    appToken == null ||
    ssoToken == null ||
    intrmTokenCache[ssoToken] == null
  ) {
    return res.status(400).json({ message: "badRequest" });
  }

  const appName = intrmTokenCache[ssoToken][1];
  const globalSessionToken = intrmTokenCache[ssoToken][0];
  if (
    appToken !== appTokenDB[appName] ||
    sessionApp[globalSessionToken][appName] !== true
  ) {
    return res.status(403).json({ message: "Unauthorized" });
  }
  const payload = generatePayload(ssoToken);

  const token = await genJwtToken(payload);
  delete intrmTokenCache[ssoToken];
  return res.status(200).json({ token });
};

В коде присутствует проверка кеша на наличие ssoToken. Так как его отсутствие говорит о попытке обмана системы. Дальше проверяется действительность токена и проверка на генерацию нового, после чего из кеша удаляется старый ключ.

Для лучшей бозопасности можно определить некоторые политики безопасности:

  1. На сервере SSO необходимо зарегистрировать все сервисы системы, которые будут использовать сервер для аутентификации.
  2. Для защиты каждого приложения можно сгенерировать для каждого из них специальные публичные и приватные rsa-ключи, которыми сервисы будут верифицировать JWT.

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

const userDB = {
  "info@exampleurl.com": {
    password: "test",
    userId: encodedId(),
    appPolicy: {
      sso_consumer: { role: "admin", shareEmail: true },
      simple_sso_consumer: { role: "user", shareEmail: false }
    }
  }
};
Централизованный выход из системы

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

  1. Существование локальной сессии подразумевает существование глобальной сессии, но обратное не обязательно верно.
  2. При уничтожении локальной сессии влечет также уничтожении и глобальной сессии.

Таким образом мы описали одну из реализаций маршрутизатора с использованием SSO.

Сервис для распознавания лиц 7 8 9 10

Ранее мы описывали принцип работы алгоритмов распознавания лиц. Напомним, что эта задача - частный случай проблемы машинного зрения.

Учитывая особенности синтаксиса языка, пояснения кода оставим в виде комментариев.

from stop_face_recognition import camera_break

import face_recognition
import cv2
import numpy as np

video_capture = cv2.VideoCapture(0)

# Загрузим изображение и обучим систему для его распознавания 
image = face_recognition.load_image_file("./photos/example.jpg")
face_encoding = face_recognition.face_encodings(image)[0]

# Создадим массивы известных сигнатур и их сопоставлений с реальными людьми
known_face_encodings = [
    face_encoding,
]
known_face_names = [
    "user_name",
]

# проинициализируем необходимые переменные
face_locations = []
face_encodings = []
face_names = []
process_this_frame = True

while True:
    # вычленим отдельный кадр из видео
    ret, frame = video_capture.read()

    # сожмем изображение в 4 раза для ускорения распознавания
    small_frame = cv2.resize(frame, (0, 0), fx=0.25, fy=0.25)

    # конвертируем изображение из BGR color (для OpenCV пользователей) в RGB color (для face_recognition пользователей)
    rgb_small_frame = small_frame[:, :, ::-1]

    # для повышения производительности обрабатываем через кадр
    if process_this_frame:
        # найдем все лица на видео
        face_locations = face_recognition.face_locations(rgb_small_frame)
        face_encodings = face_recognition.face_encodings(rgb_small_frame, face_locations)

        face_names = []
        for face_encoding in face_encodings:
            # сопоставляем найденое лицо с известным
            matches = face_recognition.compare_faces(known_face_encodings, face_encoding)
            name = "Unknown"

            # приближенно сопоставим найденой лицо с уже известным
            face_distances = face_recognition.face_distance(known_face_encodings, face_encoding)
            best_match_index = np.argmin(face_distances)
            if matches[best_match_index]:
                name = known_face_names[best_match_index]

            face_names.append(name)

    process_this_frame = not process_this_frame


    # отобразим результат
    for (top, right, bottom, left), name in zip(face_locations, face_names):
        top *= 4
        right *= 4
        bottom *= 4
        left *= 4

        # отобразим обводку найденного лица
        cv2.rectangle(frame, (left, top), (right, bottom), (0, 0, 255), 2)

        # отобразим метку для найденного лица
        cv2.rectangle(frame, (left, bottom - 35), (right, bottom), (0, 0, 255), cv2.FILLED)
        font = cv2.FONT_HERSHEY_DUPLEX
        cv2.putText(frame, name, (left + 6, bottom - 6), font, 1.0, (255, 255, 255), 1)

    # отобразим полученное изображение
    cv2.imshow('Video', frame)

    # клавиша "q" завершает работу алгоритма
    camera_break()

video_capture.release()
cv2.destroyAllWindows()

Сервис обработки пользовательских данных

Данный сервис служит для упрощения взаимодействия пользователей с системой. Рассмотрим, как именно реализуется пользовательский интерфейс. Приложение будет построено с использованием React.js библиотеки. Основной функционал будет состоять из некоторых форм и прослойки взаимодействия с маршрутизатором.

Для упрощения понимания создадим каждый компонент в виде отдельного приложения.

Для загрузки файла изображения будем использовать файловый инпут.


class FileInput extends React.Component {
  constructor(props) {
    super(props);
    this.handleSubmit = this.handleSubmit.bind(this);
    this.fileInput = React.createRef();
  }
  handleSubmit(event) {
    event.preventDefault();

    // В этом месте можно разместить функцию отправки изображения на сервер и иную необходимую логику

  }

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <label>
          Upload file:
          <input type="file" ref={this.fileInput} />
        </label>
        <br />
        <button type="submit">Submit</button>
      </form>
    );
  }
}

ReactDOM.render(
  <FileInput />,
  document.getElementById('root')
);

Форма авторизации может выглядеть такием образом

class Reservation extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      login: '',
      password: ''
    };

    this.handleInputChange = this.handleInputChange.bind(this);
  }

  handleInputChange(event) {
    
// В этом месте необходимо обратотать логику обработки данный и дальнейшей отправки на сервер
    
  }

  render() {
    return (
      <form>
        <label>
          Login
        <input
            name="numberOfGuests"
            type="number"
            value={this.state.login}
            onChange={this.handleInputChange} />
        </label>
        <br />
        <label>
          Password
          <input
            name="numberOfGuests"
            type="number"
            value={this.state.password}
            onChange={this.handleInputChange} />
        </label>
      </form>
    );
  }
}


const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<Reservation />);

Показаных выше компонентов в теории достаточно для реализации минимального пользовательского интерфейса. Теперь покажем как может выглядеть функция отправки запроса на сервер


    fetch("https://api.example.com")
      .then(res => res.json())
      .then(
        (result) => {
         
          // в этом месте нужно обрабатывать ответ от сервера

        },
        (error) => {
         
          // в этом месте нужно обработать возможные ошибки
          // сам способ обработки зависит от конкретного запроса

          });
        }
      )

Из представленного выше программного кода важно понять, что по идее все взаимодействия пользователей с системой сводятся к простейшим функциям

Производительность и развёртывание

Непрерывная интеграция

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

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

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

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

Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании, поскольку конечная цель — разработка качественных приложений. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в CI/CD-конвейере.

Зрелая практика CI/CD позволяет реализовать непрерывное развертывание: при успешном прохождении кода через CI/CD-конвейер, сборки автоматически развертываются в продакшн-окружении. Команды, практикующие непрерывную поставку, могут позволить себе ежедневное или даже ежечасное развертывание. Хотя здесь стоит отметить, что непрерывная поставка подходит не для всех бизнес-приложений.

Непрерывное развертывание

Непрерывная поставка — это автоматическое развертывание приложения в целевое окружение. Обычно разработчики работают с одним или несколькими окружениями разработки и тестирования, в которых приложение развертывается для тестирования и ревью. Для этого используются такие CI/CD-инструменты как Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI.

Типичный CD-конвейер состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:

  • Получение кода из системы контроля версий и выполнение сборки.
  • Настройка инфраструктуры, автоматизированной через подход “инфраструктура как код”.
  • Копирование кода в целевую среду.
  • Настройка переменных окружения для целевой среды.
  • Развертывание компонентов приложения (веб-серверы, API-сервисы, базы данных).
  • Выполнение дополнительных действий, таких как перезапуск сервисов или вызов сервисов, необходимых для работоспособности новых изменений.
  • Выполнение тестов и откат изменений окружения в случае провала тестов.
  • Логирование и отправка оповещений о состоянии поставки.

Реализация CI/CD-конвейеров с Kubernetes и бессерверными архитектурами

Многие команды, использующие CI/CD-конвейеры в облаках используют контейнеры, такие как Docker, и системы оркестрации, такие как Kubernetes. Контейнеры позволяют стандартизировать упаковку, поставку и упростить масштабирование и уничтожение окружений с непостоянной нагрузкой.

Архитектура бессерверных вычислений представляет собой еще один способ развертывания и масштабирования приложений. В бессерверном окружении инфраструктурой полностью управляет поставщик облачных услуг, а приложение потребляет ресурсы по мере необходимости в соответствии с его настройками. Например, в AWS бессерверные приложения запускаются через функции AWS Lambda, развертывание которых может быть интегрировано в CI/CD-конвейер Jenkins с помощью плагина.

Заключение

В заключение скажем, что нам удалось в полной мере решить поставленную задачу и показать, что архитектура, показанная ранее, работоспособна и имеет ряд преимуществ. В связке с оркестровщиком и ci/cd конвейером разработчик способен абстрагироваться от процесса развертывания приложения и предупредить человеческий фактор. Мы описали необходимые сервисы, которых достаточно для реализации архитектуры. Установили связь между абстракцией и реальной задачей. Составили техническое задание и представили реализацию приложения. Описали модель в контексте облачных вычислений и показали различия между их реализациями и ценность для бизнеса.

Список литературы

  1. Основы теории вычислительных систем / Под ред. С. А. Майорова. -М.: Высшая школа, 1978. ↩︎

  2. Батура Т.В., Мурзин Ф.А., Семич Д.Ф. Software & Systems Программные продукты и системы // Облачные технологии: основные модели, приложения, концепции и тенденции развития Сборник. - 2014. - №3 (107). ↩︎

  3. Tsvetkov У^а. Information interaction // European Researcher. 2013. Vol. 62. Is. 11-1. ↩︎

  4. Goldsmith Kevin. Microservices at Spotify. –– 2015. –– International software development conference «GOTO Berlin». Режим доступа: https://www.kevingoldsmith.com/talks/microservices-at-spotify.html. ↩︎

  5. RFC4120 – The Kerberos Network Authentication Service (V5) // (спецификации) https://datatracker.ietf.org/doc/html/rfc4120 (дата обращения 01.05.2022) ↩︎

  6. RFC4556 – Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) // (спецификации) https://www.ietf.org/rfc/rfc4556.txt (дата обращения 01.05.2022) ↩︎

  7. документация по языку программирования python // (интернет ресурс) https://docs.python.org/3/ (дата обращения 01.05.2022) ↩︎

  8. документация по библиотеке numpy языка python // (интернет ресурс) https://pythonworld.ru/numpy/1.html (дата обращения 01.05.2022) ↩︎

  9. A.J. Goldstein, L.D. Harmon, A.B.Lesk, “Identification of Human Faces”, Proc. IEEE, May 1971, Vol. 59, No. 5, 748-760. ↩︎

  10. T.F. Cootes and C.J. Taylor and D.H. Cooper and J. Graham (1995). “Active shape models - their training and application”. Computer Vision and Image Understanding (61): 38-59. ↩︎

Комментарии