Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
W Apigee Edge router obsługuje cały przychodzący ruch API. Oznacza to, że wszystkie protokoły HTTP i HTTPS żądania wysyłane do serwera proxy interfejsu Edge API są najpierw obsługiwane przez router brzegowy. Dlatego żądanie serwera proxy interfejsu API musi być kierowany na adres IP i otwarty port w routerze.
Host wirtualny umożliwia hostowanie wielu nazw domen na jednym serwerze lub w grupie serwerów. W przypadku Edge serwery odpowiadają routerom brzegowym. Definiując hosty wirtualne w routerze, możesz obsługi żądań wysyłanych do wielu domen.
Host wirtualny na Edge definiuje protokół (HTTP lub HTTPS) wraz z portem routera i aliasem hosta. Alias hosta to zwykle nazwa domeny DNS, która jest mapowana na adres IP routera.
Na przykład ten obraz przedstawia router z 2 definicjami hostów wirtualnych:
W tym przykładzie mamy 2 definicje hostów wirtualnych. Jeden z nich obsługuje żądania HTTPS domena domainName1, druga obsługuje żądania HTTP w domenie domainName2.
W żądaniu wysłanym do serwera proxy interfejsu API router porównuje nagłówek hosta i numer portu połączeń przychodzących żądanie na listę aliasów hostów zdefiniowanych przez wszystkie hosty wirtualne, aby określić, host wirtualny obsługuje żądanie.
Przykładowa konfiguracja hostów wirtualnych:
Antywzór
Definiowanie wielu hostów wirtualnych z tym samym aliasem hosta i tym samym numerem portu w tym samym lub innym systemie w całej organizacji lub w różnych organizacjach prowadzi do dezorientacji, i może powodować nieoczekiwane błędy/działania.
Przyjrzyjmy się przykładowi, który wyjaśnia konsekwencje posiadania wielu hostów wirtualnych z tym samym aliasem hosta.
Weź pod uwagę 2 hosty wirtualne, sandbox and secure
które zostały zdefiniowane
z tym samym aliasem hosta, tj. api.company.abc.com
w środowisku:
W przypadku powyższej konfiguracji możliwe są 2 scenariusze (opisane w poniższych sekcjach).
Scenariusz 1 : serwer proxy interfejsu API jest skonfigurowany tak, aby przyjmował żądania tylko do jednego piaskownica hostów
<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/demo</BasePath> <VirtualHost>sandbox</VirtualHost> </HTTPProxyConnection> ... </ProxyEndpoint>
W tym scenariuszu, gdy aplikacje klienckie wywołują określony serwer proxy interfejsu API za pomocą metody
alias hosta api.company.abc.com
, będzie okresowo otrzymywać błędy 404 z komunikatem:
Unable to identify proxy for host: secure
Dzieje się tak, ponieważ router wysyła żądania zarówno do sandbox
, jak i do secure
hostów wirtualnych. Gdy żądania są kierowane do hosta wirtualnego sandbox
, aplikacje klienckie
otrzyma pomyślną odpowiedź. Gdy jednak żądania są kierowane do hosta wirtualnego secure
,
aplikacje klienckie otrzymają błąd 404, ponieważ serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań
secure
host wirtualny.
Scenariusz 2 : serwer proxy interfejsu API jest skonfigurowany tak, aby akceptować żądania zarówno do piaskownicy hostów wirtualnych, jak i do bezpiecznego
<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/demo</BasePath> <VirtualHost>sandbox</VirtualHost> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection> ... </ProxyEndpoint>
W tym scenariuszu, gdy aplikacje klienckie wywołują określony serwer proxy interfejsu API za pomocą metody
hosta api.company.abc.com
, otrzymają prawidłową odpowiedź zgodnie z logiką serwera proxy.
Powoduje to jednak przechowywanie w Analytics nieprawidłowych danych, ponieważ żądania do interfejsu API są kierowane do na hostach wirtualnych, natomiast rzeczywiste żądania miały być wysyłane tylko do jednego hosta wirtualnego.
Może to też wpłynąć na informacje logowania i inne dane oparte na hostach wirtualnych.
Wpływ
- Błędy 404 – żądania do interfejsu API mogą być kierowane do hosta wirtualnego, do którego serwer proxy interfejsu API może nie być skonfigurowane do akceptowania żądań.
- Nieprawidłowe dane Analytics, ponieważ żądania do interfejsu API są kierowane do wszystkich hostów wirtualnych mających ten sam alias hosta, gdy żądania były wysyłane tylko do konkretnego hosta wirtualnego.
Sprawdzona metoda
- Nie definiuj wielu hostów wirtualnych z tym samym aliasem hosta i numerem portu w tym samym środowisku. czy różnych środowisk w organizacji.
Jeśli musisz zdefiniować wiele hostów wirtualnych, użyj różnych aliasów hosta w każdym z hostami wirtualnymi, które wygląda tak: