Здравствуйте, Cyberax, Вы писали:

C>Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.

Можно и делают. Ессна ж ни разу не силвер баллет, но диапазон применимости достаточно широк.

C>Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.

C>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).

Нормальные очереди дизайнят так, чтобы они были
— безразмерными
— не тормознутыми
— гарантировали высокий SLA по авайлабилити
При таких вводных, вероятность описанного сценария минимальна(а все в распределенных системах упирается в вероятности в конечном итоге), зато позволяет тротлить нагрузку на бекенд и мониторить логически развязать фронтенд и бекенд(что помимо всего прочего, позволяет делать 0-downtime update для бекенда).

C>В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.
Вопрос исключительно к мониторингу и агрегации логов. Ровно тоже самое может произойти при прямых вызовах — бекенд ответил response code 500 b фиг поймешь что там произошло. Кстате в нормальных очередях есть retries + deed letter queue, что очень сильно помогает уменьшить вероятность таких сценариев — если месседж не сумели обработать несколько раз, то
— там явно что-то пошло не так
— сообщение не потеряется

C>В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.
Как я уже отметил выше — retries + dlq лечит такие варианты. Хотя перфоманс может деградировать, если ретраев больше нуля(те не слать месседж в dlq при первой же ошибке).

C>Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.
Все упирается в SLA. Зачастую очереди — распределенные системы, с SLA выше чем у поставщиков-потребителей этой очереди.