Здравствуйте, A13x, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>...
A>Меня очень заинтересовала эта ветка обсуждения, жаль, что до конструктива не добрались.
A>* Системы на сообщениях будут иметь меньшую availability из-за потерь сообщений, это можно отмести для систем, где availability самой message queue system вполне достаточна для бизнеса.
Вот имха, выделенное очень сильно зависит от используемых компонентов, сценариев, квалификации команды, бюджета на разработку и многих других факторов. Из моего опыта, надежность и availability промышленных очередей в разы выше любых велосипедов(включая прямые вызовы), напедаленых среднестатистической командой в (обычно) сжатые сроки.
С другой стороны, при нагрузках в миллионы операций в секунду, как у сайберакса, естественно что 90% промышленных очередей тупо не справятся и велосипеды придется строить. Но тут наверняка и бюджеты другие, и квалификация команды и так далее.
С третьей стороны, подобные нагрузки — ну оочень редки, хотя и интересны.
A>* С точки зрения сопровождения восстановление состояния системы при ошибке будет более сложным -- насколько я вижу correlation id / request id частично решает вопрос, но в случае потерь сообщений это становится сложным.
Строя любую распределенную систему процессинга/сохранения даных, надо помнить о том что eventual consistency — это плата за распределенную систему. Это надо учитывать с самого начала и временами оно бьет очень больно. Поэтому я всячески не рекомендую распределенные системы в тех случаях, когда без них можно обойтись. Еще один способ борьбы с eventual consistency системы — event log/event sourcing. Что в свою очередь привносит новые сложности, которые надо героически решать.
A>* Сложная обработка случаев типа multicast storm. Необходимо в архитектуру закладывать способ работы со сценарием когда система позволяет накопить больше сообщений, чем может обработать.
Да, это надо учитывать с самого начала.
A>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).
Как то так, нет универсальных сценариев. Каждый раз надо смотреть на требования и работать с ними. еще можно разворачивать дополнительные мощности динамически, уменьшать пропускную способность фронтенда(по сути переносить очередь на веб сервера), в конце концов честно умереть.
Все зависит исключительно от бизнеса, бюджета и так далее.
A>Да, и отвечая на вопрос выше про альтернативы асинхронным сообщениям для критических сервисов используют workflow / orchestration engines типа Amazon SWF или Uber Cadence — последний уберовцы построили уже имея внутреннюю "durable and scalable" message queue system — cherami.
Да, по сути — actor model в разных ипостасях. Еще можно делать централизированно на ESB.
A>Пока вроде бы очевидна неприменимость message queue-based систем для построения систем требующих максимальной надежности типа обработки заказов от пользователя, которые часто строят на подобии orchestration engines и мне кажется тут у вас консенсус -
Вот опять, все зависит от требований, нагрузки и так далее. ИМХА просто нельзя сравнивать решения для клепания сайта веб магазина аквариумных рыбок в мухосранске и для того же амазона. Соглашусь с сайбераксом, что в последнем случае любое лишнее звено привносит дополнительные риски и надо все упрощать настолько, насколько возможно.
A>Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.
Из моего опыта, сейчас обычно бизнес требует 99.95% availability для client-oriented веб сайтов. И это число легко достигается очередями. Более того, очереди позволяют увеличить availability системы по сравнению с прямыми вызовами в целом ряде сценариев — можно делать даунтайм consumer-ам очередей (почти)незаметно для пользователя с гарантированной сохранностью данных.
A>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?
Уже штук несколько, самый крупный пожалуй — аналог coursera для "реальных" американских университетов, вроде как лидер в своей отрасли.
