Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Antywzór: równoważenie obciążenia z jednym serwerem docelowym z wartością MaxFailures ustawioną na wartość inną niż zero

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Konfiguracja TargetEndpoint określa sposób, w jaki Apigee Edge łączy się z usługą backendu lub interfejsem API. Wysyła żądania i odbiera odpowiedzi do/z usługi backendu. Usługa backendu może być serwerem HTTP/HTTPS, NodeJS lub Hosted Target.

Usługę backendu w TargetEndpoint można wywołać na jeden z tych sposobów:

bezpośredni adres URL serwera HTTP lub HTTPS,
ScriptTarget do skryptu Node.js hostowanego w Edge,
HostedTarget do NodeJS wdrożonego w środowisku Hosted Target,
konfiguracja TargetServer.

Podobnie za pomocą zasady Service Callout można wywołać dowolną usługę zewnętrzną z przepływu serwera proxy interfejsu API. Ta zasada umożliwia zdefiniowanie docelowych adresów URL HTTP/HTTPS bezpośrednio w zasadzie lub za pomocą konfiguracji TargetServer.

Konfiguracja TargetServer

Konfiguracja TargetServer oddziela konkretne adresy URL punktów końcowych od konfiguracji TargetEndpoint lub zasad Service Callout. W TargetEndpoint odwołanie do TargetServer następuje za pomocą nazwy, a nie adresu URL. Konfiguracja TargetServer będzie zawierać nazwę hosta usługi backendu, numer portu i inne szczegóły.

Oto przykładowa konfiguracja TargetServer:

<TargetServer name="target1">
  <Host>www.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

TargetServer umożliwia stosowanie różnych konfiguracji w każdym środowisku. Zasada TargetEndpoint/Service Callout może być skonfigurowana z jednym lub kilkoma nazwanymi serwerami TargetServer za pomocą LoadBalancer. Wbudowana obsługa równoważenia obciążenia zwiększa dostępność interfejsów API i przełączanie awaryjne między skonfigurowanymi instancjami serwera backendu.

Oto przykładowa konfiguracja TargetEndpoint z użyciem TargetServer:

<TargetEndpoint name="default">
    <HTTPTargetConnection>>
      <LoadBalancer>
        <Server name="target1"/>
      <Server name="target2"/>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures

Konfiguracja MaxFailures określa maksymalną liczbę nieudanych żądań do serwera docelowego, po której serwer docelowy zostanie oznaczony jako niedostępny i usunięty z rotacji dla wszystkich kolejnych żądań.

Przykładowa konfiguracja z określonym parametrem MaxFailures:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

W powyższym przykładzie, jeśli 5 kolejnych żądań do „target1” zakończy się niepowodzeniem, „target1” zostanie usunięty z rotacji, a wszystkie kolejne żądania będą wysyłane tylko do „target2”.

Antywzorzec

Nie zalecamy używania pojedynczego TargetServer w konfiguracji LoadBalancer zasady TargetEndpoint lub Service Callout z parametrem MaxFailures ustawionym na wartość inną niż zero, ponieważ może to mieć negatywne konsekwencje.

Rozważmy tę przykładową konfigurację, która ma pojedynczy TargetServer o nazwie „target1” z parametrem MaxFailures ustawionym na 5 (wartość różna od zera):

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Jeśli żądania do TargetServer „target1” zakończą się niepowodzeniem 5 razy (liczba określona w MaxFailures), TargetServer zostanie usunięty z rotacji. Ponieważ nie ma innych serwerów TargetServer, na które można by się przełączyć, wszystkie kolejne żądania do serwera proxy interfejsu API z tą konfiguracją będą kończyć się niepowodzeniem z powodu błędu 503 Service Unavailable.

Nawet jeśli TargetServer „target1” wróci do normalnego stanu i będzie mógł wysyłać odpowiedzi, żądania do serwera proxy interfejsu API będą nadal zwracać błędy 503. Dzieje się tak, ponieważ Edge nie przywraca automatycznie TargetServer do rotacji, nawet gdy serwer docelowy znów działa. Aby rozwiązać ten problem, serwer proxy interfejsu API musi zostać wdrożony ponownie , aby Edge mógł przywrócić TargetServer do rotacji.

Jeśli ta sama konfiguracja jest używana w zasadzie Service Callout, żądania do interfejsu API będą zwracać błąd 500 po 5 nieudanych żądaniach do TargetServer „target1”.

Wpływ

Używanie pojedynczego TargetServer w konfiguracji LoadBalancer zasady TargetEndpoint lub Service Callout z parametrem MaxFailures ustawionym na wartość inną niż zero powoduje:

ciągłe niepowodzenia żądań do interfejsu API z błędami 503/500 (po nieudanych żądaniach o liczbie MaxFailures) do momentu ponownego wdrożenia serwera proxy interfejsu API;
dłuższe przerwy w działaniu, ponieważ zdiagnozowanie przyczyny tego problemu jest trudne i może zająć więcej czasu (bez wcześniejszej wiedzy o tym antywzorcu).

Sprawdzona metoda

Aby zwiększyć dostępność, w konfiguracji LoadBalancer używaj więcej niż 1 serwera TargetServer.
Gdy parametr MaxFailures jest ustawiony na wartość inną niż zero, zawsze definiuj monitor stanu. Serwer docelowy zostanie usunięty z rotacji, gdy liczba niepowodzeń osiągnie liczbę określoną w MaxFailures. Monitor stanu zapewnia, że TargetServer zostanie przywrócony do rotacji, gdy tylko serwer docelowy znów będzie dostępny, co oznacza, że nie trzeba ponownie wdrażać serwera proxy.

Aby mieć pewność, że kontrola stanu jest przeprowadzana na tym samym porcie, którego Edge używa do łączenia się z serwerami docelowymi, Apigee zaleca pominięcie elementu podrzędnego <Port> w elemencie <TCPMonitor> chyba że różni się on od portu TargetServer. Domyślnie <Port> jest taki sam jak port TargetServer.

Przykładowa konfiguracja z monitorem stanu:
```
<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>RoundRobin</Algorithm>
      <Server name="target1" />
      <Server name="target2" />
      <MaxFailures>5</MaxFailures>
    </LoadBalancer>
    <Path>/test</Path>
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <TCPMonitor>
        <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>
```
Jeśli istnieje ograniczenie, które pozwala na używanie tylko 1 serwera TargetServer, a monitor stanu nie jest używany, nie określaj parametru MaxFailures w konfiguracji LoadBalancer.

Domyślna wartość MaxFailures to 0. Oznacza to, że Edge zawsze próbuje połączyć się z serwerem docelowym w przypadku każdego żądania i nigdy nie usuwa serwera docelowego z rotacji.