Антипаттерн: использование правила Service Callout для вызова бэкенд-службы в API-прокси без цели

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

Прокси-сервер API – это управляемый интерфейс для серверных сервисов. Базовая конфигурация прокси-сервера API состоит из ProxyEndpoint (определяет URL прокси-сервера API) и TargetEndpoint (определяет URL бэкенд-службы).

Apigee Edge предоставляет множество возможностей для создания сложных моделей поведения на основе этого шаблона. Например, вы можете добавить правила, чтобы контролировать, как API обрабатывает запрос клиента перед отправкой в бэкенд-службу, или изменять ответ, полученный от бэкенд-службы, перед отправкой клиенту. Вы можете вызывать другие сервисы, используя правила вызова сервисов, добавлять пользовательское поведение, добавляя код JavaScript, и даже создавать прокси-сервер API, который не вызывает бэкенд-службу.

Антипаттерн

Использование выносок сервисов для вызова бэкенд-службы в прокси-сервере API без маршрутов к целевой конечной точке технически возможно, но приводит к потере данных статистики о производительности внешней службы.

Прокси-сервер API без целевых маршрутов может быть полезен, если вам не нужно пересылать сообщение запроса в TargetEndpoint. Вместо этого ProxyEndpoint выполняет все необходимые операции. Например, ProxyEndpoint может получить данные из хранилища ключей и значений API-сервиса и вернуть ответ, не вызывая бэкенд-службу.

Вы можете определить пустой маршрут в прокси-сервере API, как показано ниже: 

<RouteRule name="noroute"/>

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

Технически возможно добавить вызов сервиса в прокси без цели, чтобы вызвать внешний сервис, как показано в примере ниже: 

<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>ServiceCallout-InvokeBackend</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/no-target-proxy</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

Однако прокси-сервер не может предоставить аналитическую информацию о работе внешнего сервиса (например, о времени обработки или частоте ошибок), поэтому оценить его производительность сложно.

Результат

  • Аналитическая информация о взаимодействии с внешним сервисом ( коды ошибок, время ответа, целевая производительность и т. д.) недоступна.
  • Любая логика, необходимая до или после вызова сервиса, включается в общую логику прокси, что затрудняет понимание и повторное использование.

Рекомендации

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

Следующая конфигурация прокси-сервера реализует то же поведение, что и в примере выше, но соответствует рекомендациям: 

<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/simple-proxy-with-route-to-backend</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>

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

Дополнительные материалы