Обмен сообщениями
Представим ситуацию, сегодня день получения зарплаты, вы приходите в кассу, а кассира нет на месте. Вы сможете получить зарплату только в том случае, если кассир будет на месте и будет свободным в момент вашего прихода, а так же будет необходимая сумма в кассе предприятия. Это является отличным примером синхронного взаимодействия. Привнесение в эту систему «заявок на выплату», которые утверждаются, а также фиксируют время, когда необходимо обратится в кассу делает эту систему асинхронной. Это намного проще, чем пытаться приходить к кассе вновь и вновь. «Сохранение» намерения получить зарплату в виде сообщения («заявка на выплату») и помещение его в очередь для последующей обработки наглядно иллюстрирует сущность обмена сообщениями.
Обмен сообщениями — это технология высокоскоростного асинхронного взаимодействия между программами с гарантией доставки информации. Программы взаимодействуют между собой обмениваясь сообщениями.
Система обмена сообщениями — это некоторый программный комплекс, который обеспечивает хранение и передачу двоичных данных (в большинстве случаев) между различными участниками системы. Использование системы обмена сообщениями обладает такими важными преимуществами:
- независимость взаимодействующих приложений через общий интерфейс;
- экономия и рациональное использование ресурсов;
- надежность, благодаря возможности накапливать сообщения, а так же благодаря независимости компонентов;
- возможность доставки сообщений, после сбоя одного из компонентов после “восстановления”;
- гарантия доставки сообщения.
Канал или очередь — это логический маршрут, объединяющий программы и использующийся для транспортировки сообщений, он также напоминает массив сообщений, который доступный для многих приложений одновременно. Приложения, объединенные с помощью технологии обмена сообщениями, передают данные по каналам сообщений. Изначально система обмена сообщениями не содержит каналов, они создаются по мере определения потребностей.
Сообщение — это наименьшая единица данных, которая может быть передана по каналу сообщений. Для передачи данных отправитель должен разбить их на пакеты, которые затем будут упакованы в сообщения и помещены в канал. Обычно сообщение состоит их двух основных частей:
- Заголовок сообщения содержит информацию для выполнения адресации в системе обмена сообщениями;
- Тело сообщения содержит полезные данные и как правило игнорируются системой обмена сообщениями.
Отправитель или поставщик — программа, отправляющая сообщение путем его размещения в канале.
Получатель или потребитель — программа, получающая сообщение путем его считывания из канала и удаляет это сообщение на определенном этапе (обычно после считывания).
Функционирование обмена сообщениями обеспечивается отдельной программной системой — системой обмена сообщениями (message-oriented middleware). Необходимость наличия такой системы обусловлена ненадежностью сетей, различные сбои, необходимостью ускорения процесса принятия решений (итоговое решение формируется из нескольких источников, например: система управления складом, финансовая система, система доставки и другие.). Процедура передачи сообщения состоит из 5 основных этапов:
- Создание сообщения;
- Отправка сообщения;
- Доставка сообщения;
- Получение сообщения;
- Обработка сообщения.
«Отправить и забыть» (Send and forget) — поместив сообщение в канал (этап 2), отправитель может не заботится о судьбе сообщения, доставку обеспечит система обмена сообщениями.
Преимущества обмена сообщениями
- Обмен сообщениями позволяет наладить взаимодействие между приложениями. Можно конечно возразить, что все инструменты есть в платформе 1С, но не один не гарантирует доставку;
- Интеграция разнородных систем и технологий. Использовать для все и вся платформу 1С очень плохая идея, при том, что быстродействие платформы низкое, а масштабирование — дорогое;
- Взаимодействия между приложениями происходят асинхронно. Для платформы 1С так же верно, пока не закончатся лицензии на подключение;
- При синхронном взаимодействии отправитель должен дождаться завершения обработки вызова получателем прежде, чем сделать новый вызов. Таким образом, если посмотреть на пример в начале статьи, у касс не будет очередей при использовании «заявок на выплату». Асинхронное взаимодействие позволяет размещать и обрабатывать вызовы с разной скоростью. Другими словами можно балансировать лицензиями на подключение к «1С:Предприятие 8», можно балансировать нагрузку на сервер 1С, создать кэширование на уровне очереди и т. п.;
- Возможность балансирования нагрузки, система обмена сообщениями формирует очередь запросов, позволяя получателю контролировать скорость их обработки;
- Надежное взаимодействие между системами;
- Возможность работы без подключения к сети, например, торговые агенты, которые периодически выполняют синхронизацию с сервером;
- Приложение может быть интегрировано с множеством приложений используя только — систему обмена сообщениями;
- Асинхронное взаимодействие позволяет приложению не ожидать результата выполнения задачи другим приложением, когда задача будет выполнена, приложение может быть оповещено о результатах.
Недостатки обмена сообщениями
- Довольно сложная реализация;
- Довольно сложно отлаживать и тестировать;
- Порядок доставки сообщений неизвестен. Необходимо дополнительно восстанавливать порядок сообщений, если он необходим;
- Дополнительные задержки при использовании обмена сообщениями, в сравнении с использованием прямого вызова приложения;
- Ограниченная поддержка закрытыми, старыми (legacy) системами.
История реального проекта
- 2009 год. В организации возникла потребность работать с товарами под заказ, для этого конфигурацию необходимо было научить, как-то, работать с прайсами. Поставщиков было немного до 15, да и прайсы у всех были *.xls и в принципе одинаковые. Было внедрено решение которое позволяло загружать информацию в ручном режиме, искать соответствия и устанавливать цены поставщиков;
- 2011 год. Количество поставщиков выросло и прайсы стали различаться, а так же добавились новые форматы. Появились конкуренты и их тоже необходимо было анализировать. Чем быстрее начнешь понимать ситуацию и сформируешь картину рынка тем выгоднее или быстрее продашь товар. Система загрузки стала автоматической и прайсы загружались периодически один раз в час. Довольно смешно было наблюдать картину, когда продавцы из конкурирующего магазина прибегали в наш магазин и записывали цены, а потом они у себя снижали цену, а максимум через час у нас цена становилась меньше, но не ниже себестоимости. Так появилась система парсинга интернет сайтов конкурентов;
- 2013 год. Первые проблемы. Прайсов стало больше и за один час они не успевали попасть в базу за выделенное время. Решено было апгрейдом сервера 2 процессора по 20 ядер и 128 ГБ ОЗУ;
- 2024 год. Прайсы стали очень большими, некоторые по 100 тыс. позиций, да и магазинов уже было 15, в 2009 году был только 1 магазин. Стало так — одно фоновое задание порождало много подчиненных фоновых заданий которые загружали и анализировали информацию;
- 2024 год. Информации стало слишком много и иногда ожидать загрузку прайса до 2-х часов стало критично для бизнеса (строилась очередь на одновременную обработку не более 10-15 прайсов из 200). Появилось более глубокая проблема, как работа с дедлайном — время, до которого необходимо сделать заказ на товар у поставщика, при соблюдении которого товар клиенту будет доставлен на следующий день. Решение оказалось технологичным — зачем постоянно загружать информацию, когда ее можно обновить только при событии изменения этой информации. Соответственно, когда возникает событие, что у поставщика что-то обновилось, это событие попадает в очередь на обработку и далее оно передается в 1С:Предприятие. Дальше система обрабатывает прайс. Таким образом важные прайсы попадают в систему очень быстро, для особо важных поставщиков удалось сократить время обновления цен и наличия с 2-х часов до десятков секунд;
- Конечно, можно переписать подсистему и придумать более удачную архитектуру, которая будет работать лучше, но кто на это даст денег? Событийная обработка оказалось намного дешевле, так как не потребовала измений базовой подсистемы.
Ответы на вопросы из комментариев
Если бы пришлось писать подобный сервис с нуля, то как бы это выглядело в коде?
Наверное, правильно начать с ограничения «1С:Предприятие 8», нельзя никаким образом подписатся на внешнее событие другой системы, если не запущен хотя бы один клиентский сеанс или сеанс фонового задачния. Это ограничение обходится двумя способами:
- Использовать фоновое задание в «1С:Предприятие 8», которое периодически проверяет наличие новых сообщений в системе обмена сообщениями. Проблематика:
- Реализовать асинхронную обработку сообщений будет проблематично;
- Асинхронную обработку можно реализовать, если фоновое задание будет порождать новые фоновые задания и контролировать процесс их выполнения;
- Дополнительные проблемы при реализации транзакционного чтения сообщений из системы обмена сообщениями;
- Необходимо реализовать компоненту подключения к системе обмена сообщениями, если отсутствует HTTP интерфейс.
- Использовать службу, которая подписывается на события системы обмена сообщениями (пример, не рекомендую использовать в боевой базе, это учебный пример. GitHub). При появлении сообщений, выполняет маршрутизацию сообщения на HTTPСервис «1С:Предприятие 8». Проблематика:
- Необходимо знать языки программирования отличные от 1С;
- Есть возможность использовать ESB для этих целей, но не освобождает от первого пункта.
Сообщения уже поступают в «1С:Предприятие 8» и обрабатываются. Для отправки сообщений так же можно использовать два пути:
- Написать компоненту, которая будет отправлять сообщения (пример, учебный);
- Обычно в системе обмена сообщениями есть HTTP интерфейс. Можно реализовать отправку сообщений в «1С:Предприятие 8» с помощью HTTPСоединение, но для больших сообщений нужно, все-таки, реализовать компоненту.
Сообщения уже поступают и отправляются. Настройку каналов, бирж и организацию обработкиотправки в «1С:Предприятие 8» сознательно успускаю, это целая статья.
Как выглядит прием сообщений в 1с?
Наверное, правильно начать с ограничения «1С:Предприятие 8», нельзя никаким образом подписатся на внешнее событие другой системы, если не запущен хотя бы один клиентский сеанс или сеанс фонового задачния. Это ограничение обходится двумя способами:
- Использовать фоновое задание в «1С:Предприятие 8», которое периодически проверяет наличие новых сообщений в системе обмена сообщениями. Проблематика:
- Реализовать асинхронную обработку сообщений будет проблематично;
- Асинхронную обработку можно реализовать, если фоновое задание будет порождать новые фоновые задания и контролировать процесс их выполнения;
- Дополнительные проблемы при реализации транзакционного чтения сообщений из системы обмена сообщениями;
- Необходимо реализовать компоненту подключения к системе обмена сообщениями, если отсутствует HTTP интерфейс.
- Использовать службу, которая подписывается на события системы обмена сообщениями (пример, не рекомендую использовать в боевой базе, это учебный пример. GitHub). При появлении сообщений, выполняет маршрутизацию сообщения на HTTPСервис «1С:Предприятие 8». Проблематика:
- Необходимо знать языки программирования отличные от 1С;
- Есть возможность использовать ESB для этих целей, но не освобождает от первого пункта.
OData позволяет снаружи обращаться к данным 1С и при этом не писать в 1С логику отдачи данных. С другой стороны, для обмена сообщениями, сообщения, наверно, надо формировать из 1с. Это накладывает какие-то ограничения?
OData довольно проблемный механизм, вот у нас есть таблица размером около 80Гб. При обращении к данной таблице происходит падение всего кластера, возможно, сейчас уже что-то да исправлили, но рисковать использовать этот механизм…
Обычно обмены сообщениями между приложениями это не плоские обмены. Три разных документа в «1С:Предприятие 8» может соответствовать одному документу в другой системеприложении. Использование OData напрямую — это очень сильное связывание приложений и дублирование функционала. Если сломается что-то в одной системе, то и другая система перестанет работать.
Ограничений может и не быть при правильном построении архитектурной составляющей. В своей практике использую конструктор обмена сообщениями (зачатки документации GitHub, проект нигде еще не описывался), что позволяет создавать обмены любой сложности. Например, создание обмена данными очета ОСВ (Оборотно-сальдовая ведомость с дополнительными аналитическими данными) с системой визуализации (Dashboard) занял порядка 2-ух часов.
Какие-то сторонние приложения умеют работать с очередями сообщений?
Отличный пример ESB (Enterprise service bus). Все системы можно научитьрасширитьзаплатить за доработку что бы появилась поддержка очередей. Проще всего это сделаеть, когда приложениянаборымикросхемы имеют внешние интерфейсы, API или используют базу данных. Если у них отсутствуют некоторые интерфейсы иили существуют ограничения это обходится с помощью ESB (Enterprise service bus) или собственноручно реализованных сервисов.
Хороший пример, в магазине происходит видеофиксация всего что происходит возле входной двери. Далее из этого потока видеосигнала можно посчитать количество посетилелей за час/день/месяц. Так же можно поступать с очередями.
В 1С можно в общем модуле что-нибудь написать, подключить, но есть же закрытые системы. Как вы их «принуждаете» отправлять сообщения в очередь?
Немного ответил в предыдущем сообщении, все зависит от ситуации, если это важно для бизнеса — будут наняты люди, которые это сделают. Если это очень критично, можно посадить людей и они вручную будут заносить данные. Есть один успешный коммерческий банк, который может в одночасье перекинуть две тысячи сотрудников на выполнения опредленной операции такого рода.
Литература
Все книги настоятельно рекомендую читать в оригинале, некоторые понятия не имеют аналогов в русском языке. Книги частично применимы для «1С:Предприятие 8» и позволяют развить навыки принятия архитектурных решений. Последняя книга в списке отлично подойдет для того чтобы начать экспериментировать с паттернами и пощупать настоящую асинхронность.
- The «Gang of Four». Design Patterns: Elements of Reusable Object-Oriented Software. — Addison-Wesley, 1994, ISBN: 0202433612.
- Martin Fowler. Patterns of Enterprise Application Architecture. — Addison-Wesley, 2003, ISBN: 0321127420.
- Gregor Hohpe and Booby Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. — Addison-Wesley, 2003, ISBN: 0321200683.
- Christian Nagel. Professional C# 6 and .NET Core 1.0. — Willey, 2024, ISBN: 1119096603
Ссылки на связанные публикации:
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Петр, спасибо за отличную статью. После прочтения появилось два вопроса.
Что есть канал на физическом (архитектурном) уровне?
Что есть сообщение на физическом (архитектурном) уровне?
Если бы пришлось писать подобный сервис с нуля, то как бы это выглядело в коде?
«Обмен сообщениями, что это? Сообщения это сообщения, обмен это обмен. Когда системам нужно обменяться сообщениями они ими обмениваются используя канал обмена. Вот самые известные книжки по программированию.»
(1) infosoft-v, на выходных добавлю в публикацию.
(2) Alien_job, возможно, стоит добавить больше конструктивной критики. Информации на самом деле много, а так же выполненных внедрений. Публикация будет расширятся, но направление можно скорректировать.
(4) тогда можно не критику, а вопросы?
— как выглядит прием сообщений в 1с?
— OData позволяет снаружи обращаться к данным 1С и при этом не писать в 1С логику отдачи данных. С другой стороны, для обмена сообщениями, сообщения, наверно, надо формировать из 1с. Это накладывает какие-то ограничения?
— какие-то сторонние приложения умеют работать с очередями сообщений? Типа «не надо писать сихронизацию с …, можно просто отправлять в очередь …»
— в 1С можно в общем модуле что-нибудь написать,подключить, но есть же закрытые системы. Как вы их «принуждаете» отправлять сообщения в очередь?
(4)
а также
Публикация будет расширятЬся
Граммар-наци негодуэ.
PS Статьи — дело полезное, нужно нести просвещение в массы.
Быстро посмотреть о чём речь (официальный сайт книги и её авторов):
(1) infosoft-v, Механизм сообщений уже давно реализован 1с в «1С:Технология публикации решений 1cFresh». Конечно в упрощенном виде, но для понимания процесса вполне годится. Сам интересуюсь этой темой уже 3 года.
Подписался