Кратко

  • RFC 10053 позволяет CATS выбирать видимый клиенту контакт сервиса по сетевым и вычислительным данным. Один контакт может обслуживать несколько внутренних экземпляров, поэтому факт выбора не показывает, какой именно экземпляр выполнил запрос.
  • Метрики контакта могут объединять сведения о нескольких экземплярах, а агент сервисных метрик может дополнительно агрегировать данные нескольких контактов. Выбранный маршрут или спокойное среднее описывает поверхность управления трафиком, но не исполнение отдельного запроса и не результат обслуживания.

Вход виден, а обработка за ним — нет

Представим сервис сборки программного проекта. Клиент направляет задание по идентификатору сервиса. Система управления трафиком сравнивает две площадки: у одной короче сетевой путь, у другой больше свободных вычислительных ресурсов. Она выбирает доступный контакт сервиса и направляет туда запрос. Для клиента этот контакт и есть вход в службу. Он может обработать запрос сам или решить, какой внутренний экземпляр получит работу.

RFC 10053 намеренно разделяет эти роли. Экземпляр сервиса — это совокупность работающих ресурсов, организованных согласно логике поставщика. Контакт сервиса — обращённая к клиенту функция, принимающая запросы и способная обслуживать один или несколько экземпляров. Он может распределять работу между ними, как балансировщик нагрузки. RFC прямо говорит, что дальнейшее управление за контактом скрыто и для клиента, и для компонентов CATS.

Поэтому утверждение «CATS выбрала сервис» требует уточнения. CATS Path Selector (C-PS) использует сведения от агентов сетевых и сервисных метрик, чтобы выбрать выходной CATS-Forwarder, возможно — контакт сервиса, и маршрут. Так определяется точка входа запроса в структуру поставщика. Это само по себе не идентифицирует внутренний экземпляр, который выполняет работу.

У метрики есть границы, и агрегация может идти в несколько слоёв

RFC 10053 отдельно предупреждает: выбор может не раскрывать фактически вызванный экземпляр, например, при иерархической или рекурсивной структуре. Поэтому метрики контакта могут быть агрегированными данными нескольких экземпляров. В разделе 4.2 также допускается, что агент сервисных метрик CATS агрегирует метрики нескольких контактов, хранит их отдельно или использует оба подхода. Это разные уровни агрегации: один может сводить состояние внутренних экземпляров за контактом, другой — объединять состояние контактов перед передачей селекторам.

Агрегированная метрика не становится ложной. Важно понимать, к чему она относится. Среднее по контакту может помочь выбрать точку входа и одновременно мало сказать о хвосте задержек, назначенном на конкретный запрос экземпляре или полученном ответе. Показатель по площадке может упростить масштабирование управления, но не становится измерением каждого контакта. RFC оставляет варианты реализации поставщику и не задаёт единственный алгоритм выбора.

Классификатор трафика CATS может удерживать пакеты одного запроса на выбранном контакте. В разделе 4.4 описана привязка к экземпляру контакта: пакеты потока идут к тому же контакту и по тому же пути, чтобы снизить переупорядочивание и непредсказуемые колебания задержки. Это полезное свойство пересылки, но оно не делает внутреннее распределение контакта прозрачным. В документе не определён журнал, связывающий каждое решение CATS с внутренним экземпляром и результатом запроса.

Допустим, один контакт распределяет сборки между несколькими компиляторами. Если из-за изменения нагрузки один из них замедлится, агрегированная метрика контакта всё ещё может выглядеть приемлемо. CATS может продолжить выбирать этот контакт, не заметив перекоса и не установив, какие запросы он затронул. Это возможное следствие границы видимости в RFC, а не зафиксированный инцидент или измеренный результат конкретного оператора.

Такое разделение задумано специально. RFC 10053 указывает, что поставщик услуги сохраняет контроль над внутренними ресурсами и логикой обслуживания; способ организации сервиса не входит в область CATS. CATS сочетает сетевые и вычислительные данные для управления трафиком, но не задаёт проверку внутреннего планировщика поставщика. Сетевая сторона не должна выводить больше, чем позволяют сигналы; поставщик не должен выдавать выбранный контакт за доказательство результата конкретного запроса.

RFC 10054 расширяет постановку проблемы и требования CATS. Здесь вопрос уже: что известно после того, как трафик дошёл до выбранного контакта? Ответ зависит от телеметрии и журналов, которые поставщик решит предоставить отдельно. RFC не требуют универсального API распределения по backend-экземплярам, трассировки каждого запроса или квитанции о результате. Развёртывание может добавить такие средства, но их наличие нужно подтверждать отдельно.

Без дополнительных данных цепочка доказательств заканчивается на контакте

Это различие важно в эксплуатации, когда изменение маршрута, казалось бы, уменьшило задержку, но прикладная команда видит нестабильные результаты. Маршрут и выбранный контакт объясняют, куда пришли пакеты. Без свидетельств со стороны поставщика они не показывают, какой внутренний экземпляр обработал запрос, зависел ли он от деградировавшего компонента и выполнил ли ответ цель сервиса.

Корректный отчёт может сказать: «CATS выбрала этот контакт по таким метрикам и с таким охватом». Для заявления «этот экземпляр успешно обслужил запрос» нужны данные сервиса. Для заявления «сервис улучшился» нужна метрика результата, связанная с нужным запросом или группой запросов. Это разные утверждения, даже если позднее они объединены в одной системе наблюдаемости.

RFC 10053 — архитектурная основа для случая с одним поставщиком услуги. Она не фиксирует конкретный алгоритм выбора и внутреннее устройство сервиса. Документ помогает понять границы управления трафиком, но не обещает, что выбранный контакт раскроет все последующие решения.

Источники и рамки