Мы живем в мире микросервисов. Микросервисы помогают нам разрушать монолиты и увеличивать масштабы наших команд, но есть минус; некоторые службы могут быть недоступны при доступе. Да, у нас могут быть причудливые архитектуры, чтобы смягчить это, но в конечном итоге это случается.
Мы предлагаем автономный режим для нашего флагманского продукта (Bloom), и для этого нам необходимо сохранить часть данных наших клиентов на их устройствах. Мы получаем необходимые данные из наших различных сервисов.
Мы выбрали оптимистичный подход: когда служба работает, все в порядке, но когда служба не работает, качество обслуживания ухудшается.
Неоднократно мы замечали, что всякий раз, когда служба не возвращала код состояния 200, загрузка завершалась, и пользователи жаловались, что она зависла, и мы просили их нажать кнопку обновления. Это не лучший подход, поскольку мы можем выявлять ошибки и обрабатывать их в фоновом режиме, не мешая взаимодействию с пользователем.
Таким образом, мы пришли к выводу, что, когда служба возвращает код состояния от 400 до 599 , мы предполагаем, что служба работает локомотивом, и через некоторое время (5–30 секунд) пытаемся повторить попытку и надеемся, что в большинстве случаев на самом деле он возвращает 200.
Вот некоторые из эффектов, которые мы хотели достичь, в произвольном порядке.
- Получить конкретный ресурс
- Если запрос выполнен успешно, перейдите к следующему
- Если запрос не выполняется, спите определенное время и повторите шаг 1 еще раз.
2. Настройте такие параметры, как время ожидания, отсутствие повторных попыток и т. Д.
3. Повторно используйте код для всех ресурсов, которые нам нужно загрузить, чтобы обеспечить максимальное удобство работы в автономном режиме.
Вот фрагмент кода с комментариями.
Такой подход значительно улучшил наш пользовательский опыт.
Спасибо за чтение, надеемся, что вы узнали что-то новое. Пожалуйста, оставьте свой отзыв в разделе комментариев.
