старый товарищ, но по духу молодой, в телеграмм канале напомнил о том, почему собственно выбран RabbitMQ в качестве основного сервера для реализации событийной интеграции в 1С.
Как все начиналось
в целом самое первое архитектурное решение предполагалось универсальным - то есть идея была в том, чтобы из 1С вызывать универсальные методы - а уже через адаптеры менять “транспорт”
http://www.1cpp.ru/forum/YaBB.pl?num=1261865206
Казалось что основным станет ActiveMQ как наиболее распространненый, а затем оказалось:
Выбор сервера
- ActiveMQ на сложных федеративных развертываниях тяжел
- ActiveMQ при высоких нагрузках задыхается
- В сложных федеративных сетях на NAT - ActiveMQ вообще не работает
в 2012 году была найден вот такой скриншот где казалось что что скорее всего нужно смотреть в сторону ZeroMQ или на крайний случай
Выбор протокола
при ближайшем рассмотрении оказалось, что 1C-системы настолько много бизнес-сообщений-событий генерирует, что влияние HTTP и WSDL (и даже REST) слишком велико - нужно было интегрировать 1С по более низким (с точки зрения OSI https://ru.wikipedia.org/wiki/Сетевая_модель_OSI) уровням.
То есть что-то потоковое где-то на уровне TCP-UDP - то есть транспортный уровень.
Наиболее интересным оказалось использование протокола AMQP https://www.amqp.org/product/different
Он как раз убирает высокоуровневые данные из протокола - осталяя только транспортные составляющие. Отсюда и скорость интеграции.
Федеративные сети
Казалось в далеком 2012 году, что федеративные сети это сети типа Связной, X5Retail и другие крупняки. Но потом оказалось что федеративная сеть - это сеть между сегментами которой есть роутет-шлюз. А это извините любая оптовка с сайтом - так как сайт живет в интернете, и свитчи-шлюзы там не один и не два между оптовкой и сайтом.
Из скриншоты видно что наиболее интерсным был бы ZeroMQ - НО http://zguide.zeromq.org/page:all#Federation-Versus-Peering
Хотя federation он там как бы есть - но нужно делать самому, прям расчехлять знания по С++ - находить бюджет на человекогод и делать.
Версии AMQP
Если коротко, то и на сегодня продолжает присутствовать ситуация, что наиболее распространенной и стабильной версией протокола является версия 0.9.1.
Хотя официально версия 1.0 заявлена как ратифицированная https://www.oasis-open.org/news/pr/amqp-1-0-approval, суть в том что версия протокола 1.0 фактически является вообще другим протоколом. Позиция авторов RMQ изложена в их экспериментальном плагине https://github.com/rabbitmq/rabbitmq-amqp1.0
Если еще короче - почти все поля переименованы, виртуальные хосты вообще выпилены, ну и т.д.
В итоге к моменту 2016 года
- адаптер к 1С по реализации событийной интеграции решено было делать на базе протокола AMQP версии 0.9.1
- в качестве сервера рекомендовать RabbitMQ редакции 3.X
как только версия 1.0 протокола будет реализована не только в Apache Qpid, но в RabbitMQ (или другом втором вендоре) можно будет реализовывать и в DLL.
Инновационные протоколы и технологии
так как многие переходя на микросервисы в силу моды, не знают истоков проблемы - зачем были вообще придуманы микросервисы. Поэтому только сейчас авторы микросервисов приходят к пониманию двух интересных проблем:
- одна из академических задач - которая не была решена до сих пор в глобальном виде: это распределённые или глобальные транзакции между несколькими системами. ЗавершитьТранзакцию(ВЕЗДЕ, во всей компании, во всей стране, у всех партнеров).
и как следствие - мульти-мастер СУБД - не важно в какой узел запишет клиент данные - на соседнем узле не будет допущено задвоение сущностей с одним и тем же ключом, если запись происходила одновременно в одном узле.
Как решение данного вопроса было придумано что микросервисы должны иметь только горячий кеш данных, который они наполняют из распределенного журнала транзакций, а СУБД это только еще один микросервис, который также наполняется из единого распределенного журнала транзакции.
Так хотят инноваторы ;-), но что у них получится - это будет видно. Обычным 1С-иникам все равно от СУБД не отказаться, пока того не захотят платформщики. Та же ситуация и у дрих языков - отказаться от СУБД: тупо странно. А вдруг чего ? Поэтому все авторы микросервисов делают свою маленькую СУБД рядом со своим сервисом. На всякий случай по старой памяти.
Все вышеуказанное намекают как раз на Apache Kafka. Которые большинство авторов статей на Хабре используют то как раз в качестве MOM - то есть транспорта данных, между системами.
Потоки, WAMP и другой STOMP/Хайп
на рынок MOM пытаются ворваться новые игроки
- deepstream - https://deepstreamhub.com/blog/an-overview-of-realtime-protocols/
- nats - https://nats.io/
Перешедшие по ссылкам на досуге могут поэкспериментировать с https://crossbar.io/
А тем кому надо Ынтернет вещей здесь и сейчас - могут брать https://www.rabbitmq.com/mqtt.html и логику работы вентилятора и двигателя строить хоть на 1С, хоть на Oscript.
Финал.
- по савокупной стоимости владения в реальном бизнесе наиболее выгрыйшным вариантом является MOM в виде сервера RabbitMQ.
- если ситуация поменяется по сравнению с вышеизложенной - не поменяется главное: в 1С все равно будет метод
ОтправитьСообщение- а транспортный уровень может быть любым. Когда они там в своих консорциумах договоряться - тогда и передеедем если понадобится.
P.S. Поэтому изначально и закладывалась независимость адаптера 1С от конкретного транспорта - сейчас и ближайшие лет 5-10 ситуация не изменится.
Любителям потопить про ActiveMQ - советую рассказать мне каким образом вы будете делать вот такое https://habr.com/post/422151/, в условиях когда BI система в онлайне хочет получать информацию о чеках, а учет ведется в 1С. И BI система не на Java, а на С# (клиент не обновлялся с 2016 года ;-))