Сообщение Re[6]: Микросервисы маршрутизация от 15.08.2017 13:35
Изменено 15.08.2017 13:52 itslave
Re[6]: Микросервисы маршрутизация
Здравствуйте, Cyberax, Вы писали:
C>Пока я для себя нашёл два нормальных применения очередей:
C>1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
C>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
Ну я еще парочку накину:
— буферизирование пиковой нагрузки
— интеграция разнородных систем
— обеспечение high availability + guaranteed delivery
Но это далеко не полный список, уверяю тебя
C>Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.
Пусть ломается, надо делать мониторинг нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.
C>Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.
Если выделенное — это просто фигура речи интернет бойца, то ради бога. В реале же это гарантированный путь к инвалидности. И что самое интересное — я в принципе двумя руками поддерживаю твой посыл не строить распределенных систем пока совсем не припечет, но выражения, которыми ты его доносишь, резкость как у газировки и ультимативность спермотоксикозной школоты — детский сад.
C>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
C>Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.
C>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.
C>DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.
И так тоже dlq можно использовать.
C>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
C>Пока я для себя нашёл два нормальных применения очередей:
C>1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
C>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
Ну я еще парочку накину:
— буферизирование пиковой нагрузки
— интеграция разнородных систем
— обеспечение high availability + guaranteed delivery
Но это далеко не полный список, уверяю тебя
C>Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.
Пусть ломается, надо делать мониторинг нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.
C>Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.
Если выделенное — это просто фигура речи интернет бойца, то ради бога. В реале же это гарантированный путь к инвалидности. И что самое интересное — я в принципе двумя руками поддерживаю твой посыл не строить распределенных систем пока совсем не припечет, но выражения, которыми ты его доносишь, резкость как у газировки и ультимативность спермотоксикозной школоты — детский сад.
C>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
C>Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.
C>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.
C>DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.
И так тоже dlq можно использовать.
C>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
Re[6]: Микросервисы маршрутизация
Здравствуйте, Cyberax, Вы писали:
C>Пока я для себя нашёл два нормальных применения очередей:
C>1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
C>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
Ну я еще парочку накину:
— буферизирование пиковой нагрузки
— интеграция разнородных систем
— обеспечение high availability + guaranteed delivery
Но это далеко не полный список, уверяю тебя
C>Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.
Пусть ломается, надо делать нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.
C>Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.
Если выделенное — это просто фигура речи интернет бойца, то ради бога. В реале же это гарантированный путь к инвалидности. И что самое интересное — я в принципе двумя руками поддерживаю твой посыл не строить распределенных систем пока совсем не припечет, но выражения, которыми ты его доносишь, резкость как у газировки и ультимативность спермотоксикозной школоты — детский сад.
C>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
C>Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.
C>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.
C>DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.
И так тоже dlq можно использовать.
C>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
C>Пока я для себя нашёл два нормальных применения очередей:
C>1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
C>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
Ну я еще парочку накину:
— буферизирование пиковой нагрузки
— интеграция разнородных систем
— обеспечение high availability + guaranteed delivery
Но это далеко не полный список, уверяю тебя
C>Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.
Пусть ломается, надо делать нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.
C>Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.
Если выделенное — это просто фигура речи интернет бойца, то ради бога. В реале же это гарантированный путь к инвалидности. И что самое интересное — я в принципе двумя руками поддерживаю твой посыл не строить распределенных систем пока совсем не припечет, но выражения, которыми ты его доносишь, резкость как у газировки и ультимативность спермотоксикозной школоты — детский сад.
C>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
C>Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.
C>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.
C>DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.
И так тоже dlq можно использовать.
C>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.