Эта страница переведена с помощью Cloud Translation API.

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

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

Любая модель прикладного программирования включает способ управления потоком обработки. В прокси 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 делит свой код на код, который взаимодействует с клиентом прокси-сервера (конечная точка прокси-сервера), и дополнительный код, который взаимодействует с целевой серверной частью прокси-сервера, если таковая имеется (целевая конечная точка).

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

Тип конечной точки	Описание	Поддерживаемые потоки
ПроксиКонечная точка	Содержит потоки прокси-сервера API, ближайшие к клиенту. Предоставляет места для логики, которая сначала будет действовать по запросу клиента, а затем в последнюю очередь по ответу клиенту.	PreFlow, условные потоки, PostFlow, PostClientFlow
Целевая конечная точка	Содержит потоки прокси-сервера API, ближайшие к серверному ресурсу. Предоставляет места для логики для подготовки запроса и последующей обработки ответа от внутреннего ресурса.	PreFlow, условные потоки, PostFlow

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

Запрос от HTTP-клиента, проходящий через конечную точку прокси-сервера к целевой конечной точке на серверной стороне, для доступа к службе HTTP. На каждой панели запросов и ответов отображаются предварительная обработка, условные потоки и заключительная обработка. Кроме того, предоставляются примеры конечной точки прокси и целевой конечной точки.

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

Позиция	Тип потока	Описание
1	Предварительный поток	Полезно, когда вам нужно убедиться, что определенный код выполняется, прежде чем произойдет что-либо еще. Если PreFlow находится в целевой конечной точке, он выполняется после PostFlow конечной точки прокси.
2	Условный поток	Место условной логике. Выполняется после PreFlow и перед PostFlow. В каждом сегменте выполняется только один условный поток — первый поток, условие которого оценивается как истинное. Это означает, что вы можете выполнить один условный поток как часть каждого из: Конвейер запросов ProxyEndpoint Конвейер запросов TargetEndpoint Конвейер ответов ProxyEndpoint Конвейер ответов TargetEndpoint
3	PostFlow	Хорошее место для регистрации данных, отправки уведомления о том, что что-то произошло во время обработки запроса и т. д. Выполняется после условных потоков и PreFlow. Если PostFlow находится в конечной точке прокси и существует целевая конечная точка, PostFlow конечной точки прокси выполняется до целевой конечной точки PreFlow.
4	PostClientFlow (только поток прокси)	Поток регистрации сообщений после возврата ответа клиенту.

Сначала выполнение кода с помощью 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 может вызывать только общие потоки, которые сами соответствуют критериям нахождения в PostClientFlow (т. е. содержат только совместимые политики).

Если вы добавите его, PostClientFlow будет последним потоком, который будет выполняться после отправки ответа клиенту.

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

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

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

Видео. Посмотрите это короткое видео, показывающее, как создать PostClientFlow с помощью политики MessageLogging из серии «Четырехминутное видео для разработчиков» (4MV4D).

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

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

Когда вы добавляете логику в свой прокси, вы делаете это путем добавления политик в потоки вашего прокси. Точно так же, как потоки выполняются последовательно (PreFlow, затем Flow, затем PostFlow, как описано в этом разделе), содержимое потока выполняется последовательно.

Следующий пример конфигурации потока ссылается на три политики (настроенные в другом месте в их собственных 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 представляет эту последовательность политик в виде ряда значков, каждый из которых представляет политику. На пути запроса отображаются значки: «Проверить ключ API», «Удалить ключ API» и «Квота».

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

Инструмент 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>

Дополнительные сведения об обработке ошибок см. в разделе Обработка ошибок .