Как справиться с долго работающим нестабильным сервером

Question

У нас старая нестабильная монолитная система, 95% запросов обрабатываются в течение 500 мс, а остальные 5% требуют> 10 с и время ожидания соединения.Я хотел бы сделать наш сервис более устойчивым.Обмен данными осуществляется через REST, а архитектура выглядит следующим образом: .

Наш текущий подход заключается в использовании асинхронного http-клиента с экспоненциальным механизмом повторных попыток отката.Но это приведет к проблемам с производительностью при увеличении трафика

Моя идея состоит в том, чтобы сделать синхронный вызов http в S с тайм-аутом 500 мс и резервным методом, который добавляет задачу в очередь для повторной попытки запроса http вв будущем, при возврате 202 на C вместе со ссылкой для проверки состояния задачи, например, /queue/task-123.Я знаю, что мне нужно сделать так, чтобы S предоставлял сервис C идемпотенту, поэтому мне придется проверять очередь каждый раз, когда я получаю новый запрос от C, чтобы убедиться, что у меня нет повторяющихся задач.

Вопросы:

1. Есть ли лучший подход для решения моей проблемы?
2. Является ли задача в очереди лучшим способом обработки повторных попыток в конечной точке REST?

Наш стек: Java, использующая загрузку Spring, и для очереди, я думаю, RabbitMQ

Answer 1

Попросите S создать Futures для AsyncHttpResponse и отправить их Исполнителю с пулом потоков, достаточно большим, чтобы вместить вашу нагрузку, но не настолько высоким, чтобы он затопил ваш Монолит.Таким образом, когда что-то пойдет не так, это не приведет к снежному кому, а другие запросы могут встать в очередь.В этой модели все еще может быть модель повторов, но ее можно контролировать вне будущего, чтобы позволить поступать успешным запросам до повторных попыток.