(java || kotlin) && devOps
369 subscribers
6 photos
1 video
6 files
306 links
Полезное про Java и Kotlin - фреймворки, паттерны, тесты, тонкости JVM. Немного архитектуры. И DevOps, куда без него
Download Telegram
На Highload услышал упоминание про timeout propagation и вспомнил, что давно хотел эту тему поднять.
В чем суть - где-то настроен timeout, и для того, чтобы upstream сервисы знали про него - мы передаём его в заголовках, также как и traceId. Наилучшее место для создания этих заголовков - входной шлюз. Или API Gateway - именно так сделали в Avito. Передать таймуат можно двумя способами - как длительность, X-Timeout = 5s или как время - X-Deadline: 06.12.2024 14:55:45. Второй вариант проще обрабатывать на upstream серверах, т.к. не нужно вычислять сколько из первоначального таймаута осталось, но требуется синхронизация времени на всех серверах.

Казалось бы - добавили таймаут, пробросили по цепочке, сервисы знают дедлайн и могут прервать обработку и не тратить лишние ресурсы, если результат уже не нужен. Вот он профит.

Но возникает вопрос - будут ли его использовать? Как это проконтролировать? К тому же не каждый процесс можно прерывать. На первый взгляд можно операции чтения - ведь клиент уже не прочитает данные, соединение прервется выше по цепочке. Но возможно имеет смысл вернуть клиенту хоть что-то - или fallback ответ, или часть ответа, которую успели подготовить. И вернуть чуть раньше дедлайна, чтобы запрос успел дойти до клиента. Т.е. в общем случае задачу автоматически решить кажется можно, но нужен фреймворк и его внедрение по всей цепочке сервисов. Причём фреймворк, работающий поверх существующих контроллеров и клиентов.

#reliability #timeout