Управление работой прокси с помощью потоков

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Любая модель прикладного программирования включает в себя способ управления потоком обработки. В API-прокси это делается с помощью потоков. К потокам добавляются логика, условные операторы, обработка ошибок и так далее. Вы используете потоки для управления тем, что происходит и когда.

Потоки — это последовательные этапы обработки запроса к API. При добавлении логики прокси, например, для проверки ключа API, вы добавляете эту логику в качестве шага в последовательности, указанной в потоке. При определении условия, определяющего, будет ли выполняться логика и когда, вы добавляете это условие в поток.

В приведенном ниже примере конфигурации потока определяется поток, в котором политика VerifyAPIKey выполняется, если путь входящего запроса заканчивается символом / и HTTP-метод запроса — GET.

<Flow name="Get Food Carts">
    <Description>Get Food Carts</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

Значение Verify-API-Key в элементе <Name> потока служит для включения политики, настроенной в другом месте прокси-сервера с помощью XML, например, следующей:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key">
    <DisplayName>Verify API Key</DisplayName>
    <Properties/>
    <APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>

Разработка последовательности выполнения потока

Вы структурируете потоки таким образом, чтобы логика выполнялась в правильной последовательности на протяжении всего пути обработки.

При выборе места для добавления логики сначала необходимо определиться, добавлять ли её в конечную точку прокси-сервера или в целевую конечную точку. Код API-прокси разделяется на код, взаимодействующий с клиентом прокси (конечная точка прокси), и необязательный код, взаимодействующий с целевым бэкэндом прокси, если таковой имеется (целевая конечная точка).

Обе конечные точки содержат потоки данных, как описано здесь:

Вы настраиваете поток с помощью XML-файла, который определяет, что должно происходить и в каком порядке. На следующем рисунке показано, как потоки упорядочиваются последовательно внутри конечной точки прокси и целевой конечной точки:

Прокси-сервер и целевая конечная точка содержат потоки данных, которые можно расположить в следующей последовательности:

Предварительное выполнение кода с помощью PreFlow

PreFlow полезен, когда необходимо убедиться, что определенный код выполняется до того, как произойдет что-либо еще.

В прокси-сервере PreFlow отлично подходит для кода, который аутентифицирует клиента и ограничивает трафик от клиентов. В целевом сервере, где начинается подготовка к отправке запроса на бэкэнд, PreFlow хорош для первых шагов в подготовке к отправке запроса.

Например, обычно нежелательно обслуживать клиента, превысившего свою квоту. Для поддержки таких требований политики безопасности и квот размещаются в сегменте PreFlow. Таким образом, вам не нужно беспокоиться о том, что условие не будет выполнено в последующем условном потоке. Политики в этом потоке всегда будут выполняться до начала любой другой обработки.

В следующем примере политики SpikeArrest и Quota выполняются до того, как обработка переходит к условным потокам.

<PreFlow name="MyPreFlow">
    <Request>
        <Step>
            <Name>Spike-Arrest</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
</PreFlow>

Выполнение кода в зависимости от условий с помощью условного потока выполнения.

Между PreFlow и PostFlow можно создавать потоки, выполняющиеся условно. Это позволяет настроить несколько последовательностей логики, но при этом выполняться только одна в зависимости от состояния прокси-сервера. Условный поток является необязательным, если можно выполнить всю логику в PreFlow или PostFlow и условия не требуются (другими словами, поддерживается только один путь через конечную точку).

Каждый поток задает условие, которое проверяет различные значения состояния. Это фактически разветвляет выполнение в зависимости от условий. Например, вы можете захотеть преобразовать XML в JSON только тогда, когда запрашивающее приложение работает на мобильном устройстве.

Здесь ограничения квоты применяются только в том случае, если запрос является GET запросом с URI-шаблоном /issue/** (/issue/ с любым содержимым URI после последней косой черты).

<Flow name="MyFlow">
    <Description/>
    <Request>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>

Для задания условий используются переменные потока. Более подробную информацию об использовании переменных в условиях см. в разделе «Условия с переменными потока» .

Примеры использования сопоставления с шаблоном в условиях см. в разделе «Сопоставление с шаблоном» .

Выполнение кода после основной логики с помощью PostFlow

PostFlow — отличное место для выполнения действий после основной логики конечной точки и до завершения обработки конечной точки. PostFlow выполняется после условных потоков и PreFlow.

PostFlow — это хорошее место для регистрации данных, отправки уведомления о произошедшем, преобразования формата ответного сообщения и так далее.

В следующем примере политика AssignMessage под названием SetResponseHeaders устанавливает заголовки ответного сообщения перед тем, как Apigee Edge отправит ответ обратно клиенту.

<PostFlow>
    <Response>
        <Step>
            <Name>SetResponseHeaders</Name>
        </Step>
    </Response>
 </PostFlow>

Код должен выполняться после того, как клиент получит ответ от вашего прокси-сервера с помощью PostClientFlow.

Объект PostClientFlow может включать следующие политики:

• Политика вызова расширений
• Политика FlowCallout ^*
• Политика ведения журнала сообщений
• Политика вызова сервисной службы

^* Политика FlowCallout может вызывать только общие потоки, которые сами соответствуют критериям для нахождения в PostClientFlow (т.е. содержат только совместимые политики).

Если вы его включите, то PostClientFlow будет последним выполняемым потоком, запускающимся после отправки ответа клиенту.

Компонент PostClientFlow хорошо подходит для окончательного логирования. Кроме того, вы можете записывать в лог метки времени начала и окончания ответного сообщения.

Вот пример PostClientFlow с прикрепленной политикой MessageLogging.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

Для получения более подробной информации см.:

• Справочник по настройке API-прокси
• Учебное пособие: статья сообщества Apigee Edge - Post Client Flow

Добавление логики в потоки

При добавлении логики в прокси-сервер вы делаете это путем добавления политик в потоки прокси-сервера. Подобно тому, как потоки выполняются последовательно (предварительный поток, затем основной поток, затем заключительный поток, как описано в этой теме), содержимое потока выполняется последовательно.

В приведенном ниже примере конфигурации потока используются три политики (настроенные в отдельных XML-файлах). Политика, на которую ссылается Verify-API-Key выполняется перед политикой, на которую ссылается Remove-API-Key ; за обеими политиками следует политика, представленная Quota .

<Flow name="Get Food Cart Menus">
    <Description>Get Food Cart Menus</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
        <Step>
            <Name>Remove-API-Key</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

В консоли Apigee Edge эта последовательность политик отображается в виде ряда значков, где каждый значок представляет собой соответствующую политику.

Отладка потоков

Инструмент Apigee Edge Trace предоставляет графический способ увидеть, как выполняется логика в вашем API-прокси после запроса. Инструмент иллюстрирует обработку между запросом и ответом. Он не показывает конкретно разделение между PreFlow, условными потоками и PostFlow.

Для получения дополнительной информации о трассировке прокси-серверов см. раздел «Использование инструмента трассировки» .

Обработка ошибок в потоках

В API-прокси можно генерировать ошибки из различных мест, в том числе из потоков данных.

В следующем примере представлен фрагмент кода ответа из PreFlow в целевой конечной точке — другими словами, это код, который выполняется немедленно после получения ответа от бэкэнда. В примере ошибка возникает, если ответ от цели не равен 200 (успех).

<PreFlow name="PreFlow">
    <Response>
        <Step>
            <Name>RaiseFault</Name>
            <Condition>(response.status.code GreaterThan "200")</Condition>
        </Step>
    </Response>
</PreFlow>

Более подробную информацию об обработке ошибок см. в разделе «Обработка ошибок» .