Коллеги приветствую, поделитесь пожалуйста опытом.

Есть центральная база и 1000 периферийных. На данный момент обмен происходит сообщениями через Rabbitmq.
Появилась задача передавать заказы, которые создаются в периферийных базах, в центральную более быстрым способом
По примерным расчетам, около 50 заказов может быть создано одновременно, соответственно одновременно 50 WEB запросов на передачу в центральную базу.

Есть ли у кого опыт использования  Web-сервисов на подобные задачи, либо все же использовать старого доброго кролика?..
Заранее спасибо за советы.

А что, у кролика такая низкая скорость, что веб-сервисы быстрее будут?

Там сейчас раз в 20 минут передается операционная деятельность. Вариант сделать отдельную очередь и вычитывать ее быстрее тоже рассматривается.

К скорости кролика - вопросов нет.

(2) Ну тогда зачем использовать другую технологию, если имеющаяся устраивает? В чём вы видите потенциальный выигрыш от Web-сервисов?

(3) Передача заказов планируется под интернет магазин. То есть объемы данных совсем маленькие.
Через кролик же передается более большой объем информации, и пока не редки случаи что обмен через кролика иногда ложится (проект в активной разработке, группой разработчиков. Бывает что случаются проблемы при обработке входящий и исходящих сообщений, очередь забивается и потом очень долго рассасывается)

(3) таким образом пытаюсь чуть-чуть повысить отказоустойчивость. Что-то мне подсказывает что веб сервис будет более лучшим решением для моей задачи.

(4) Как-то "маленький объем" и "50 заказов одновременно" не бьётся. Если не уверены в надежности кролика, то рассмотрите HTTP сервисы ещё, там диагностика проблем проще.

(6) Понял, спасибо за совет

(6) Заказ не типовой, обрезанный. Очень мал по объему

(2) Нужно сделать отдельную очередь.
Точнее ее надо всегда делать когда не требуется последовательность передачи сообщений.

(0) С кроликом как работаете через адаптер или пулю или еще как?

(9)+ Да если сообщений не много то можно и одну очередь использовать с приоритетами сообщений.
Но имхо на 1000 периферийных лучше разные очереди.

(0) Для вас 1с создала https://wonderland.v8.1c.ru/blog/integratsionnaya-shina/

(12) Использовать "сырой" продукт без опыта промышленной эксплуатации - так себе решение.

(12) оба продукта на 1с, тут наверное этот инструмент не совсем подойдет. Но все равно спасибо за предложение

(11) на каждую базу свою очередь ?

(15) На каждое "направление" свою очередь

(0) Лучше научиться готовить Кролика, а не менять технологии по сто раз на дню

(17) HTTP сервисы тоже используются, тут дело за выбором на конкретную задачу

Почитал про rabbit mq и так и не понял, нафига он нужен.

(19) Для задач, подобных этой, и не нужен, в общем то.

(19) Для удобного обмена объектами-сообщениями.

(20) Это примерно как RDP|тонкий клиент vs РИБ

(19) Для высоконагруженных систем и с большим количеством обменов. Обмен не упадет между системами, если 1С базу решили обновить. Все сообщения обмена будут сохранены в RabbitMQ.
RabbitMQ
https://www.youtube.com/watch?v=0xoT0-TzhZ4

Хранение изменений объектов в Kafka:
https://www.youtube.com/watch?v=BqkJaidyno0

Nats (отправка за 3 секунды, 1С разбирает за 9 мин):
https://www.youtube.com/watch?v=P-J2ohPmhnw

(15) На каждую базу своя входящая очередь да и можно несколько очередей на базу чтобы разделить потоки.
Правильная архитектура точек входа/очередей/биндингов это продумывать надо под условия.

(22) Нет, если бы автору надо было заказ прогрузить во все 1000 переферийных баз в реальном времени, тогда кролик вполне был бы уместен.

(23) Я думал - какая-нибудь bulk insert напрямую в базу, а это всего лишь транспорт.

(25) Ты же наверно понимаешь что на заказ из каждой 1000 периферийных баз надо ответить?

(26) Угу всего лишь транспорт и с напрямую в базу приходится отдельно извращаться.
Ну можно с многопотчностью на фоновых

(27) И что из этого следует? 50 заказов в секунду в пике - это какая-то запредельная нагрузка, что-ли?

(29) У ТС уже есть кролик - не вижу смысла если задачу можно решить на нем без лишних сущностей.
Если бы его не было то да есть смысл выбирать веб-сервисы (еще вопрос какие ибо их дофига разных) или кролика внедрять.

(30) Топором, конечно, можно забивать гвозди. Но лучше использовать молоток.

(19) Брокер сообщений
Типа КД 3, только трехзвенка
Например, Пете нужно сообщить всем интересующимся о том, что Танька из 5 квартиры девица легкого поведения
Но Петя не хочет бегать и спрашивать у каждого, интересна ли ему эта информация
И не хочет отвечать всем обращающимся по этому вопросу в любое время дня и ночи
Поэтому он пишет в подъезде на стене эту информацию, а уж все интересующиеся читают ее там

(31) В условиях ограничения веса предпочту взять только топор с обухом подходящим для забивки гвоздей.
Или ты умеешь молотком валить деревья? Тор ты это?

(27) Кролик переваривает десятки тысяч обращений в секунду

(33) Ну если с расчетом, что лет через 5 после забивания гвоздей вдруг лес валить понадобится :)

(35) Нет тут фишка что количество технологий в одной конфе возрастает - с поддержкой проблема.

(36)+ Хотя если уже есть и кролик и веб-сервисы в конфе то глубоко пофиг да.

(36) Я больше про вопрос выбора технологий для реализации конкретных задач, думать, что будет, если "вдруг через 5 лет компания вырастет в мильён раз" не очень разумно

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

(39)+ В этом случае нечто вроде gRPC на ура идет но это еще сложнее.

Имхается шина данных в 1С уже появилась, со временем и до gRPC c protobuf из коробки дойдет.
JSON же добавили хотя XML до сих пор в строю.

(39) С Http-сервисами знакомо большинство 1С-ников, а вот с кроликами/кафками и т.п. - единицы. Использование кролика без необходимости - зачем? Если бы автора устраивала работа кролика, или была возможность самому сделать так, чтобы устраивала - вопроса здесь не появилось бы.

(41)+ Хотя не удивит что в очередной раз через одно место как с ЖР который недо sqlite блин.
Лучше бы нативную поддержку sqlite впилили в платформу а не только древний xbase-dbf

(42) Дык (30)

(42) Или ты предлагаешь отказаться ТС от кролика совсем и весь обмен перевести на веб-сервисы? Нюню.

(45) У ТС альтернатива - трахаться с кроликом, или сделать надёжно работающий вариант. Тут уж кому как больше нравится :)

(46) Думаю просто ты пока кролика не освоил и находишься на этапе ура я освоил веб-сервисы ))

(47) Ты тему целиком читал, вообще? Перечитай (3) и (4) :))

Лучше шина, но с отдельными очередями.

Проще пояснить от обратного: в центре нужно будет иногда тушить базу на регламентные процедуры (обновление, чистка, апгрейд железа, прочее) и, при схеме с WS, все эти 1000 точек будут ждать подъема центра. ХЗ как реализовано в точках, может там кто-то должен дрюкать кнопку "Отправить" и его будет злить ошибка отсутствия связи с центром. Ок, центр поднялся и одновременно большая толпа точек начнет пушить свои заказы. Центру поплохеет от такой активности.

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

(49) А если шина упала/на регламентном обслуживании, то что?

естественно шина данных, я бы выбрал Kafka, в нашем случае это было быстрее ссаного кролика.

проголосовал

Делай на Кафке, Кролик тупой

(50) для этого есть логи. веб сервисы тоже могут упасть.

Kafka предлагает гораздо более высокую производительность, чем брокеры сообщений, такие как RabbitMQ. Она использует последовательный дисковый ввод-вывод для повышения производительности, что делает ее подходящим вариантом для реализации очередей. Она может обеспечить высокую пропускную способность (миллионы сообщений в секунду) при ограниченных ресурсах, что необходимо для случаев использования больших данных.

даже гугол знает правду.

(54) Могут. Я про то, что отказоустойчивость не является важным преимуществом кролика.

(55) О, а расскажи про 1С с миллионами сообщений в секунду?

(57) да пожалуйста. реальный кейс, который я автоматизировал. есть база на 1С, а есть парсер, который собирает данные в реальном времени и кладет в кафку, база на 1С забирает эти данные из кафки регл. заданием и пишет в базу в потоках.

(58) и прям миллион сообщений в секунду?

обычно всё упирается не в скорость брокера, а в сами обработчики

(59) сбор данных - 1,5 млн в день. проверка актуальности ссылок - 10-20 млн. в день.

(60) Это и близко не "миллионы в секунду"

(61) ок, но под задачу из (0) Kafka идеально подходит, т. к. она еще хранит какое-то время данные, а у кролика насколько я помню очередь закончилась и уссё.

(60) 20млн в день это гдето 230 в секунду...вообще ерунда с точки зрения любой службы очередей

у меня ща на работе больше 2тыс в секунду...и загрузка на хосте кролика меньше 15% ...тупо не успевают серваки разбирать
(62) кролик настраивается по разному... минус у него в том что он немногопоточный, в смысле многопроцессорность не умеет

(63) "кролик настраивается по разному" // Подскажешь, как Кролика настроить, чтоб он продолжал хранить в себе уже успешно отданные сообщения?

(62) Подходит. Только, эту-же задачу можно решить ещё несколькими не менее подходящими, но более простыми, способами.