Интересный кейс от Uber с реализацией механизма обработки ошибок запросов, во многом похожий на паттерн Circuit Breaker.
Отличие от CB в том, что основная цель не просто временно прекратить проблемные запросы, а продолжить отправлять запросы на лучший из доступных доменов.
Ряд доменов у Uber нацелены на прокси сервера в из облачной инфраструктуре, которая распределена по разным регионам, основным доменом для приложения считается ближайший, в запасных есть и другие прокси домены, и домен, который смотрит напрямую в дата-центр Uber.
Вся edge инфраструктура дает профит в скорости установления TLS соединения, меньше задержек и ошибок у HTTPS трафика, плюс так как это обычно популярные cloud сервисы, на них могут использоваться современные протоколы (привет, QUIC!)
В статье рассказано про то, как сложно понять что произошла именно ошибка связанная с проблемами доступа к хосту, что-то уровня DNS / TCP, таймауты запросов, но не такие ошибки, как отсутствие связи в тоннеле, или ошибки непосредственно от API.
Основная часть статьи - описание механизма, который отвечает за то, что бы запросы всегда уходили на самый подходящий хост, но умели использовать запасные, плюс различные графики, измеряющие профит.
Не буду все подробно переводить, но на верхнем уровне, этот механизм - симпатичная стейт-машина, где все состояния стремятся к основному, когда используется лучший домен, т.е. система стабильна.
Для проверки доменов отправляются запросы на health эндпоинте.
https://eng.uber.com/eng-failover-handling/
Отличие от CB в том, что основная цель не просто временно прекратить проблемные запросы, а продолжить отправлять запросы на лучший из доступных доменов.
Ряд доменов у Uber нацелены на прокси сервера в из облачной инфраструктуре, которая распределена по разным регионам, основным доменом для приложения считается ближайший, в запасных есть и другие прокси домены, и домен, который смотрит напрямую в дата-центр Uber.
Вся edge инфраструктура дает профит в скорости установления TLS соединения, меньше задержек и ошибок у HTTPS трафика, плюс так как это обычно популярные cloud сервисы, на них могут использоваться современные протоколы (привет, QUIC!)
В статье рассказано про то, как сложно понять что произошла именно ошибка связанная с проблемами доступа к хосту, что-то уровня DNS / TCP, таймауты запросов, но не такие ошибки, как отсутствие связи в тоннеле, или ошибки непосредственно от API.
Основная часть статьи - описание механизма, который отвечает за то, что бы запросы всегда уходили на самый подходящий хост, но умели использовать запасные, плюс различные графики, измеряющие профит.
Не буду все подробно переводить, но на верхнем уровне, этот механизм - симпатичная стейт-машина, где все состояния стремятся к основному, когда используется лучший домен, т.е. система стабильна.
Для проверки доменов отправляются запросы на health эндпоинте.
https://eng.uber.com/eng-failover-handling/