На сегодняшний день существует множество подходов к созданию информационных систем, отличающихся принципами, фокусом на отдельных составляющих их предметной области, а также способами взаимодействия компонентов. Это обусловлено многообразием решаемых задач и особенностями эксплуатации систем.
В условиях активного внедрения информационных технологий в деятельность компаний к системам предъявляются повышенные требования к скорости работы, безопасности и устойчивости к высоким нагрузкам. Помимо этого, постоянно меняющиеся тренды вынуждают компании предлагать новые и уникальные услуги, тем самым создавая необходимость постоянно дорабатывать свои информационные системы. Именно поэтому в настоящее время акцент при проектировании делается на уменьшение связанности их составляющих, в следствие чего концепция разделения системы на сервисы и выстраивания их взаимодействия получила широкое распространение. Наиболее известной реализацией такой концепции является сервис-ориентированная архитектура (SOA), или же конкретная её разновидность — микросервисная архитектура, отличающаяся от SOA общесистемной стандартизацией способов взаимодействия составляющих систем и возможностью масштабирования за счёт быстрого запуска копий сервисов [1].
В микросервисной архитектуре каждый сервис отвечает за выполнение определенных бизнес-функций, связанных с некоторым элементом предметной области или группой связанных процессов. Безусловно, при проведении большинства процессов в системе, где ответственность разделена, возникает необходимость в межкомпонентном, или говоря иначе, межсервисном взаимодействии. К примеру, обработка заказа в книжном магазине после выбора покупателем позиции к приобретению требует выполнения нескольких процессов — выставление счёта, проведение оплаты и выдача доступа к приобретенному экземпляру после проверки факта оплаты. В дополнение, на почту клиенту может потребоваться отправка чека, что в отношении самого процесса является неприоритетной задачей, но обязательной в соответствии с требованиями законодательства. Именно поэтому существует несколько способов межсервисного взаимодействия в системах. Часто можно наблюдать их комбинацию, так как в рамках процесса одним задачам требуется выполнение действий сторонним сервисом практически мгновенно (синхронно), а другим достаточно выполнения с задержкой (асинхронно).
Наиболее популярным инструментом для организации асинхронного взаимодействия является брокер сообщений. Это специальный программный компонент, который работает по модели «издатель-подписчик». Сервис-издатель публикует некоторое сообщение о событии, а сервис-подписчик реагирует на него в зависимости от определенных в нём бизнес-правил. Бесспорным преимуществом такого компонента является возможность хранения им сообщений, пока они не будут прочитаны потребителем. К тому, же в отличии от синхронной реализации, например, через оповещение о событиях посредством REST API, это позволяет гибко масштабировать систему — добавлять новые узлы-обработчики, что является одним из методов противостояния высоким нагрузкам, или же с минимальными затратами на разработку модифицировать отдельные сервисы, что бывает удобно в системах, которые работают как в «облаке», так и распространяются в коробочном исполнении. Однако использование брокера в системе требует высокой квалификации сопровождающей её персонала, так как только при грамотной настройке будет гарантироваться корректная маршрутизация и низкий процент потерянных сообщений. Это делает их использование в небольших, но нагруженных системах нецелесообразным. К тому, же централизация в такой модели может стать точкой отказа. Конечно, современные брокеры сообщений имеют возможность объединения их в кластеры, однако для небольших систем это становится избыточным.
Исследуя профильное направление компьютерных наук, занимающееся передачей данных, а именно технологий систем связи и компьютерных сетей, можно подметить один из способов передачи данных — многоадресное вещание. Такой способ позволяет эффективно передавать данные множеству получателей одновременно за счёт отправки одной копии потока. Для сравнения стоит сказать, что в случае с одноадресной передачей для каждого получателя создаётся своя копия потока, из‑за чего суммарная нагрузка на источник и сеть линейно растёт с числом клиентов. В качестве еще одного аргумента в пользу многоадресного вещания можно привести возможность управления доставкой потока сетевыми устройствами за счёт протокола IGMP (Internet Group Management Protocol), что избавляет источник данных от необходимости управлять доставкой, а нативная поддержка сетевым стеком операционных систем на базе ядра Linux упрощает использование такого способа передачи данных при разработке прикладных решений [2].
Выполним построение прототипа информационной системы, состоящей из двух сервисов — сервиса задач и сервиса почтовых уведомлений, обменивающихся сообщениями о произошедших в них событиях при помощи многоадресного вещания при проведении некоторого бизнес-процесса создания и делегации задачи. Реализацию сервисов выполним на языке Python с использованием библиотеки multicast. Данная библиотека позволяет отправлять и получать сообщения по сети посредством многоадресной рассылки , используя возможности сетевого стека операционной системы на ядре Linux [3]. На рис. 1–2 представлены листинги исходного кода сервисов.
Рис. 1. Листинг исходного кода сервиса задач с функциями отправки и получения сообщений посредством многоадресного вещания
Рис. 2. Листинг исходного кода сервиса почтовых уведомлений с функциями отправки и получения сообщений посредством многоадресного вещания
Программы используют многопоточность для разделения задач отправки и обработки получаемых сообщений. После запуска программы сервиса задач выполняется создание задачи посредством функции task_create() , в которой также вызывается функция publisher(), отправляющей сообщение «Task was created successfully» в сеть по адресу многоадресного вещания 224.0.0.1 . Запущенная программа сервиса почтовых уведомлений прослушивает данный адрес и при поступлении сообщений начинает их обработку — выполняет чтение сообщения и запуск соответствующего бизнес-сценария. В данном примере таким сценарием является отправка оповещения на почту посредством функции send_mail() и публикация сообщения « Email was sent successfully » в сеть по адресу многоадресного вещания 224.0.0.1. В сервисе задач также задано правило обработки события отправки письма, и поэтому при получении данного сообщения из сети сервис задач выполняет бизнес-сценарий делегации задачи, реализованной в функции task_delegate() . На рис. 3. представлено логирование обмена сообщениями и отработки бизнес-сценариев сервисами.
Рис. 3. Логирование обмена сообщениями и отработки бизнес-сценариев сервисами
Нельзя не упомянуть о главном недостатке подобного исполнения — потеря сообщений при недоступности получателя. Дело в том, что многоадресное вещание изначально разрабатывалось для сервисов реального времени — например, IPTV (Internet Protocol Television) и сохранение состояния не было предусмотрено осознано. Одним из решений данной проблемы, вызванной ограничением многоадресного вещания, может стать добавление кэширующих компонентов в составе сервиса-подписчика (рис. 4). При недоступности всех экземпляров сервиса-подписчика сообщения принимаются кэширующим компонентом сервиса и при восстановлении работоспособности первый экземпляр сервиса выполняет обработку имеющихся в кэше данных.
Рис. 4. Схема обмена сообщениями при использовании кэширующего компонента
Подводя итог, можно предположить, что концепция использования многоадресного вещания имеет место быть при создании небольших, но нагруженных или аппаратно-разделенных информационных систем за счёт своей эффективности и простоты реализации. В дополнение можно сказать, что создаваемые информационные системы с применением многоадресного вещания как способа взаимодействия между их составляющими могут быть включены в состав автоматизированных систем предприятия, реализующих технологические процессы, так как некоторые программируемые логические контроллеры умеют получать данные, передаваемые многоадресным вещанием.
Литература:
1. SOA vs. Микросервисы: в чём отличия. — Текст: электронный // Джеймикс: [сайт]. — URL: https://www.jmix.ru/tech-hub/soa-vs-mikroservisy/ (дата обращения: 19.07.2026).
2. IP Multicast Routing Technology Overview. — Текст: электронный // Cisco Systems: [сайт]. — URL: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/ 17–1/configuration_guide/ip_mcast_rtng/b_171_ip_mcast_rtng_9300_cg/ip_multicast_routing___technology_overview.pdf (дата обращения: 19.07.2026).
3. Multicast Python Module. — Текст: электронный // PyPI: [сайт]. — URL: https://pypi.org/project/multicast/ (дата обращения: 19.07.2026).
