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

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

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

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

Антипаттерн

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

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

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

<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>

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

Дополнительная информация