Когда каждый модуль имеет свой язык, операционная сложность растёт вместе с платформой.
Управление корпоративным трафиком — это уже не просто правила балансировки нагрузки. Внутри одной платформы совместно работают маршрутизация трафика, проверка работоспособности, обогащение логов, GTM-решения, оценка безопасности, политика captcha, ACL и контекст доступа. Проблема в том, что большинство продуктов управляют этими модулями с отдельными языками выражений, отдельными именами переменных и отдельными поведениями ошибок.
Эта фрагментация вынуждает операторов постоянно переключать контекст мышления. Одно и то же значение пишется по-разному в разных модулях — страна клиента, IP источника, путь запроса, JWT-клейм или WAAP-оценка обрабатываются отдельной логикой в каждом месте. Результатом становятся более высокие затраты на обучение, умноженное дублирование правил и более длинные циклы отладки.
Ещё опаснее, когда одно и то же бизнес-правило интерпретируется по-разному в разных модулях. Если условие проверки работоспособности расходится с условием маршрутизации, система может пометить сервис как здоровый, тогда как отдельный логический путь отбрасывает трафик к тому же сервису. Когда сторона логов записывает тот же контекст неполно, расследование после инцидента также страдает.
Правильный подход — сделать единый язык выражений общим уровнем принятия решений. Этот язык должен централизованно определять функции, переменные, проверку типов и область видимости использования, чтобы каждый модуль потреблял одно и то же дерево выражений в своём собственном операционном контексте.
FX-движок TR7 удовлетворяет эту потребность: он объединяет логику принятия решений, разрозненную по модулям, под единым языком выражений, единым каталогом переменных и моделью валидации с пред-регистрацией.
Наш подход
Вместо разбиения логики принятия решений на отдельные синтаксисы для каждого модуля TR7 компилирует и вычисляет всё через общее дерево FX-выражений.
Каталог функций и переменных определяется централизованно
FX-движок предоставляет 41 встроенную функцию и 173 переменные, организованные в 14 группах. Контексты соединения, HTTP-заголовков, тела, SSL, таймеров, статистики, WAAP и AAM — все выбираются из одного каталога.
Выражения компилируются в нативную цепочку sample-fetch и конвертеров
Функции, которые могут обрабатываться нативно, выполняются напрямую как высокопроизводительная цепочка sample-fetch и конвертеров. Например, поле JSON из тела запроса может быть прочитано, нормализовано трансформатором текста и привязано к единому результату выражения.
Нативно не поддерживаемые функции компилируются в Lua-действия
Функции, требующие XML XPath, сложных JWT-запросов или пользовательской обработки, генерируются как Lua-действия. FX-язык остаётся унифицированным; путь выполнения выбирается исходя из потребностей функции.
Один и тот же движок выражений потребляется всеми модулями
Правила трафика, проверки работоспособности, форматы логов, GTM-триггеры, политика captcha и ACL — все разделяют одну модель функций и переменных. Эта общность снижает необходимость для операторов изучать новый язык принятия решений для каждого модуля.
Возможности
FX-движок выражений и переменных превращает переменные и функции всей платформы в управляемую схемой, проверяемую и компилируемую модель.
173 переменные в 14 группах охватывают контекст трафика и безопасности
Каталог переменных FX организован в группы: соединение, HTTP-заголовки, тело, клиент, строка запроса, строка ответа, SSL, статистика, таймер, отслеживание, WAAP, AAM, VarBuilder и другие. Операторы выбирают IP источника, порт назначения, путь запроса, статус ответа, SNI, детали сертификата, WAAP-оценку, роль пользователя AAM или пользовательские переменные из одной модели. Это предотвращает запись одного и того же контекста под разными именами в разных модулях, делая язык правил более согласованным, более читаемым и менее подверженным ошибкам.
41 функция охватывает от трансформации текста до JSON- и XML-запросов
Каталог функций охватывает группы: конвертер, математика, XML, JSON, JWT, IP, строки, хэш, FIX, MQTT, карты/списки, параметры и условный выбор. JSONQUERY, XMLQUERY, JWTHEADER, JWTPAYLOAD, PARAM, DIGEST, LOWERCASE, STRREPLACEALL, MAP_STR, LIST_REG и TERNARY — всё может быть составлено в одном выражении. Операторы используют одну FX-модель как для простых трансформаций текста, так и для глубоких запросов полей тела, переводя создание правил от ситуативного кодирования к управляемому определению политик.
Нативный путь компиляции используется для выражений с малой задержкой
Переменные и функции с нативной поддержкой компилируются напрямую в цепочку sample-fetch и конвертеров. Этот путь подходит для часто необходимых решений, таких как чтение заголовков, сопоставление путей, трансформация текста, поиск по картам и определённые запросы тела. Поскольку промежуточный уровень интерпретации не задействован, производительность остаётся предсказуемой. Правила трафика переводятся на наиболее эффективный путь выполнения платформы, когда это возможно.
Путь компиляции через Lua охватывает сложные и пользовательские функции
Управления, которые нельзя выразить через нативную цепочку, выполняются как Lua-действия. XML XPath-запросы, пользовательские JWT-проверки и сложная условная обработка — всё поддерживается таким образом. Язык выражений не меняется с точки зрения оператора — система выбирает правильный путь выполнения в фоне. Это разделение объединяет производительный нативный путь и гибкий Lua-путь в едином FX-опыте.
Проверка типов отклоняет недопустимые выражения до их сохранения
Каждый аргумент функции определяется с типом — integer, string, jsonPath, xmlPath, hash или smartInput. UI и уровень управления проверяют эти типы во время сохранения. Неверный тип аргумента, отсутствующий параметр или несовместимое вложенное использование перехватываются до достижения среды выполнения, снижая неожиданные сбои правил в продакшн-трафике.
Область видимости использования фильтруется по модулю и контексту
Каждая переменная несёт метаданные, описывающие, в каких модулях, типах условий и фазах трафика она может использоваться. Некоторые переменные действительны только в фазе ответа; другие появляются только в шаблонах логов или конкретных типах условий. UI использует эту информацию для представления оператору контекстно-подходящих вариантов, предотвращая размещение недопустимых переменных в неправильном месте.
VarBuilder позволяет операторам создавать собственные вычисляемые переменные
Группа VarBuilder позволяет операторам создавать пользовательские переменные, вычисляемые во время выполнения. Значение вычисляется через FX-выражение, хранится в области транзакции и используется повторно в последующих правилах. Эта модель снижает необходимость перезаписывать одно и то же вычисление в нескольких местах. В сложных потоках логика принятия решений становится более модульной и отслеживаемой.
Автодополнение получает данные из схемы для ускорения создания правил
FX-консоль получает информацию о функциях, переменных, аргументах и области видимости из центральной схемы. По мере того как оператор вводит имя функции или переменной, предлагаются подходящие варианты; аргументы, принимающие пустые значения, и функции, требующие скобок, правильно направляются UI. Это снижает кривую обучения для новых пользователей и позволяет опытным операторам создавать правила быстрее. Выражения становятся более корректными ещё до достижения шага сохранения.
Операционная глубина
FX-движок разработан с учётом валидации, применения области видимости, аудита, производительности и поведения в граничных случаях — а не только опыта создания выражений.
Валидация аргументов
Ожидаемый список аргументов и их типы для каждой функции хранятся в центральном определении. Как UI, так и уровень управления независимо проверяют эту информацию. В результате недопустимые выражения отклоняются не только на экране, но и в момент сохранения.
Область видимости фазы ответа
Некоторые переменные имеют смысл только в фазе ответа. Эти переменные помечаются в метаданных и блокируются от использования в условиях фазы запроса. Это различие снижает ошибки во время выполнения, вызванные несоответствиями фаз.
Скрытые псевдонимы переменных
Некоторые переменные хранятся в системе для обратной совместимости или внутреннего использования, но не отображаются в UI. Это позволяет платформе продолжать выполнять более старые выражения, представляя операторам чистый и точный список переменных. Видимый каталог и внутреннее использование разделены.
Загрузка Lua-конвертера
Функции такие как XMLQUERY, XMLPATHTYPE и XMLPATHEXISTS зависят от компонентов Lua-конвертера. Эти компоненты загружаются при запуске сервиса и потребляются соответствующими FX-функциями. Отсутствующие состояния конвертера должны выявляться в процессе развёртывания и проверок работоспособности.
Аудит и версионирование
Каждое дерево выражений должно быть отслеживаемым с историей изменений. Кто изменил какое выражение и когда — критически важная информация для операций и проверок безопасности. Эти записи обеспечивают возможность отката и отслеживание ответственности, особенно для правил, влияющих на поведение трафика.
Предупреждения о производительности regex
STRREPLACEALL и некоторые проверки на основе regex могут создавать высокую стоимость обработки при небрежном написании. Шаблоны с интенсивным отслеживанием могут представлять как риски безопасности, так и производительности. UI должен предупреждать операторов в таких случаях и побуждать к более безопасному написанию шаблонов.
Когда применять
Общее выражение в проверках работоспособности и правилах трафика
SaaS-команды могут использовать одно FX-выражение — например, `$.status == "OK"` в теле ответа — как в проверке работоспособности, так и в правиле маршрутизации трафика. Поскольку одно и то же состояние сервиса не пишется по-разному в каждом модуле, операционная согласованность улучшается.
Обогащение логов JWT-клеймами
SOC-команды могут добавлять email-адрес пользователя, роль или информацию о тенанте в формат логов через JWTPAYLOAD. Расследование инцидентов выходит за рамки сырых данных IP и URL, делая контекст пользователя видимым в каждой записи лога.
Геолокационная и ASN-триггерная активация в GTM-решениях
Команды глобальных сервисов могут оценивать данные о стране, ASN или задержке через FX-выражения при выборе DNS-ответа. Та же логика может повторно использоваться в правиле маршрутизации трафика при необходимости.
Контролируемая A/B-маршрутизация на основе хэша
Команды электронной коммерции могут перенаправлять определённый процент трафика на новый вариант на основе хэша, полученного из идентификатора пользователя. Распределение детерминировано — один и тот же пользователь всегда направляется к одному и тому же опыту при каждом запросе.
Часто задаваемые вопросы
Сколько функций и переменных предоставляет FX-движок?
Какие модули разделяют один FX-язык выражений?
Как работает проверка типов с пред-регистрацией?
В чём разница между нативным путём компиляции и Lua-путём?
Для чего можно использовать VarBuilder?
Как применяется область видимости переменных?
Унифицируйте решения платформы в едином языке выражений
Управляйте правилами трафика, проверками работоспособности, логами, GTM и решениями безопасности через одну FX-модель. Позвольте нам провести вас через живую настройку в вашей собственной среде.