Холивара для. API vs шина сообщений

Мысли, почему система, где сервисы общаются через общую шину сообщений проще, чем где общение идет через API.

В системе с API/REST системы синхронно друг к другу обращаются, для этого:

  1. требуется обработка ошибок на всех уровнях (допустим процесс А вызывает Б а тот вызывает В)
  2. плюс обработка таймаутов
  3. плюс логгирование ошибок (pl7: логированием занимается вызывающая сторона) т.е в вызывающей стороне должно быть понимание какие ошибки могут произойти на вызываемой стороне как об этом лучше сообщить и что делать вообще

В системе с сообщениями, у процесса есть шина, он кладет в нее запрос. В результате может появится:

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

Поэтому мне и кажется, что система на общей шине будет проще и легче, чем система построенная на API.

~~OWNERAPPROVE~~

Прочитал обсуждения.blog Холивара для. API vs шина сообщений
Yes(1) No(0) Clear

Yes:
,

No:

Обсуждение

adminadmin, 21.11.2018 19:11

с точки зрения разработки, практика как правило обратная, с очередью получается сложнее кодить и сложнее код.

требуется обработка ошибок на всех уровнях

pl7 ошибка должна проходить без изменений на все уровни вверх, можно дополнять текст но не менять.

плюс обработка таймаутов

в шине тоже есть обработка таймаутов

уже сформированная обрабатывающей стороной, в едином формате более менее)

чем строже тем сложнее расширять, уровень шины становится умным и специфицированным

А процесс, который обрабатывает сообщения, сам занимается из получением, сам их обрабатывает.

Возникает асинхронка, это всегда сложнее кодить, особенно джунерам

Поэтому мне и кажется, что система на общей шине будет проще и легче, чем система построенная на API

Мне кажется, что тебе только кажется. Это разные способы общения подсистем, с точки зрения простоты кода call api проще и шина нужна там где call не справляется.

Например шина нужна там, где много событий и есть несколько слушателей которые хотят подписаться на события.

p.s. шина технологичней и универсальней, но никак не проще, если хочешь можно разобрать на примерах.

adminadmin, 21.11.2018 19:26 (04.12.2018 07:21)

кстати шина(среда) с сообщениями меж подсистем(объектов) это тру идеолога ооп))

опять же по современным меркам это всего лишь один из патернов.

pl7 пропагандирует другой подход

  • есть данные, есть задачи(или tobe состояния), и есть обработчики.
  • Очередь задач с ее обработчиком это подсистема, обработчик в отличии от ооп не содержит состояний и может быть перезагружен или распараллелен.
  • У нескольких подсистем могут быть общие данные.
  • Методы и проперти это лишь удобные патерны кода, а не архитектуры.
  • А причем здесь шина? а не причем просто навеяло)

TODO перенести в PL7 в патерны

Nikolay CarbonsoftNikolay Carbonsoft, 04.10.2021 11:13

Я просто сравнил теплое с мягким немного. Я не сравнивал REST API vs вызов-процедур-через-шину. Тут действительно получается асинхронка, таймауты и прочие стремные вещи, которые во многом схожи с REST API при применении микросервисов, и если сделать умную шину, которая будет заодно контролировать и мониторить работу микросервисов…

Я скорее имел в виду движение в сторону работы с job'ами, вместо вызова API или даже переход на декларативное описание (но тут уже не шина будет, а СУБД, хотя для таких вещей подойдет какой-нибудь NoSQL). И да, еще не понятно что проще: REST API или job. Джоб сильно увеличивает качество абстрагирования, но у вызывающего появляется появляется сложная сущность job, которая может сильно повлиять на ее архитектуру (для web-приложения, это хранение job в своей БД или в сессии пользователя, периодическая проверка состояния, вывод пользователю статуса job'а итд).

А переход на декларативное описание - схожий метод, что был применен в системе интеграции с оборудованием, когда евенты заменили скриптом-синхронизатором. Дополнительной фичей тут будет разбиение на системы, которое доступно для администратора - REST API, обычно, дебажит разработчик, а упавший job в супервизоре - админ.

Ваш комментарий. Вики-синтаксис разрешён: