Сообщение Re[3]: Микросервисы маршрутизация от 15.08.2017 0:03
Изменено 15.08.2017 3:19 Cyberax
Re[3]: Микросервисы маршрутизация
Здравствуйте, Sharov, Вы писали:
C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.
Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.
Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).
В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.
Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.
C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.
Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.
Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).
В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.
Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.
Re[3]: Микросервисы маршрутизация
Здравствуйте, Sharov, Вы писали:
C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.
Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.
Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).
В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.
В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.
Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.
C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.
Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.
Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).
В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.
В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.
Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.