Здравствуйте, maxkar, Вы писали:
G>>Существует ли шина\боркер\оркестратор, который может совмещать оба подхода:
M>Почти все требования (кроме надежной доставки) реализуют API Gateways. А надежная доставка не нужна. Смотрите:
G>>3) Окрестратор вызывает REST эндпоинты получателей, а в случае их недоступности повторяет вызов через некоторое время
M>Не нужно. Либо отправитель уже реализует надежную доставку до оркестратора (и тогда оркестратору не нужно ничего повторять). Либо отправитель надежной доставки не реалиует. Но это обозначает, что сообщения терять допустимо и дополнительную работу на оркестраторе можно не делать.
В том и дело, что я хочу функцию надежной доставки возложить на этот брокер, а не городить его в каждом приложении. Тем более я сильно сомневаюсь в квалификации среднего программиста, что он может без ошибок сделать надежную доставку.
Без надежной доставки остальное все не очень нужно.
M>Но вот что меня еще больше волнует, так это как этот пункт сочетается с предыдущим? Этот пункт (4) утверждает, что оркестратор может терять сообщения. Зачем тогда все сложности с попыткой гарантированной доставки в пункте 3?
Это вообще нормальная практика, что сообщение выбрасывается из очереди если не удалось его доставить за N попыток.
G>>5) На стороне окрестратора можно настроить сохраннеие последовательности вызовов
M>Это очень сложно в ситуации с "зависимыми entities" (когда связные сущности меняются неявно в результате изменения других). А могут ведь быть и явные групповые операции еще. Из более-менее простого я вижу только возможность доставлять сообщения строго последовательно. Но это не будет работать для больших нагрузок.
Вообще без разницы честно говоря. Я описал тот минимальный функционал который хочу видеть. Ни один пункт из него выкинуть нельзя.
G>>Существует такое? Или я слишком много хочу?
M>Называется API Gateway. Например, статья приводит несколько реализаций (на качество статьи я не смотрел, только на список решений).
Без надежной доставки смысла нет.
M>Если вам все же очень хочется их решить — можно сделать два простеньких сервиса. Один будет предоставлять REST для отправки сообщений в message bus. Второй будет слушать сообщения и маршрутизировать их в web hook (aka вызов rest).
А почему нет одного сервера, который это делает?
Я понимаю что наколхозить такой сервер можно из подручных средств. Но вот готового решения, кроме тяжелых и дорогих, не видел.
