У кого был опыт реализации поделитесь знаниями..
Какой подход окажется лучше:
1. с "шиной" в 1С
2. без "шины" в 1С

Шина - 2 отдельных регистра сведений 1-на входящие данные; 2-на исходящие данные
и 2 регл задания на разбор очереди из регистров сведений

Ну и еще 1 регистр сведений журнал (лог)

(0) веб-сервис? а почему не http-сервис?

Интеграционная шина от 1С
https://wonderland.v8.1c.ru/blog/integratsionnaya-shina/
https://infostart.ru/journal/news/mir-1s/firma-1s-anonsirovala-novyy-produkt-integratsionnaya-shina_1214491/

то, что в России - высоконагруженный сервис, в Китае - неудачный день (алибаба и jd)

на мой взгляд 1с не инструмент для реализации высоконагруженных решений.
для каждого инструмента есть своя область, и тащить 1с повсюду совсем не стоит.
все равно упретесь в потолок при нагрузках на порядок ниже альтернативных вариантов, и смысл?

А что вообще подразумевается под высоконагруженным сервисом? И какой "предел" у 1С?

(2) Все про это говорят, но никто не видел в живую. Я пытался найти информацию - 0.

(6) у меня есть, остался от прошлых разработчиков. но видимо подходит к пределу..
Надо, видимо, переделывать

(4) первичные данные в 1С, разные виды внешних источников запрашивают/дают данные

(1) сейчас веб. новый будет http

(7) главное обеспечить возможность параллельной обработки. тогда можно будет масштабировать горизонтально запуская новые экземпляры обработчиков событий на шине.

(2) та учетная база с 0ля написана, предыдущими умельцами под отраслевую специфику.  режим совместимости 8.3.7

(10) пока 1 на прием и 1 на отдачу. в базе еще 70 пользователей текущих работают 24/7
тут есть параллельно, то регл задания могут пользователей парализовать, надо пробовать

повторю вопрос из (5)

А что вообще подразумевается под высоконагруженным сервисом? И какой "предел" у 1С?

(13) самому интересно сколько 1С вытянет? у кого какой опыт?
сейчас 30т запросов в сутки, объем растет, добавляются новые виды интеграций

(14) Это менее 1 запроса в секунду. Конечно, надо понимать цену одного запроса, чтобы присвоить системе почётное звание "высоконагруженной".

(14) Вот, можешь ознакомиться. Реально высоконагруженная система. https://infostart.ru/1c/articles/1234830/

(15) в секунду бывает до 4-5 запросов, запросы не равномерно распределены по суткам, а в основном в интервале 8:00-20:00

(0) Шина - 2 отдельных регистра сведений 1-на входящие данные; 2-на исходящие данные
и 2 регл задания на разбор очереди из регистров сведений

Сервер только нормальный соберите и все потянет 1С.

(17) В этой же статье и результаты исследований работы 1С с http сервисами.

(16) высоконагруженная для 1с и не для 1С разные понятия. Топик про 1С

(18) уже. кластер из 2 пока

(20) Ты статью то читал? Там как раз разбор, почему 1С не потянул такие нагрузки и пришлось использовать вспомогательные звенья.

(20) Ребята изначально то все хотели на чистом 1С организовать.

(17) Надо смотреть цену запроса: сколько нужно выполнить работы, чтобы ответить на единичный средний запрос. Например, сколько и каких запросов к БД, какой объём данных ответа.

В какой-то момент станет понятно, что надо поставить кучу кэширующих систем/баз, в 1С передавать только самые сложные.

(22) почитаю. у меня первичная система - 1С. все оперативные обмены будут в ней, возможно для ресурсоемких придётся что-то изобретать

(1) Я так и не понял в чем принципиальное отличие веб-сервисов от http.
(25) Мы для ресурсоемких обменов фоном делаем все процедуры, а результат кладем отдельно - его и забирает клиент сервиса.

(26) в 1с код для http намного проще писать, сопровождать, расширять, чем для web сервиса
Когда много фоном запишешь в БД, пользователей замедляешь жизнь

(4) Я конечно рискую кого-то обидеть, и могу оказаться неправ, но по-моему смысл простой: кроме 1С, ничего не знаешь, а денег урвать за заказ хочется.

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

(26) Приципиально одна весчЪ. Для ВЕБ-сервиса всегда выполняется модуль сеанса. Для каждого запроса. И если оно громоздкое - сушите весла. Для http этого нет.
Вторая достаточно принципиальная весчЪ - для http не выполняется стандартная процедура авторизации.

(28) иногда 1С - это "мастер-система", а http - удобный механизьм интригации между

(28) другой случай. в наследство достался Франкенштейн на 1С, ну и бюджет не безлимитный.
Тут вопрос какой предел у 1С, если по нормальному сделать. Тогда и понять можно какой запас, перспективы

(24) Так в том-то и дело, что количество работы зависит от дизайна системы, и используемых технологий. Я более чем уверен, что Nginx + NоSQL база решит задачу ТС за x0.1 денег.

(30) для http всегда инициализируются параметры сеанса ( «тяжелый» обработчик УстановкаПараметровСеанса()), другое дело в http можно повторно сеансы использовать, тем самым сократить расходы на инициализацию

(33) допустим ставим Nginx + NоSQL, но все равно все это дело должно в 1С будет обмениваться. Получается лишнее звено в цепи и соответствующие накладные расходы

(35) покури MQTT-брокер ("кролика" того же) для гарантированной доставки сообщений, или если запрос потеряется, ну и х@р с ним

(36) я не про это. все равно писать придётся обмен 1С и NоSQL с обработкой большого кол-ва запросов

(35) Ну пусть обмениваются в off-peak. С передачей большого количества данных малым количеством запросов 1С вполне справится. А вот наоборот — нет.

Непонятны задачи обмена. Если обмен односторонний - оджин подход. Двусторонний - совсем другой.

(32) ну смотри, расписываю на пальцах:

1. 1с оптимизирована для чтения а не для записи, то есть это "бек" система
2. тебе нужно ее интегрировать с "фронт" системой, которой важно быстро писать
3. критичным местом является не получить отказ (блокировку или любой другой) при записи из "фронта"

для решения потянет или нет - берешь свое решение 1с и загружаешь его на 100% записью (тестовых данных), от туда получаешь время самой большой транзакции и делишь 24 часа на это время, получится максимум записей за сутки
далее надо понимать не равномерность запросов, для офисной работы эту цифру надо разделить на 3 или на 4

это будет ограничение "с верху",

далее вводишь коэф. развития я обычно делю на 10 (один порядок), можно делить на 100 (два порядка)


пример: самая длинная транзакция длится 2 сек
24*60*60/2 = 43200
43200 / 4 = 10800
10800 / 10 = 1080

примерно 1000 документов в сутки для офисной работы при скорости проведения 1 документа 2 сек с запасом на пики и будущее развитие до 10х.
документов в сутки

(17) "в секунду бывает до 4-5 запросов" - а где тут нагрузка, тем более "высокая"?
Узкое место будет не в веб-сервисе, а в обработке этих запросов самой 1С.

(0) ТС, на мой взгляд все уже придумано.
Я так делал и видел в других - не одинес системах подобную реализацию "тяжелых" обменов.
Клиент стучится с запросом в сервис, ему сервис отдает идентификатор запроса. И он потом с этим идентификатором стучится уже другим методом, где ему возвращается статус обработки запроса. И так он будет ломиться в ожидании получения нужного статуса. После чего забирается результат запроса.
Это если коротко.

(41) логично, узкое место в 1С. Я в очередь думаю сразу писать все данные, чтобы их только отправлять, без доп запросов

(42) я для новых интеграций там так и сделал уже

(42) Это не решение задачи "получить ответ быстро". Это лишь удобство, если приходится ждать долго. И не для всех случаев это подходит.

(42) Так почта России работает, когда статусы посылок хочешь получить. Если мне не изменяет память, 1 токен дается на 3000 заказов. А далее по этим токенам получаешь нужные данные, когда, они будут готовы.

(43) Всё зависит от:
1) критично ли тому, кто вызвал 1С, время ожидания
2) критично ли тому, кто вызвал 1С, чтобы обработка его данных полностью завершилась за этот вызов, и он не может ждать какого-то регл задания
3) будет ли блокировка в 1С при параллельной обработке входящих запросов

Какой ответ ты хочешь получить, если никаких вводных данных не привел и не описал задачу целиком?

(47) vde69 уже ответил