Здравствуйте, Gattaka, Вы писали:
G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию?
Из личного опыта:
0) А может нафиг микросервисы не нужны?
1) Все эти ESB и мега-оркестраторы сосут. Очень глубоко сосут.
2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.
Здравствуйте, Cyberax, Вы писали:
C>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.
Даже нашелся кандидат, который не сосет. Это прекрасно.
Почитал доку по диагонале. Я правильно понимаю, что персистентность он не предоставляет, доставку — не гарантирует, очередность доставки — не гарантирует?
Здравствуйте, Cyberax, Вы писали:
C>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.
Пользовались? Мультиплексирование запросов (несколько запросов в рамках одного TCP соединения) делать умеет?
Здравствуйте, scf, Вы писали:
scf>Пользовались? Мультиплексирование запросов (несколько запросов в рамках одного TCP соединения) делать умеет?
Если умеет — т оето трипл фейспалм. Потому как ето задача транспортного уровня и уже решена в http/2
Который кстате худо-бедно сапортят многие веб сервера.
Здравствуйте, itslave, Вы писали:
I>Если умеет — т оето трипл фейспалм. Потому как ето задача транспортного уровня и уже решена в http/2 I>Который кстате худо-бедно сапортят многие веб сервера.
HTTP/1.1 pipelining (ссылку на который вы прислали) не панацея, т.к. он фиксирует порядок получения ответов на запросы:
8.1.2.2 Pipelining
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
http/2 java-клиенты и серверы еще сырые. Это слишком новая технология, чтобы на нее завязываться. grpc, кстати, использует http/2 в качестве протокола и многие жаловались на разнообразные проблемы с ним. К тому же, http/2 сложнее и нужно изучать использование цпу и памяти под нагрузкой — http/1.1 может оказаться дешевле.
Здравствуйте, scf, Вы писали:
scf>HTTP/1.1 pipelining (ссылку на который вы прислали) не панацея, т.к. он фиксирует порядок получения ответов на запросы:
Фейспалм, промазал. Правильная ссылка и цитата:
Multiplexing multiple requests over a single TCP connection
scf>http/2 java-клиенты и серверы еще сырые. Это слишком новая технология, чтобы на нее завязываться. grpc, кстати, использует http/2 в качестве протокола и многие жаловались на разнообразные проблемы с ним.
Я далек от мира джавы, и не могу не отметить, чт оу нас топик про микросервисы. Которыеподразумевают использвание разных технологических стеков и интеграцию на уровне http контрактов
scf>К тому же, http/2 сложнее и нужно изучать использование цпу и памяти под нагрузкой — http/1.1 может оказаться дешевле.
Любую новую технологию надо изучать и тестировать. Но технологию, которая гарантированно будет стандартом, изучать и тестировать гораздо проще чем самодельный велосипед.
Здравствуйте, itslave, Вы писали:
C>>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга. I>Даже нашелся кандидат, который не сосет. Это прекрасно.
Он тоже сосёт, но немного меньше, чем альтернативы.
I>Почитал доку по диагонале. Я правильно понимаю, что персистентность он не предоставляет, доставку — не гарантирует, очередность доставки — не гарантирует?
Нет, это не система сообщений. Это система для коммутации микросервисов.
Здравствуйте, scf, Вы писали:
C>>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга. scf>Пользовались? Мультиплексирование запросов (несколько запросов в рамках одного TCP соединения) делать умеет?
Да, пользовались. Мультиплексирование — не нужно в принципе, кроме как для клиентских приложений на всяких мобильниках.
Здравствуйте, Cyberax, Вы писали:
C>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему. C>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
Здравствуйте, Sharov, Вы писали:
C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему. C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно. S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.
Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.
Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).
В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.
В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.
Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.
Здравствуйте, Cyberax, Вы писали:
C>Он тоже сосёт, но немного меньше, чем альтернативы.
Ну как то же умудряются люди делать распределенные системы, которые не сосут, или кака минимум не всегда сосут.
Один из возможных вариантов как им это удается — четенько работают с реквариментами и подбирают решение конкретной задачи, а не заявляют "все сосут, кроме вот этой библиотеки, которая ничего не умеет кроме как логировать сетевые вызовы и показывает лиги на админке".
C>Нет, это не система сообщений. Это система для коммутации микросервисов.
То есть ее применимость очень сильно ограничена, целый ряд проблем коммуникации она не решает в принципе. Понятно.
Здравствуйте, Cyberax, Вы писали:
C>Да, пользовались. Мультиплексирование — не нужно в принципе, кроме как для клиентских приложений на всяких мобильниках.
А пацаны то и не знают, наверное от нефиг делать пихают мультиплексирование в следующий стандарт хттп. Они тоже наверное сосут.
Здравствуйте, 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 выше чем у поставщиков-потребителей этой очереди.
Здравствуйте, itslave, Вы писали:
C>>Да, пользовались. Мультиплексирование — не нужно в принципе, кроме как для клиентских приложений на всяких мобильниках. I>А пацаны то и не знают, наверное от нефиг делать пихают мультиплексирование в следующий стандарт хттп. Они тоже наверное сосут.
Я выделил. Ещё мультиплексирование имеет смысл для Web'а, чтобы сразу несколько запросов на ресурсы отправлять по одному каналу и получать сразу несколько ответов.
Для интер-сервисной коммуникации это нафиг не нужно.
Здравствуйте, itslave, Вы писали:
C>>Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности. I>Можно и делают. Ессна ж ни разу не силвер баллет, но диапазон применимости достаточно широк.
Я видел даже реализации аналогов TCP на сообщениях, с flow control и прочим. Это не значит, что это хорошая идея.
Пока я для себя нашёл два нормальных применения очередей:
1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
C>>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут). I>Нормальные очереди дизайнят так, чтобы они были I> — безразмерными I> — не тормознутыми I> — гарантировали высокий SLA по авайлабилити
Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.
I>При таких вводных, вероятность описанного сценария минимальна(а все в распределенных системах упирается в вероятности в конечном итоге), зато позволяет тротлить нагрузку на бекенд и мониторить логически развязать фронтенд и бекенд(что помимо всего прочего, позволяет делать 0-downtime update для бекенда).
Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.
C>>В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло. I>Вопрос исключительно к мониторингу и агрегации логов.
У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
C>>В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик. I>Как я уже отметил выше — retries + dlq лечит такие варианты. Хотя перфоманс может деградировать, если ретраев больше нуля(те не слать месседж в dlq при первой же ошибке).
Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.
Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.
C>>Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать. I>Все упирается в SLA. Зачастую очереди — распределенные системы, с SLA выше чем у поставщиков-потребителей этой очереди.
Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
Здравствуйте, itslave, Вы писали:
C>>Он тоже сосёт, но немного меньше, чем альтернативы. I>Ну как то же умудряются люди делать распределенные системы, которые не сосут, или кака минимум не всегда сосут.
Так и делают — минимизируют внешние зависимости, делают всё как можно проще, продумывают динамическое поведение под нагрузкой, уменьшают возможный blast radius при отказе компонентов и т.п.
ЧСХ, варианты: "А давайте возьмём Tibco/Oracle/ZMQ, у которых ВООООООООООТ ТАКОЙ!!! SLA", — заканчиваются обычно провалом.
Если что, мой код работает в системе, которая обслуживает 2 миллиона (5 миллионов в пике) запросов в секунду. Другая моя (на 100%) система обслуживает "всего" 20000 запросов в секунду.
I>Один из возможных вариантов как им это удается — четенько работают с реквариментами и подбирают решение конкретной задачи, а не заявляют "все сосут, кроме вот этой библиотеки, которая ничего не умеет кроме как логировать сетевые вызовы и показывает лиги на админке".
Некоторые вещи практически неизменны, вне зависимости от требований.
C>>Нет, это не система сообщений. Это система для коммутации микросервисов. I>То есть ее применимость очень сильно ограничена, целый ряд проблем коммуникации она не решает в принципе. Понятно.
То что она не решает — не нужно (тм).
Здравствуйте, Cyberax, Вы писали:
C>Я выделил. Ещё мультиплексирование имеет смысл для Web'а, чтобы сразу несколько запросов на ресурсы отправлять по одному каналу и получать сразу несколько ответов.
Тоесть не тлько для мобил, а еще и для обыкновенных веб сатов. Ок, с этим пожалуй соглашусь и не буду углубляться в детали.
C>Для интер-сервисной коммуникации это нафиг не нужно.
Опять таки, смотря какие данные там передаются. в большинстве случаев — не надо, а если это (почти) сплошной поток мелких данных с критичным временем обработки(например котировки акций), то мультиплицирование(в том или ином виде) здесь более чем необходимо.
Здравствуйте, 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%, только ведь всё равно всё упадёт.
Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
Здравствуйте, Cyberax, Вы писали:
C>ЧСХ, варианты: "А давайте возьмём Tibco/Oracle/ZMQ, у которых ВООООООООООТ ТАКОЙ!!! SLA", — заканчиваются обычно провалом.
Кэп подсказывает, что раз tibco/oracle/biztalk/zmq — коммерчески успешные проекты на протяжении многих лет, то твое утверждение неверно.
C>Если что, мой код работает в системе, которая обслуживает 2 миллиона (5 миллионов в пике) запросов в секунду. Другая моя (на 100%) система обслуживает "всего" 20000 запросов в секунду.
Пошло членомеряние. С горизонтальным масштабирование после 5х инстансов количество запросов не имеет значения. Ну и давай я отмечу, что у меня свежий бизнес кейс — обработать внезапную балковую заливку +- 10 млн картинок в спец формате на S3 и сгенерить из них видео, предварительно трансформировав и это делается за несколько часов на одном дешевом инстансе. Вариантов оптимизации на порядки — валом, но она не нужна потому что бизнес устраивает эта производительность.
I>>Один из возможных вариантов как им это удается — четенько работают с реквариментами и подбирают решение конкретной задачи, а не заявляют "все сосут, кроме вот этой библиотеки, которая ничего не умеет кроме как логировать сетевые вызовы и показывает лиги на админке". C>Некоторые вещи практически неизменны, вне зависимости от требований.
Все твои посты просто кричат о твоем (возможно)глубоком, но узком опыте. Ты абсолютно все задачи подгоняешь под свои шаблоны и исходя из них пытаешься решить ультимативно и безапелляционно. Дык от. Это глупо. Мир гораздо многообразней и далеко не всем нужны сообщениядробилки.
Если бы ты окунулся, к примеру, в типичный ентенпрайз то ужаснулся бы от зоопарка сервисов, разрабатываемых десятилетиями, обособленными командами с плохой инженерной культурой, легаси ужасом. Там банально поле невозможно добавить в xml без 125 согласований. Мне как то раз доступ к тестовому серваку полгода открывали. Тут ESB очень сильно помогает с организационной точки.
Есть еще IoT, где большой поток входных сообщений надо буферизировать и потери единичных приемлимы.
Есть просто необходимость частых релизов и это пытаются порешать микросервисами...
В общим задачи бывают совершенно разные, а серебряной пули до сих пор не придумали. Поентому я бы на твоем месте бы не утверждал бы настолько ультимативно про "практически неизменные вещи"
C>То что она не решает — не нужно (тм).
Как я уже отметил выше, узость твоего видения мира не позволяет тебе адекватно оценивать как разнообразие задач, так и методов их решения.
Здравствуйте, itslave, Вы писали:
C>>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях. I>Ну я еще парочку накину: I> — буферизирование пиковой нагрузки
ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.
I> — интеграция разнородных систем I> — обеспечение high availability + guaranteed delivery
Ещё хуже.
I>Но это далеко не полный список, уверяю тебя
Ну так плохих идей вообще очень много.
I>Пусть ломается, надо делать нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.
И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.
C>>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением? I>Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
Проблема в том, что если сообщения вызывают изменение чего-то, то при пропуске одного сообщения не очень понятно итоговое состояние.
C>>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная. I>Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.
I>Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.
Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.
Кстати, эта проблема как раз может решаться ограничением максимальной глубины очереди.
C>>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт. I>Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
Производители себе не враги, и никакие серьёзные последствия для них не последуют.
