Антишаблон: определение нескольких виртуальных хостов с одинаковым псевдонимом хоста и номером порта.

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

В Apigee Edge весь входящий API-трафик обрабатывается маршрутизатором . Это означает, что все HTTP и HTTPS-запросы к прокси-серверу Edge API сначала обрабатываются маршрутизатором Edge. Следовательно, запрос к прокси-серверу API должен быть направлен на IP-адрес и открытый порт маршрутизатора.

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

Виртуальный хост на Edge определяет протокол (HTTP или HTTPS), а также порт маршрутизатора и псевдоним хоста. Псевдоним хоста обычно представляет собой доменное имя DNS, которое сопоставляется с IP-адресом маршрутизатора.

Например, на следующем изображении показан маршрутизатор с двумя определениями виртуальных хостов:

В этом примере есть два определения виртуальных хостов. Один обрабатывает HTTPS-запросы для домена domainName1 , другой — HTTP-запросы для домена domainName2 .

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

Ниже приведены примеры конфигурации виртуальных хостов:

пример конфигурации виртуального хоста

Антипаттерн

Определение нескольких виртуальных хостов с одинаковым псевдонимом хоста и номером порта в одной или разных средах организации или между организациями может привести к путанице при маршрутизации запросов API и вызвать неожиданные ошибки/некорректное поведение.

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

Предположим, есть два виртуальных хоста: sandbox and secure определенный с тем же псевдонимом хоста, например, api.company.abc.com в среде:

виртуальные хосты с одинаковым псевдонимом

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

Сценарий 1: API-прокси настроен на прием запросов только к одному из виртуальных хостов в изолированной среде. 

<ProxyEndpoint name="default">
  ...
  <HTTPProxyConnection>
    <BasePath>/demo</BasePath>
    <VirtualHost>sandbox</VirtualHost>
  </HTTPProxyConnection>
  ...
</ProxyEndpoint>

В этом сценарии, когда клиентские приложения обращаются к конкретному API-прокси, используя псевдоним хоста api.company.abc.com , они периодически будут получать ошибки 404 со следующим сообщением:

Unable to identify proxy for host: secure

Это происходит потому, что маршрутизатор отправляет запросы как на виртуальные хосты sandbox , так и на secure виртуальные хосты. Когда запросы направляются на виртуальный хост sandbox , клиентские приложения получают успешный ответ. Однако, когда запросы направляются на secure виртуальный хост, клиентские приложения получают ошибку 404, поскольку API-прокси не настроен на прием запросов на secure виртуальном хосте.

Сценарий 2: Настроен API-прокси для приема запросов как к изолированной среде виртуальных хостов, так и к защищенной среде. 

<ProxyEndpoint name="default">
  ...
  <HTTPProxyConnection>
    <BasePath>/demo</BasePath>
    <VirtualHost>sandbox</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
  ...
</ProxyEndpoint>

В этом сценарии, когда клиентские приложения обращаются к определенному API-прокси, используя псевдоним хоста api.company.abc.com , они получают корректный ответ в соответствии с логикой прокси.

Однако это приводит к хранению некорректных данных в Analytics, поскольку запросы API направляются на оба виртуальных хоста, тогда как фактические запросы должны были быть отправлены только на один виртуальный хост.

Это также может повлиять на информацию в журналах и любые другие данные, связанные с виртуальными хостами.

Влияние

  1. Ошибка 404 возникает, поскольку запросы к API могут направляться на виртуальный хост, для которого API-прокси может быть не настроен на прием этих запросов.
  2. Некорректные аналитические данные, поскольку запросы к API направляются на все виртуальные хосты с одинаковым псевдонимом хоста, тогда как запросы были сделаны только для конкретного виртуального хоста.

Передовая практика

  • Не следует создавать несколько виртуальных хостов с одинаковым псевдонимом хоста и номером порта в одной и той же среде, а также в разных средах организации.

  • Если необходимо определить несколько виртуальных хостов, используйте разные псевдонимы хостов для каждого из них, как показано ниже:

    два виртуальных хоста

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