CC BY
0КОМПЬЮТЕРНЫЕ НАУКИ И ИНФОРМАТИКА
УДК 004.9
ОРГАНИЗАЦИЯ ВЗАИМОДЕЙСТВИЯ МЕЖДУ КОМПОНЕНТАМИ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ СИСТЕМЫ КОНТРОЛЯ И УПРАВЛЕНИЯ ДОСТУПОМ
Н.А. Иванова, А.М. Сотченков
ФГБОУ ВО «Брянский государственный университет имени академика И.Г. Петровского»
Данная статья посвящена вопросам проектирования и реализации брокера сетевых сообщений для построения взаимодействия между микросервисами системы контроля и управления доступом. В статье описаны основные механизмы сетевого взаимодействия, представлены шаги по реализации брокера сетевых сообщений. Для наглядности описаний приводятся схемы, примеры листингов. Ключевые слова: брокер сообщений, микросервисная архитектура, распределенные системы, сетевые сообщения, взаимодействие, микросервисы.
Микросервисная архитектура - это подход к разработке программного обеспечения, при котором приложение разбивается на небольшие независимые службы, так называемые микросервисы. Каждый микросервис выполняет отдельную функцию или сервис и взаимодействует с другими микросервисами через сетевые вызовы, обычно по API [1].
Можно отметить ряд преимуществ такой структуры системы. Прежде всего, это отказоустойчивость, поскольку микросервисы могут продолжать работу даже при отказе одного из них, что способствует общей надежности системы. Другим несомненным плюсом такой архитектуры является возможность масштабируемости компонентов системы: добавление, обновление или удаление тех или иных сервисов происходит независимо и не повлечет к нарушению работы других элементов и системы в целом.
Брокер сообщений играет ключевую роль в обеспечении взаимодействия между этими микросервисами. Использование брокера сообщений помогает улучшить гибкость, надежность и масштабируемость системы, особенно в распределенных архитектурах, где несколько компонентов должны обмениваться данными в реальном времени.
Архитектура разрабатываемой системы контроля и управления доступом к вычислительным ресурсам и программному обеспечению в рамках работы отдела компьютерных технологий ФГБОУ ВО «Брянский государственный университет им. ак. И.Г. Петровского» (БГУ) подразумевает взаимодействие его микросервисов с помощью брокера сообщений [2].
Брокер сообщений разрабатывался с учетом приказа Минцифры России от 18 января 2023 г. № 21 «Об утверждении Методических рекомендаций по переходу на использование российского программного обеспечения...» и совместим с отечественной операционной системой AstraLinux [3].
В контексте брокера сообщений взаимодействие между объектами (сообщение) и ресурсами (очередь сообщений) реализовано на базе протокола HTTP с использованием архитектурного стиля REST API (REpresentational State Transfer) для обмена сообщениями без сохранения состояний. Это позволяет обеспечить прежде всего независимость от языков программирования, используемых при создании компонентов системы или внешних компонентов, а также масштабируемость архитектуры системы.
Отправка HTTP-запросов с соответствующими методами (POST, GET, PUT, DELETE) дает возможность организовать взаимодействие с ресурсами брокера.
На рисунке 1 показан процесс создания новой очереди в брокере сообщений. Параметры PUT-запроса включают сведения о названии очереди (например, testing), а также необходимый предварительный объем выделяемой памяти (например, 100): http://localhost:7920/queue?name=testing&size=100. При положительном исходе будет выдан
код ответа «201 Created» или же «400 Bad Request» и «409 Conflict» в случае ошибок при передаче запроса (например, в случае создания уже имеющейся очереди).
"http://local.host:7920/queue?narae=testing&slze="
Брокер сообщений
201 Created
Ф
Приложение
"ok"; true,
"info": "The queue has been created", "name": "testing", "presize": 16©
Рис. 1. Создание новой очереди
Помимо создания именованных очередей реализованный брокер сообщений позволяет получить информацию о ранее созданных очередях. GET-запрос http://localhost:7920/queue () позволяет получить список имен, а GET-запрос http://localhost:7920/queue/testing - сведения о конкретной очереди (например, testing).
При необходимости очередь можно удалить, используя в отправляемом запросе метод DELETE (рис. 2): http://localhost:7920/queue?name={имя_очереди}. Ответ с кодом «200 ОК» будет получен, если очередь удалена, при отсутствии очереди с указанным в запросе именем клиент получит код «404 Not Found».
Рис. 2. Удаление очереди
Для отправки в брокер сообщения используется POST-запрос с указанием необходимой очереди (http://localhost:7920/msg?qname={имя_очереди}). Параметры очереди должны быть заданы в формате JSON (рис. 3).
Рис. 3. Отправка сообщения
Как и в случае успешного создания очереди подтверждение добавления нового сообщения сопровождается кодом «201 Created». Отсутствие указанной в запросе очереди или ошибка в структуре запроса приведет к выдаче кода «400 Bad Request» или «404 Not Found» с пояснениями ошибки.
Отправка GET-запроса (http://localhost:7920) позволяет получить сведения о брокере сообщений в JSON-формате: версия, тип лицензии, автор, расположение (рис. 4). Если очередь пуста, будет выдан ответ с кодом ошибки «404 Not Found».
Рис. 4. Получение сведений
Описанный стиль REST API дает возможность разрабатывать легко масштабируемую систему, которая будет готова к последующим улучшениям, обеспечивая при этом эффективный обмен сообщениями между их отправителями и получателями.
Реализация выполнялась на языке программирования общего назначения Go [4]. Такие преимущества как лаконичный и понятый синтаксис, статическая типизация, трансляция программы сразу в машинный код, поддержка многоядерных процессоров, кроссплатформен-ность делают язык наиболее подходящим для разработки брокера сообщений.
Потребовалось выполнить несколько последовательных этапов для непосредственной реализации брокера сетевых сообщений.
Изначально был создан репозиторий в системе контроля версий Git [5].
Затем был реализован пакет очереди сообщений с учетом принятой в сообществе разработчиков структуры проекта, в том числе конструктор создания экземпляр именованной очереди и методы размещения сообщений в циклическом списке (с учетом места в очереди) и получение сообщений из очереди.
В последствии был реализован API для взаимодействия с очередью и описанными методами. Далее был создан регистратор запросов к брокеру сообщений, необходимый для оценки его работы и отслеживания (регистрации) возникающих ошибок.
Платформа контейнеризации Docker была применена для автоматизации последующего развёртывания и работы брокера сообщений. Контейнеризация позволяет запускать брокер на отечественной операционной системе Astra Linux.
Для минимизации размера итогового образа использовалась многоступенчатая сборка. Готовый образ брокера имеет открытый исходный код и размещен в удалённом репозитории GitHub для всеобщего использования.
Каждый обработчик событий был подвержен модульному тестированию для обеспечения надёжности и корректности работы (рис. 5).
Проверка брокера подтвердила его функциональную работоспособность и позволила перейти в завершающему этапу - внедрению брокера сетевых сообщений в систему контроля и управления доступом информационного центра БГУ.
Running tool: /usr/local/go/bin/go test -benchmein -run=A$ -bench ABenchmarkPushM sgQueueSizelfi&G00$ github.com/sotchenkov/limero/internal/server/handlers
Running tool: /usr/local/go/bin/go test -benchmem -run=*$ -bench "BenchmarkPopMs gQueueSizel000&0$ github.com/sotchenkov/limerD/internal/server/hardlers
goos: linux goarch: amd64
pkg: github.com/sotchenkov/limero/interral/server/hardlers cpu: AMD Ryzen 5 35001 with Radeon Vega Mobile Gfx === run BenchmarkPopMsgqueueSizeieaeoa BenchmarkPopMsgQueLieSizelQ0000
BenchmarkPopMsgQueueSizel00000-8 413100 2689 ns/op
2397 B/op 19 allocs/op
PASS
ok github.com/sotchenkov/limero/internal/server/handlers 1.170s
goos: linux goarch: amdG4
pkg: github.com/sotchenkov/limero/internal/server/handlers cpu: AMD Ryzen 5 3500J with Radeon Vega Mobile Gfx === RUN BenchriarkPushMsgqueueSizel00000 BenchmarkPushMsgQueue5izel00000
BenchmarkPushMsgQueue5izel00000-8 78103 16362 ns/op
3068 B/op 31 allocs/op
PASS
ok github.com/sotchenkov/limera/internal/server/handlers 1.456s
Рис. 5. Оценка производительности при отправке и получении сообщений
Использование брокера сообщений в архитектуре системы контроля и управления доступом к ресурсам и программному обеспечению в организации в сочетании с микросервисами может повысить эффективность, надежность и гибкость системы, обеспечивая удобное взаимодействие между ее компонентами.
Список литературы
1. Ганьжа А. Ю. Карелова Р.А. Особенности микросервисной архитектуры событийно-ориентированных веб-приложений // Научное обозрение. Технические науки. - 2021. - № 6. -С. 28-34.
2. Иванова Н.А. Антоненко С.В., Сотченков А.М. Использование брокера сетевых сообщений для организации взаимодействия компонентов распределённых систем // Наука и образование: актуальные вопросы теории и практики: Материалы IV Международной научно-методической конференции, Оренбург, 26-27 марта 2024 года. - Самара-Оренбург: Самарский государственный университет путей сообщения, 2024. - С. 281-286.
3. Приказ Минцифры России № 21 «Об утверждении...» / [Электронный ресурс] // Министерство цифрового развития, связи и массовых коммуникаций РФ: [сайт]. - URL: https://digital.gov.ru/ru/documents/8755/ (дата обращения: 27.01.2024).
4. Build simple, secure, scalable systems with Go. - Текст: электронный // Go: [сайт]. -URL: https://go.dev/ (дата обращения: 13.02.2024).
5. Git: [сайт]. - URL: https://git-scm.com/ (дата обращения: 12.02.2024).
Сведения об авторах
Иванова Наталья Александровна - кандидат технических наук, доцент, доцент кафедры информатики и прикладной математики ФГБОУ ВО «Брянский государственный университет имени академика И.Г. Петровского», e-mail: ivanova_natala@mail.ru.
Сотченков Алексей Михайлович - студент 4 курса кафедры информатики и прикладной математики, ФГБОУ ВО «Брянский государственный университет имени академика И.Г. Петровского», e-mail: sotchenkoff@gmail.com.
ORGANIZATION OF INTERACTION BETWEEN THE COMPONENTS
OF THE MICROSERVICE ARCHITECTURE OF THE ACCESS CONTROL
AND MANAGEMENT SYSTEM
N.A. Ivanova, A.M. Sotchenkov
Bryansk State University named after Academician I.G. Petrovsky
This article is devoted to the design and implementation of a network message broker for building interaction between microservices of the access control and management system. The article describes the basic mechanisms of network interaction and presents the steps for implementing a network message broker. For clarity of descriptions, schemes and examples of listings are given.
Keywords: message broker, microservice architecture, distributed systems, network communications, interoperability, microservices.
References
1. Ganzha A.Yu., Karelova R.A. Features of microservice architecture of event-driven web applications // Scientific review. Technical science. - 2021. - No. 6. - P. 28-34.
2. Ivanova N.A. Antonenko S.V., Sotchenkov A.M. Using a network message broker to organize the interaction of components of distributed systems // Science and education: current issues of theory and practice: Materials of the IV International Scientific and Methodological Conference, Orenburg, March 26-27, 2024. - Samara-Orenburg: Samara State Transport University, 2024. - P. 281-286.
3. Order of the Ministry of Digital Development of Russia No. 21 "On approval..." / [Electronic resource] // Ministry of Digital Development, Communications and Mass Communications of the Russian Federation: [website]. - URL: https://digital.gov.ru/ru/documents/8755/ (date of access: 27.01.2024).
4. Build simple, secure, scalable systems with Go. - Text: electronic // Go: [site]. - URL: https://go.dev/ (access date: 13.02.2024).
5. Git: [site]. - URL: https://git-scm.com/(access date: 02/12/2024).
About authors
Ivanova N.A. - Ph.D. of Engineering Sciences, Associate Professor at the Department of Computer Science and Applied Mathematics, Bryansk State Academician I.G. Petrovski University, e-mail: ivanova_natala@mail.ru.
Sotchenkov A.M. - 4th year student at the Department of Computer Science and Applied Mathematics, Bryansk State Academician I.G. Petrovski University, e-mail: sotchenkoff@gmail.com.
