Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Высоконагруженный веб-сервис. Вариант реализации в 1С?

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

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

Ну и еще 1 регистр сведений журнал (лог)
   PLUT
 
1 - 06.05.21 - 09:58
(0) веб-сервис? а почему не http-сервис?
   Волшебник
 
2 - 06.05.21 - 09:58
   PLUT
 
3 - 06.05.21 - 10:00
то, что в России - высоконагруженный сервис, в Китае - неудачный день (алибаба и jd)
   Bigbro
 
4 - 06.05.21 - 10:11
на мой взгляд 1с не инструмент для реализации высоконагруженных решений.
для каждого инструмента есть своя область, и тащить 1с повсюду совсем не стоит.
все равно упретесь в потолок при нагрузках на порядок ниже альтернативных вариантов, и смысл?
   Механик
 
5 - 06.05.21 - 10:12
А что вообще подразумевается под высоконагруженным сервисом? И какой "предел" у 1С?
   arsik
 
6 - 06.05.21 - 10:15
(2) Все про это говорят, но никто не видел в живую. Я пытался найти информацию - 0.
   Snork
 
7 - 06.05.21 - 10:27
(6) у меня есть, остался от прошлых разработчиков. но видимо подходит к пределу..
Надо, видимо, переделывать
   Snork
 
8 - 06.05.21 - 10:28
(4) первичные данные в 1С, разные виды внешних источников запрашивают/дают данные
   Snork
 
9 - 06.05.21 - 10:28
(1) сейчас веб. новый будет http
   Bigbro
 
10 - 06.05.21 - 10:28
(7) главное обеспечить возможность параллельной обработки. тогда можно будет масштабировать горизонтально запуская новые экземпляры обработчиков событий на шине.
   Snork
 
11 - 06.05.21 - 10:30
(2) та учетная база с 0ля написана, предыдущими умельцами под отраслевую специфику.  режим совместимости 8.3.7
   Snork
 
12 - 06.05.21 - 10:32
(10) пока 1 на прием и 1 на отдачу. в базе еще 70 пользователей текущих работают 24/7
тут есть параллельно, то регл задания могут пользователей парализовать, надо пробовать
   Фрэнки
 
13 - 06.05.21 - 10:32
повторю вопрос из (5)

А что вообще подразумевается под высоконагруженным сервисом? И какой "предел" у 1С?
   Snork
 
14 - 06.05.21 - 10:35
(13) самому интересно сколько 1С вытянет? у кого какой опыт?
сейчас 30т запросов в сутки, объем растет, добавляются новые виды интеграций
   Волшебник
 
15 - 06.05.21 - 10:38
(14) Это менее 1 запроса в секунду. Конечно, надо понимать цену одного запроса, чтобы присвоить системе почётное звание "высоконагруженной".
   END
 
16 - 06.05.21 - 10:40
(14) Вот, можешь ознакомиться. Реально высоконагруженная система. https://infostart.ru/1c/articles/1234830/
   Snork
 
17 - 06.05.21 - 10:40
(15) в секунду бывает до 4-5 запросов, запросы не равномерно распределены по суткам, а в основном в интервале 8:00-20:00
   mTema32
 
18 - 06.05.21 - 10:41
(0) Шина - 2 отдельных регистра сведений 1-на входящие данные; 2-на исходящие данные
и 2 регл задания на разбор очереди из регистров сведений

Сервер только нормальный соберите и все потянет 1С.
   END
 
19 - 06.05.21 - 10:41
(17) В этой же статье и результаты исследований работы 1С с http сервисами.
   Snork
 
20 - 06.05.21 - 10:41
(16) высоконагруженная для 1с и не для 1С разные понятия. Топик про 1С
   Snork
 
21 - 06.05.21 - 10:42
(18) уже. кластер из 2 пока
   END
 
22 - 06.05.21 - 10:44
(20) Ты статью то читал? Там как раз разбор, почему 1С не потянул такие нагрузки и пришлось использовать вспомогательные звенья.
   END
 
23 - 06.05.21 - 10:45
(20) Ребята изначально то все хотели на чистом 1С организовать.
   Волшебник
 
24 - 06.05.21 - 10:46
(17) Надо смотреть цену запроса: сколько нужно выполнить работы, чтобы ответить на единичный средний запрос. Например, сколько и каких запросов к БД, какой объём данных ответа.

В какой-то момент станет понятно, что надо поставить кучу кэширующих систем/баз, в 1С передавать только самые сложные.
   Snork
 
25 - 06.05.21 - 10:46
(22) почитаю. у меня первичная система - 1С. все оперативные обмены будут в ней, возможно для ресурсоемких придётся что-то изобретать
   mTema32
 
26 - 06.05.21 - 10:49
(1) Я так и не понял в чем принципиальное отличие веб-сервисов от http.
(25) Мы для ресурсоемких обменов фоном делаем все процедуры, а результат кладем отдельно - его и забирает клиент сервиса.
   Snork
 
27 - 06.05.21 - 10:52
(26) в 1с код для http намного проще писать, сопровождать, расширять, чем для web сервиса
Когда много фоном запишешь в БД, пользователей замедляешь жизнь
   mistеr
 
28 - 06.05.21 - 10:52
(4) Я конечно рискую кого-то обидеть, и могу оказаться неправ, но по-моему смысл простой: кроме 1С, ничего не знаешь, а денег урвать за заказ хочется.
   PLUT
 
29 - 06.05.21 - 10:54
(26) веб-сервисы "тормозные", http пошустрее работают, но с авторизацией и безопасностью нужно заморочиться, если систему "наружу" голой ж.пой выставлять для клиентов
   Василий Алибабаевич
 
30 - 06.05.21 - 10:55
(26) Приципиально одна весчЪ. Для ВЕБ-сервиса всегда выполняется модуль сеанса. Для каждого запроса. И если оно громоздкое - сушите весла. Для http этого нет.
Вторая достаточно принципиальная весчЪ - для http не выполняется стандартная процедура авторизации.
 
 
   PLUT
 
31 - 06.05.21 - 10:55
(28) иногда 1С - это "мастер-система", а http - удобный механизьм интригации между
   Snork
 
32 - 06.05.21 - 10:55
(28) другой случай. в наследство достался Франкенштейн на 1С, ну и бюджет не безлимитный.
Тут вопрос какой предел у 1С, если по нормальному сделать. Тогда и понять можно какой запас, перспективы
   mistеr
 
33 - 06.05.21 - 10:55
(24) Так в том-то и дело, что количество работы зависит от дизайна системы, и используемых технологий. Я более чем уверен, что Nginx + NоSQL база решит задачу ТС за x0.1 денег.
   PLUT
 
34 - 06.05.21 - 10:58
(30) для http всегда инициализируются параметры сеанса ( «тяжелый» обработчик УстановкаПараметровСеанса()), другое дело в http можно повторно сеансы использовать, тем самым сократить расходы на инициализацию
   Snork
 
35 - 06.05.21 - 10:58
(33) допустим ставим Nginx + NоSQL, но все равно все это дело должно в 1С будет обмениваться. Получается лишнее звено в цепи и соответствующие накладные расходы
   PLUT
 
36 - 06.05.21 - 11:01
(35) покури MQTT-брокер ("кролика" того же) для гарантированной доставки сообщений, или если запрос потеряется, ну и х@р с ним
   Snork
 
37 - 06.05.21 - 11:02
(36) я не про это. все равно писать придётся обмен 1С и NоSQL с обработкой большого кол-ва запросов
   mistеr
 
38 - 06.05.21 - 11:04
(35) Ну пусть обмениваются в off-peak. С передачей большого количества данных малым количеством запросов 1С вполне справится. А вот наоборот — нет.
   Василий Алибабаевич
 
39 - 06.05.21 - 11:06
Непонятны задачи обмена. Если обмен односторонний - оджин подход. Двусторонний - совсем другой.
   vde69
 
40 - 06.05.21 - 11:08
(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х.
документов в сутки
   ptiz
 
41 - 06.05.21 - 11:11
(17) "в секунду бывает до 4-5 запросов" - а где тут нагрузка, тем более "высокая"?
Узкое место будет не в веб-сервисе, а в обработке этих запросов самой 1С.
   mTema32
 
42 - 06.05.21 - 11:15
(0) ТС, на мой взгляд все уже придумано.
Я так делал и видел в других - не одинес системах подобную реализацию "тяжелых" обменов.
Клиент стучится с запросом в сервис, ему сервис отдает идентификатор запроса. И он потом с этим идентификатором стучится уже другим методом, где ему возвращается статус обработки запроса. И так он будет ломиться в ожидании получения нужного статуса. После чего забирается результат запроса.
Это если коротко.
   Snork
 
43 - 06.05.21 - 11:18
(41) логично, узкое место в 1С. Я в очередь думаю сразу писать все данные, чтобы их только отправлять, без доп запросов
   Snork
 
44 - 06.05.21 - 11:18
(42) я для новых интеграций там так и сделал уже
   mistеr
 
45 - 06.05.21 - 11:22
(42) Это не решение задачи "получить ответ быстро". Это лишь удобство, если приходится ждать долго. И не для всех случаев это подходит.
   Kassern
 
46 - 06.05.21 - 11:26
(42) Так почта России работает, когда статусы посылок хочешь получить. Если мне не изменяет память, 1 токен дается на 3000 заказов. А далее по этим токенам получаешь нужные данные, когда, они будут готовы.
   ptiz
 
47 - 06.05.21 - 11:26
(43) Всё зависит от:
1) критично ли тому, кто вызвал 1С, время ожидания
2) критично ли тому, кто вызвал 1С, чтобы обработка его данных полностью завершилась за этот вызов, и он не может ждать какого-то регл задания
3) будет ли блокировка в 1С при параллельной обработке входящих запросов

Какой ответ ты хочешь получить, если никаких вводных данных не привел и не описал задачу целиком?
   Snork
 
48 - 06.05.21 - 12:44
(47) vde69 уже ответил


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.