Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
В Apigee Edge маршрутизатор обрабатывает весь входящий трафик API. Это означает, что все запросы HTTP и HTTPS к прокси-серверу Edge API сначала обрабатываются Edge Router. Следовательно, запрос прокси-сервера API должен быть направлен на IP-адрес и открытый порт маршрутизатора.
Виртуальный хост позволяет размещать несколько доменных имен на одном сервере или группе серверов. Для Edge серверы соответствуют пограничным маршрутизаторам. Определив виртуальные хосты на маршрутизаторе, вы можете обрабатывать запросы к нескольким доменам.
Виртуальный хост на Edge определяет протокол (HTTP или HTTPS), а также порт маршрутизатора и псевдоним хоста. Псевдоним хоста обычно представляет собой доменное имя DNS, которое соответствует IP-адресу маршрутизатора.
Например, на следующем изображении показан маршрутизатор с двумя определениями виртуальных хостов:
В этом примере есть два определения виртуального хоста. Один обрабатывает HTTPS-запросы в домене имя_домена1 , другой обрабатывает запросы HTTP в доменеИмя_домена2 .
При запросе к прокси-серверу API маршрутизатор сравнивает заголовок хоста и номер порта входящего запроса со списком псевдонимов хоста , определенных всеми виртуальными хостами, чтобы определить, какой виртуальный хост обрабатывает запрос.
Пример конфигурации виртуальных хостов показан ниже:
Антипаттерн
Определение нескольких виртуальных хостов с одинаковым псевдонимом хоста и номером порта в одной или разных средах организации или между организациями приведет к путанице во время маршрутизации запросов 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 направляются на оба виртуальных хоста, в то время как фактические запросы были направлены только на один виртуальный хост.
Это также может повлиять на информацию журнала и любые другие данные, основанные на виртуальных хостах.
Влияние
- 404 Ошибки, поскольку запросы API могут быть перенаправлены на виртуальный хост, для которого прокси-сервер API не настроен для приема запросов.
- Неправильные данные Analytics, поскольку запросы API перенаправляются на все виртуальные хосты, имеющие один и тот же псевдоним хоста, в то время как запросы были сделаны только для определенного виртуального хоста.
Лучшая практика
- Не определяйте несколько виртуальных хостов с одинаковым псевдонимом хоста и номером порта в одной и той же среде или в разных средах организации.
Если необходимо определить несколько виртуальных хостов, используйте разные псевдонимы хостов на каждом из виртуальных хостов, как показано ниже:
