Я запускаю приложение на AWS Elastic Beanstalk. Если экземпляр отвечает слишком часто кодом состояния HTTP в диапазоне 500 (ошибка сервера), AWS помечает этот экземпляр как неисправный и удаляет его из балансировщика нагрузки.
Я понимаю это и согласен с тем, что это действительно хорошее поведение. Но, к сожалению, это приводит к проблемам с моим приложением.
Моему приложению необходимо подключиться к нескольким внешним API и агрегировать их данные. Один из внешних API, который не находится под моим контролем, нестабилен и довольно часто отвечает кодом состояния 500.
В настоящий момент, если API вызывает ошибку, мое приложение просто передает эту ошибку обратно пользователю. Причина мышления AWS мой в приложении произошла ошибка, поэтому этот экземпляр был прерван, а новый сервер запущен. Но на самом деле это только одна конечная точка, вызывающая постоянную скорость 500 ошибок, тогда как все остальные конечные точки все еще в порядке.
С одной стороны, правильно, что ошибка внешнего сервера заставляет мое приложение просто возвращать эту ошибку. С другой стороны, такой ошибки внешнего сервера нет в мой приложение, и я смог его поймать. Но даже если я поймаю ошибку, я не смогу вернуть что-либо полезное для пользователя, и поэтому мне все равно нужно вернуться с кодом ошибки.
Как с этим справиться? Избегать кодов состояния ошибки сервера, чтобы не запускать нездоровые экземпляры, но в то же время не использовать код состояния ошибки клиента, потому что пользователь ничего не может сделать, ему просто нужно повторить попытку?
Что ты предлагаешь? Или есть еще один вариант тонкой настройки поведения AWS Elastic Beanstalks?
В основном вопрос заключается в следующем: когда запросы к этому API терпят неудачу, требует ли рабочий процесс вашего приложения, чтобы ваши клиенты / пользователи
а) быть уведомленным об этом
б) необходимо предпринять последующие действия
c) является ли ответ об ошибке HTTP единственным способом уведомить об этом?
Если да, то подумайте, когда удаленный API генерирует внутреннюю ошибку сервера 500, чтобы ваше приложение возвращало ответ с ошибкой 408, что в некоторой степени уместно, поскольку позволяет клиенту повторно отправить тот же запрос в более поздний момент. ("502 Bad Gateway" был бы лучше, если бы не ограничение ниже :)
Дополнительно вы можете настроить расширенные правила здоровья в Elastic Beanstalk, где вы указываете эластичному бобовому стеблю игнорировать ошибки 4xx как свидетельство плохого состояния здоровья. К сожалению, на момент написания вы не могли сделать то же самое для 5xx или даже более конкретных кодов статуса http.