Запрос проходит через несколько сервисов, но внутренние таймауты суммарно превышают клиентский дедлайн. Как передача единого дедлайна по цепочке предотвращает бесполезную работу?
Передача дедлайна позволяет каждому участнику видеть оставшееся время до момента, когда результат уже не будет полезен клиенту. Сервис прекращает или не начинает работу, если оставшегося бюджета недостаточно, поэтому не тратит ресурсы на заведомо просроченный ответ.
Это отличается от независимых таймаутов: их сумма может значительно превысить клиентский дедлайн. Единый дедлайн ограничивает сквозное время запроса, но сам по себе не отменяет уже выполненные побочные эффекты и не гарантирует мгновенное прекращение работы.
В распределённых системах один пользовательский запрос часто проходит через несколько последовательно или параллельно вызывающих друг друга компонентов. Изначально каждый компонент нередко настраивал собственный фиксированный таймаут, не зная ограничений всего пользовательского запроса.
Такой подход приводил к накоплению ожиданий: зависимость могла продолжать работу после того, как клиент уже получил ошибку или прекратил ожидание. Дедлайны появились как способ передать ограничение на сквозное время и согласовать поведение всей цепочки.
Пусть клиент готов ждать ответ только ограниченное время. Если первый сервис ждёт зависимость дольше этого срока, а зависимость затем ждёт ещё одну систему, запрос может завершиться для клиента, пока серверная цепочка продолжает потреблять потоки, соединения, CPU и другие ресурсы.
Фиксированные таймауты также создают неверные решения на промежуточных этапах. Сервис может начать дорогую операцию, хотя оставшегося времени недостаточно даже для её завершения и передачи результата обратно.
Продолжение такой работы увеличивает конкуренцию за ресурсы и может ухудшить задержку полезных запросов. Особенно опасна ситуация, когда просроченные операции создают новые запросы или занимают ограниченные рабочие пулы.
Дедлайн следует представлять как абсолютный момент времени, к которому весь запрос должен завершиться. Каждый сервис вычисляет оставшееся время как разницу между этим моментом и текущим временем, затем использует его как верхнюю границу для вызова зависимости и локальной обработки.
Если оставшегося времени недостаточно для минимально полезной работы, сервис должен быстро отказать, вернуть деградированный результат или выбрать более дешёвый путь. При вызове зависимости он передаёт тот же дедлайн либо эквивалентный ему оставшийся бюджет, а не новый независимый полный таймаут.
При параллельных вызовах общий дедлайн сохраняется для всех ветвей. После получения достаточного результата необязательные ветви можно отменить, но отмена должна поддерживаться всей цепочкой: прекращение ожидания на верхнем уровне не всегда автоматически останавливает уже выполняющуюся работу ниже.
Дедлайн не равен гарантии отката. Если операция уже изменила состояние, отказ от ожидания ответа не отменяет этот побочный эффект. Для повторяемых или финансово значимых действий нужны идемпотентность, явная модель подтверждения и, при необходимости, отдельная асинхронная обработка.
Важно учитывать рассинхронизацию часов при передаче абсолютного времени между машинами. На практике протокол может передавать оставшийся бюджет с запасом, а сервис должен применять локальные ограничения на максимальную продолжительность операции. Дедлайн также не должен быть единственным механизмом защиты: нужны лимиты конкуренции, отмена, наблюдаемость и контроль очередей.
Платформа формирует страницу из профиля пользователя, рекомендаций и истории заказов. При проблемах с историей заказов верхний сервис уже возвращает страницу после клиентского таймаута, но нижний сервис продолжает обращаться к базе и удерживает рабочие ресурсы.
Рассматривались три варианта. Увеличение таймаутов у нижних сервисов упрощало настройку, но усиливало накопление просроченной работы. Полное отключение медленной функции уменьшало нагрузку, но лишало пользователей полезных данных даже при кратковременных задержках. Передача дедлайна с возможностью вернуть страницу без необязательного блока сохраняла основную функциональность, хотя требовала поддержки отмены и проверки побочных эффектов.
Выбран третий вариант. Верхний сервис передавал общий дедлайн, а сервис истории начинал дорогую операцию только при достаточном остатке времени и прекращал ожидание при его исчерпании. В результате просроченные запросы быстрее освобождали ресурсы, а обязательная часть ответа сохраняла предсказуемое время завершения; точный эффект нужно подтверждать метриками задержки, отказов и загрузки пулов.
Таймаут обычно задаёт длительность ожидания, начиная с конкретного этапа. Дедлайн задаёт общий момент окончания работы, поэтому оставшееся время автоматически уменьшается при прохождении запроса через цепочку. Независимые таймауты могут суммироваться и нарушать ограничение клиента, а единый дедлайн сохраняет сквозную границу.
Он должен прекращать работу, которая больше не может принести полезный результат и безопасна к остановке, но немедленная остановка возможна не для любой операции. Нельзя бездумно прерывать действие после частичного изменения состояния: это может оставить систему в промежуточном состоянии. Для таких операций нужны транзакционные гарантии, идемпотентность или отделение принятия задания от его фонового выполнения.
Дедлайн ограничивает время конкретного запроса, но не устраняет очередь, блокировки, перегруженную зависимость или недостаток ресурсов. Кроме того, отмена может не дойти до всех компонентов, а уже начатая работа может продолжаться. Поэтому дедлайны следует сочетать с ограничением конкуренции, контролем очередей, метриками оставшегося времени и анализом трассировок.