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

C>>Для интер-сервисной коммуникации это нафиг не нужно.
I>Опять таки, смотря какие данные там передаются. в большинстве случаев — не надо, а если это (почти) сплошной поток мелких данных с критичным временем обработки(например котировки акций), то мультиплицирование(в том или ином виде) здесь более чем необходимо.
Ну так открой два канала, какие проблемы-то? Зачем это пихать в протокол?

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

C>>ЧСХ, варианты: "А давайте возьмём Tibco/Oracle/ZMQ, у которых ВООООООООООТ ТАКОЙ!!! SLA", — заканчиваются обычно провалом.
I>Кэп подсказывает, что раз tibco/oracle/biztalk/zmq — коммерчески успешные проекты на протяжении многих лет, то твое утверждение неверно.
Угу. Благодаря подвигам продажников и ынтерпрайз-орхитектов.

C>>Некоторые вещи практически неизменны, вне зависимости от требований.
I>Все твои посты просто кричат о твоем (возможно)глубоком, но узком опыте. Ты абсолютно все задачи подгоняешь под свои шаблоны и исходя из них пытаешься решить ультимативно и безапелляционно. Дык от. Это глупо. Мир гораздо многообразней и далеко не всем нужны сообщениядробилки.
У меня достаточно широкий опыт, и ни разу я ещё не видел нормальной системы на сообщениях. Зато видел не раз, как после радикальной хирургии сложные системы со всякими workflow и оркестрацией превращались в нормальные и простые системы.

I>Если бы ты окунулся, к примеру, в типичный ентенпрайз то ужаснулся бы от зоопарка сервисов, разрабатываемых десятилетиями, обособленными командами с плохой инженерной культурой, легаси ужасом. Там банально поле невозможно добавить в xml без 125 согласований. Мне как то раз доступ к тестовому серваку полгода открывали. Тут ESB очень сильно помогает с организационной точки.
Я частично в таком окружении работаю.

I>Есть еще IoT, где большой поток входных сообщений надо буферизировать и потери единичных приемлимы.
I>Есть просто необходимость частых релизов и это пытаются порешать микросервисами...
Ой, IoT... Конкретно в IoT сообщения используются как я сказал — для пинга внешней системы, которая затем делает синхронный запрос на обновление состояния. А некоторые вообще хранят вечно-открытый TCP-канал, через который обе стороны могут общаться прямыми вызовами.

I>В общим задачи бывают совершенно разные, а серебряной пули до сих пор не придумали. Поентому я бы на твоем месте бы не утверждал бы настолько ультимативно про "практически неизменные вещи"
Зато есть очень плохие паттерны, которые приводят в итоге к проблемам.

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

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

C>ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.
Ну опять, с чего бы так? Ну вот более чем типичный сценарий в том же амазоне: появилась пиковая нагрузка, увеличилось кол-во сообщений в очереди, автоскейлинг бекенда настроен на это реагирует, начинает запускать дополнительные машины. Но ет все — время исчисляемое минутами(а то и десятками минут в случае с виндой и рантайм провижинингом). Но тем не менее машинки подымаются, очередь разгребается через некоторое время.

C>Ещё хуже.
C>Ну так плохих идей вообще очень много.
Ну раз ты сказал — то значит так и есть
Давай присвоим этой цитате номер
2:45 евангелие от сайберакса


C>И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.
Мониторинг уведомит кого надо. Например админа или там систему дизастер рекавери, которая начнет разворачивать бекенд в другом регионе.


C>Проблема в том, что если сообщения вызывают изменение чего-то, то при пропуске одного сообщения не очень понятно итоговое состояние.
Про ент сорсинг я писал выше.

C>Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.
Опять таки, все зависит от сценария и от бизнес контекста.

C>Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.
Вот как раз очередь и делает этот самы тротлинг, о чем я писал выше

C>Производители себе не враги, и никакие серьёзные последствия для них не последуют.
Ну да, канешна. И конкуренции на рынке очередей нет вообще

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

C>Ну так открой два канала, какие проблемы-то? Зачем это пихать в протокол?
Затем, чтобы не строить велосипедов для поддержания открытых каналов открытыми, с учетом таймаутов, обрывов соединений, ограничения операционной системы на кол-во открытых каналов и так далее.

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

C>Угу. Благодаря подвигам продажников и ынтерпрайз-орхитектов.
Ну да, канечна. Раз ты сказал — значит так оно и есть. Евангелие от сайберакса, 2:46

C>У меня достаточно широкий опыт, и ни разу я ещё не видел нормальной системы на сообщениях. Зато видел не раз, как после радикальной хирургии сложные системы со всякими workflow и оркестрацией превращались в нормальные и простые системы.
Если ты не видел, то ет значит что ты чего то не видел... и все. С другой стороны, соглашусь с тем что распределенные системы тулят где надо и где не надо, закон конвея только все усугубляет и зачастую это ведет к дурдому. А неумение программистов правильно строить такие системы, которое видно даже по вопросам в этом топике — контрольный выстрел в голову.
Но далеко не всякий ентерпрайз можно просто "взять и упростить". И правильные решения, построенные на очередях-ESB в огромном ряде случаев позволяют построить управляемую систему с требуемыми неефункциональными характеристиками.

C>Зато есть очень плохие паттерны, которые приводят в итоге к проблемам.
Не бывает плохих паттернов. Бывают паттерны подходящие к решению данной конкретной задачи и неподходящие. Как только это поймешь, то можно двигаться дальше к пониманию NFR/QA/ASR.

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

C>>ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.
I>Ну опять, с чего бы так? Ну вот более чем типичный сценарий в том же амазоне: появилась пиковая нагрузка, увеличилось кол-во сообщений в очереди, автоскейлинг бекенда настроен на это реагирует, начинает запускать дополнительные машины.
Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.

Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.

Всё.

Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.

C>>Ну так плохих идей вообще очень много.
I>Ну раз ты сказал — то значит так и есть
I>Давай присвоим этой цитате номер
I>2:45 евангелие от сайберакса
Ага.

C>>И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.
I>Мониторинг уведомит кого надо. Например админа или там систему дизастер рекавери, которая начнет разворачивать бекенд в другом регионе.
Угу, конечно. И ещё базы данных мигрируют и вообще всё написано так, что может работать через WAN.

C>>Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.
I>Опять таки, все зависит от сценария и от бизнес контекста.
Ну то есть, проблема не решается нормально.

C>>Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.
I>Вот как раз очередь и делает этот самы тротлинг, о чем я писал выше
Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.

C>>Производители себе не враги, и никакие серьёзные последствия для них не последуют.
I>Ну да, канешна. И конкуренции на рынке очередей нет вообще
Примерно так и есть.

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

C>>Ну так открой два канала, какие проблемы-то? Зачем это пихать в протокол?
I>Затем, чтобы не строить велосипедов для поддержания открытых каналов открытыми, с учетом таймаутов, обрывов соединений, ограничения операционной системы на кол-во открытых каналов и так далее.
Потому гораздо лучше колхозить multiplexing вручную, страдая от head of line blocking и прочих приятностей. Ага.

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

C>Потому гораздо лучше колхозить multiplexing вручную, страдая от head of line blocking и прочих приятностей. Ага.
Ты вообще читаешь мои посты, вот просто интересно.Я где то писал про то, что надо колзозить мультиплексинг вручную? Цитату не затруднит привести?

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

C>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.
Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.

C>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.
Circuit breaker можно заимплементить по разному.

C>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.
Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.


C>Ну то есть, проблема не решается нормально.

Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.

C>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.
А не надо этого делать в предложенном мной подходе.

C>Примерно так и есть.
вопросов больше не имею

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

C>>Потому гораздо лучше колхозить multiplexing вручную, страдая от head of line blocking и прочих приятностей. Ага.
I>Ты вообще читаешь мои посты, вот просто интересно.Я где то писал про то, что надо колзозить мультиплексинг вручную? Цитату не затруднит привести?
Ну не вручную, а на основе протокола системы сообщений, без разницы. Чтобы оно работало так же надёжно, как системный стек TCP, понадобиться написать аналог системного стека TCP.

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

C>>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.
I>Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.
Именно так. Вот недавно такая бомба упала на датацентр одной крупной компании — при чистке пола случайно нажали на рубильник и отключили питание для всего датацентра. Упс.

Для того, чтобы рассуждать об SLA и надёжных системах, надо сначала усвоить, что ломается вообще ВСЁ. Например, если речь идёт об autoscaling'е, то он так периодически сбоит: http://status.aws.amazon.com/rss/autoscaling-us-east-1.rss

C>>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.
I>Circuit breaker можно заимплементить по разному.
Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.

C>>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.
I>Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.
Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?

C>>Ну то есть, проблема не решается нормально.
I>Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.
Да-да. И в спецификации, конечно, написано: "Можно ломаться и терять данные, если клиенты делают слишком много запросов". Если у вас там такие спецификации, то могу только посочувствовать.

В реальном мире, нормальность решения определяется исключительно практикой использования.

C>>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.
I>А не надо этого делать в предложенном мной подходе.
Ну тогда прошу описать каким образом будет решаться проблема с перегрузкой в моём сценарии.

C>>Примерно так и есть.
I>вопросов больше не имею
Основной метод продажи этих Tibco выглядит так: продажник приходит и говорит, что если клиент купит Tibco/Oracle/whatever, то у него магически увеличится член число девяток надёжности. При этом в контракте прописаны зверские штрафные санкции за нарушения этого — возврат абонентской платы за последний месяц.

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

C>Ну не вручную, а на основе протокола системы сообщений, без разницы. Чтобы оно работало так же надёжно, как системный стек TCP, понадобиться написать аналог системного стека TCP.

Еще раз перечитай, у тебя пока что плохо получилось.

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

C>Для того, чтобы рассуждать об SLA и надёжных системах, надо сначала усвоить, что ломается вообще ВСЁ. Например, если речь идёт об autoscaling'е, то он так периодически сбоит: http://status.aws.amazon.com/rss/autoscaling-us-east-1.rss
Ломается, именно об этом и пишут в SLA. Поломается, бизнес недополучит прибыль, провайдер компенсирует(так или иначе). И отлично в огромном количестве бизнесов.


C>Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.
На уровне api gateway синтегрировав с мониторингом.

C>Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?
Я уже несколько раз писал, читать, как я уже понял, ты не умеешь. Давай попробую зайти с другой стороны: по разному, в зависимости от конкретных требований.

C>Да-да. И в спецификации, конечно, написано: "Можно ломаться и терять данные, если клиенты делают слишком много запросов". Если у вас там такие спецификации, то могу только посочувствовать.
Прикинь, в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.
Скажи, если каждый десятый пакет данных потеряется(т.е. раз в 10 секунд у нас не будет положения самолета), это вообще важно для данного сервиса?
А если это специализированный софт для диспетчеров посадки? В обоих случаях надо одинаков решать задачу, как думаешь?

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

C>Основной метод продажи этих Tibco выглядит так: продажник приходит и говорит, что если клиент купит Tibco/Oracle/whatever, то у него магически увеличится член число девяток надёжности. При этом в контракте прописаны зверские штрафные санкции за нарушения этого — возврат абонентской платы за последний месяц.

Мне вот интересно, ты и вправду считаешь покупателей подобных решений полными дибилами, которым продают полный неликвид на протяжении чуть ли не десятилетий,

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

I>Ну я еще парочку накину:
I> — буферизирование пиковой нагрузки
I> — интеграция разнородных систем
I> — обеспечение high availability + guaranteed delivery

Может наш случай и нетипичный но мы очереди использовали тоже в основном для guaranteed delivery, и в расчете на скейлинг с подъемом инстансов, да.
Малонагруженная бизнес-система на микросервисах в AWS. Для postmortem и мониторинга dlq, throttling gRPC. Возвращаясь к оригинальному посту, Сhoreography в какой-то момент стала напрягать и решили делать pub-sub service https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern (комбинируя pull семантику SQS и push с мультикастом в SNS) в итоге получается что все сервисы завязаны на один, что вроде как к Orchestration приближает

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

A>Может наш случай и нетипичный но мы очереди использовали тоже в основном для guaranteed delivery, и в расчете на скейлинг с подъемом инстансов, да.
Дык ет и есть нормальное использование очередей.У сайберакса просто немножко другой кейс: если бекенд поломался, то пользователи жмут 'ретрай' много раз, идет дубликация сообщений в очередь, часть сообщений устаревает и дальше коллапс. Вот он и придумал(точней ему придумал, он руку приложил к реализации наверное) тротлинг на отправке сообщений и велосипедный circuit breaker. Может и правильно для конкретно его случая, без требований непонятно.

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

I>Ломается, именно об этом и пишут в SLA. Поломается, бизнес недополучит прибыль, провайдер компенсирует(так или иначе). И отлично в огромном количестве бизнесов.
Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.

C>>Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.
I>На уровне api gateway синтегрировав с мониторингом.
Ещё раз, мониторинг позволит (максимум) обнаружить аварийную ситуацию. Он не позволит её исправить.

Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???

C>>Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?
I>Я уже несколько раз писал, читать, как я уже понял, ты не умеешь. Давай попробую зайти с другой стороны: по разному, в зависимости от конкретных требований.
Ну вот объясни. Требования я привёл.

I>Прикинь, в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.
Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.

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

I>Мне вот интересно, ты и вправду считаешь покупателей подобных решений полными дибилами, которым продают полный неликвид на протяжении чуть ли не десятилетий,
Да, именно так я и считаю. И сколько раз уже на практике проверил.

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

C>Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.
Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.

C>Ещё раз, мониторинг позволит (максимум) обнаружить аварийную ситуацию. Он не позволит её исправить.
C>Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???
Ты не понимаешь задачи и возможности мониторинга. Вообще.

C>Ну вот объясни. Требования я привёл.
Если то что ты привел — это требования, то не тебя жаль. Вот так навскидку и не читая реальных требований, я бы начал бороться с дубликатами и резким ростом нагрузки еще на client-side и тупо бы не отправлял бы эти дубликаты(там как раз их вычислить — плевое дело). Там же имитировал бы circute breaker/increase timeouts в случаях если что-то пошло не так. Ну вот так навскидку, повторяюсь, исходя из того минимума что я знаю.

C>Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.
Нет. Очереди пригодны fire-ensure in delivery-and forget вещей. Сервис басы пригодны для более широких применений.

C>Ну вот сообщения не пригодны даже для молотка.
Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что. Это очень смелое заявление. Не, я понимаю у тебя оно с кнопкой 'checkout shopping bag' не взлетело по каким-то причинам, но нельзя же все задачи программирования натягивать на кнопку checkout?

C>Да, именно так я и считаю. И сколько раз уже на практике проверил.
Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.

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

C>>Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.
I>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.
Ага. Ну вот смотрим SQS SLA. Упс. А его нету.

Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.

Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.

C>>Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???
I>Ты не понимаешь задачи и возможности мониторинга. Вообще.
Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.

Чем мониторинг должен помочь?

C>>Ну вот объясни. Требования я привёл.
I>Если то что ты привел — это требования, то не тебя жаль. Вот так навскидку и не читая реальных требований, я бы начал бороться с дубликатами и резким ростом нагрузки еще на client-side и тупо бы не отправлял бы эти дубликаты(там как раз их вычислить — плевое дело).
Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.

Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.

I>Там же имитировал бы circute breaker/increase timeouts в случаях если что-то пошло не так. Ну вот так навскидку, повторяюсь, исходя из того минимума что я знаю.
То есть? Я не понимаю что это значит в данном контексте. Очередь сообщений ни к каким таймаутам непричастна, сообщения туда штатно кладутся с обычной задержкой.

C>>Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.
I>Нет. Очереди пригодны fire-ensure in delivery-and forget вещей. Сервис басы пригодны для более широких применений.
Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.

C>>Ну вот сообщения не пригодны даже для молотка.
I>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.
Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).

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

C>>Да, именно так я и считаю. И сколько раз уже на практике проверил.
I>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
Principal engineer.

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

I>>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.
C>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.
А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:

Q: Does Amazon SQS guarantee delivery of messages?

Standard queues provide at-least-once delivery, which means that each message is delivered at least once.

FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.

А вот мелкософт дает полноценный sla на свой azure service bus.

C>Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.
Это всего лишь говорит о том, что всех все устраивает. Это бизнес и ничего более. Как только в амазон начнет регулярно фейлить sla и это начнет приводить к существенным убыткам клиентов — бизнес мигрирует в ажур или куда там еще. Как только это станет трендом, акции амазона пойдут вниз(или не будут показывать прогнозируемого роста), акционеры вставят пистон CEO, он начнет исправлять ситуацию тем или иным способом(улучшать качество, снижать цену, увеличивать штрафные санкции за даунтайм...) как то так оно и работает.

C>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.
А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?

C>Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.
C>Чем мониторинг должен помочь?
Если твой мониторинг для твоего супер нагруженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.

C>Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.
Таки у тебя определенные проблемы с чтением. Не будет дубликатов — очередь не будет распухать, существующие сообщения не будут "протухать".
Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".

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

C>Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.
Я тебе еще раз повторяю, все зависит от контекста. 99.99% бекенд сервисов написаны в десятки(если и сотни) раз менее стабильными, доступными, надежными чем тот же sqs. Переписывать их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.

I>>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.
C>Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).
Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).

C>Сами по себе асинхронные системы вполне себе нормально живут. Но даже там их лучше применять только для некритичных по времени вещей.
Наконец то хоть какие то проблески понимания что "а у людей может быть и не такие задачи как у меня"

I>>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
C>Principal engineer.
Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился, а может тебе оно и не сильно нужно.

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

C>>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.
I>А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:
Не гарантируют. В случае падений SQS сообщения ещё как теряются, хотя они в последнее время исправились и падать почти перестали.

I>А вот мелкософт дает полноценный sla на свой azure service bus.
Аж 25% скидки за последний месяц. Прямо как санкции против Северной Кореи по своей жестокости.

C>>Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.
I>Это всего лишь говорит о том, что всех все устраивает. Это бизнес и ничего более.
Именно так. И никакие Tibco не дадут существенно лучший SLA, потому нечего на него кивать.

C>>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.
I>А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?
У меня есть данные от нескольких очень крупных падений Oracle, с многомиллионными убытками. Во всех случаях Oracle не заплатил напрямую ничего. Про Tibco аналогично слышал из первых рук, но сам не присутствовал.

C>>Чем мониторинг должен помочь?
I>Если твой мониторинг для твоего супер нагруженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.
Что она даст, если критические компоненты не работают? Куда будет disaster recovery, если состояние системы неопределенное из-за того, что очередь сообщений скопытилась?

C>>Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.
I>Таки у тебя определенные проблемы с чтением. Не будет дубликатов — очередь не будет распухать, существующие сообщения не будут "протухать".
В моём примере очередь распухает не из-за дубликатов, а из-за того, что уникальные обращения перестают обрабатываться.

I>Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".
Как это будет выглядеть на уровне API для клиентов?

C>>Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.
I>Еще как поможет, разгребет потихоньку если входной поток ограничить как я описал выше.
А нафиг он тогда нужен? Не проще ли использовать синхронные вызовы?

I> их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.
А бэкэнд всё равно должен быть надёжен, так как иначе никакие 100500 девяток в SLA не помогут.

C>>Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).
I>Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).
В случае с синхронным вызовом состояние системы не хранится в сетевом соединении, кроме как для статуса последнего запроса.

I>Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился, а может тебе оно и не сильно нужно.
Это очень прокачанный сеньор. И как раз на системы клиентов и внутренние системы Amazon'а я насмотрелся вдоволь.