Metody routingu ruchu do źródła

Dotyczy: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (wersja klasyczna)

Ważne

Usługa Azure Front Door (klasyczna) zostanie wycofana 31 marca 2027 r. Aby uniknąć zakłóceń w działaniu usługi, należy przeprowadzić migrację profilów usługi Azure Front Door (wersja klasyczna) do warstwy Azure Front Door Standard lub Premium do marca 2027 r. Aby uzyskać więcej informacji, zobacz Wycofywanie usługi Azure Front Door (wersja klasyczna).

Usługa Azure Front Door obsługuje cztery metody routingu ruchu, aby zarządzać sposobem dystrybucji ruchu HTTP/HTTPS między różnymi źródłami. Gdy żądania użytkowników docierają do lokalizacji brzegowych usługi Front Door, skonfigurowana metoda routingu zapewnia przekazywanie żądań do najlepszego zasobu zaplecza.

Uwaga

W tym artykule Origin odnosi się do zaplecza, a origin group odnosi się do puli zaplecza w konfiguracji Azure Front Door (klasycznej).

Cztery metody routingu ruchu to:

• Opóźnienie: kieruje żądania do źródeł o najniższym opóźnieniu w dopuszczalnym zakresie czułości, zapewniając, że żądania są kierowane do najbliższych źródeł pod względem opóźnienia w sieci.

• Priorytet: umożliwia ustawienie priorytetu dla źródeł, wyznaczenie podstawowego źródła do obsługi całego ruchu i pomocniczego źródła jako kopii zapasowej, jeśli podstawowy stanie się niedostępny.

• Ważone: przypisuje wagę do każdego źródła w celu równomiernego rozkładu ruchu lub zgodnie z określonymi współczynnikami wagi. Ruch jest dystrybuowany na podstawie wartości wag, jeśli opóźnienia źródeł mieszczą się w akceptowalnym zakresie czułości.

• Koligacja sesji: gwarantuje, że żądania od tego samego użytkownika końcowego są wysyłane do tego samego źródła poprzez konfigurację koligacji sesji dla hostów lub domen frontendowych.

Uwaga

W warstwach Azure Front Door Standard i Premium nazwa punktu końcowego jest nazywana hostem frontonu w usłudze Azure Front Door (wersja klasyczna).

Wszystkie konfiguracje usługi Front Door obejmują monitorowanie stanu zaplecza systemu oraz automatyczne globalne przełączanie awaryjne. Aby uzyskać więcej informacji, zobacz Monitorowanie zaplecza usługi Front Door. Usługa Azure Front Door może użyć jednej metody routingu lub połączyć wiele metod, aby utworzyć optymalną topologię routingu na podstawie potrzeb aplikacji.

Uwaga

Korzystając z silnika reguł usługi Front Door, można skonfigurować reguły, aby zastąpić ustawienia tras w warstwach Azure Front Door Standard i Premium lub zaplecze w usłudze Azure Front Door (wersja klasyczna) dla żądania. Grupa źródłowa lub pula zaplecza ustawiona przez silnik reguł zastąpi proces routingu opisany w tym artykule.

Ogólny przepływ decyzji

Na poniższym diagramie przedstawiono ogólny przepływ decyzji:

Kroki decyzyjne to:

1. Dostępne źródła: Wybierz wszystkie źródła, które są włączone i w dobrej kondycji (200 OK) na podstawie kontroli zdrowia.
   • Przykład: jeśli istnieją sześć źródeł A, B, C, D, E i F, a C jest w złej kondycji, a E jest wyłączona, dostępne źródła to A, B, D i F.
2. Priorytet: wybierz źródła o najwyższym priorytcie z dostępnych źródeł.
   • Przykład: jeśli źródła A, B i D mają priorytet 1, a źródło F ma priorytet 2, wybrane źródła to A, B i D.
3. Sygnał opóźnienia (na podstawie sondy diagnostycznej): wybierz źródła w zakresie dozwolonych opóźnień w środowisku Front Door, do którego dotarło żądanie. To opiera się na ustawieniu wrażliwości na opóźnienia grupy źródłowej oraz opóźnieniach najbliższych źródeł.
   • Przykład: Jeśli opóźnienie źródła A wynosi 15 ms, do B wynosi 30 ms, a do D to 60 ms, a czułość opóźnienia jest ustawiona na 30 ms, wybrane źródła to A i B, ponieważ D przekracza zakres 30 ms.
4. Wagi: Rozkładanie ruchu między ostatnimi wytypowanymi źródłami na podstawie określonych proporcji wagowych.
   • Przykład: Jeśli źródło A ma wagę 3, a źródło B ma wagę 7, ruch jest dystrybuowany 3/10 do A i 7/10 do B.

Jeśli afiniteta sesji jest włączona, pierwsze żądanie w sesji podąża za wcześniej opisanym przepływem. Kolejne żądania są wysyłane do źródła wybranego w pierwszym żądaniu.

Routing ruchu opartego na najniższych opóźnieniach

Wdrażanie źródeł w wielu lokalizacjach globalnych może zwiększyć czas reakcji aplikacji, rozsyłając ruch do źródła, który jest "najbliżej" użytkowników końcowych. Metoda routingu opartego na opóźnieniu jest domyślną opcją w konfiguracjach usługi Azure Front Door. Ta metoda kieruje żądania użytkowników do źródła z najniższym opóźnieniem sieci, a nie najbliższą lokalizacją geograficzną, zapewniając optymalną wydajność.

Architektura anycast usługi Azure Front Door w połączeniu z metodą routingu opóźnienia zapewnia, że każdy użytkownik ma najlepszą wydajność w oparciu o lokalizację użytkownika. Każde środowisko usługi Front Door niezależnie mierzy opóźnienie w źródłach, co oznacza, że użytkownicy w różnych lokalizacjach są kierowani do źródła, który zapewnia najlepszą wydajność dla konkretnego środowiska.

Uwaga

Domyślnie właściwość czułości na opóźnienie jest ustawiona na 0 ms. Dzięki temu ustawieniu żądania są zawsze przekazywane do najszybszych dostępnych źródeł. Wagi dla źródeł działają tylko wtedy, gdy dwa źródła mają takie samo opóźnienie sieci.

Aby uzyskać więcej informacji, zobacz Architektura routingu usługi Azure Front Door.

Kierowanie ruchem w oparciu o priorytety

Aby zapewnić wysoką dostępność, organizacje często wdrażają usługi tworzenia kopii zapasowych w celu przejęcia w przypadku awarii usługi podstawowej. Ta konfiguracja jest znana jako wdrożenie aktywne/czuwające lub aktywne/pasywne. Metoda routingu ruchu priorytetowego w usłudze Azure Front Door umożliwia efektywne implementowanie tego wzorca trybu failover.

Domyślnie usługa Azure Front Door kieruje ruch do źródeł o najwyższym priorytcie (najniższa wartość priorytetu). Jeśli te podstawowe źródła staną się niedostępne, kieruje ruch do źródeł pomocniczych (następna najniższa wartość priorytetu). Proces ten kontynuuje się z trzeciorzędnymi źródłami, jeśli zarówno podstawowe, jak i pomocnicze źródła są niedostępne. Sondy zdrowia monitorują dostępność źródeł na podstawie ich skonfigurowanego statusu i kondycji.

Konfigurowanie priorytetu dla źródeł

Każde źródło w grupie źródła usługi Azure Front Door ma właściwość Priority , którą można ustawić na wartość z zakresu od 1 do 5. Niższe wartości wskazują wyższy priorytet. Wiele źródeł może mieć tę samą wartość priorytetu.

Ważona metoda routingu ruchu

Uwaga

W przypadku klientów z bardzo niskim RPS (żądania na sekundę), ze względu na charakter rozproszonych punktów POP i maszyn AFD, nie możemy zagwarantować, że wagi skonfigurowane przez klienta będą ściśle przestrzegane, a równoważenie obciążenia może wydawać się niesymetryczne.

Metoda ważonego routingu ruchu umożliwia dystrybucję ruchu na podstawie wstępnie zdefiniowanych wag.

W tej metodzie przypisujesz wagę do każdego źródła w grupie źródła usługi Azure Front Door. Waga jest liczbą całkowitą z zakresu od 1 do 1000 z wartością domyślną 50.

Ruch jest dystrybuowany między dostępne źródła przy użyciu mechanizmu działania okrężnego na podstawie określonych współczynników wagi, pod warunkiem że źródła spełniają akceptowalną czułość opóźnienia. Jeśli czułość opóźnienia jest ustawiona na 0 milisekund, wagi obowiązują tylko wtedy, gdy dwa źródła mają takie samo opóźnienie sieci.

Metoda ważona obsługuje kilka scenariuszy:

• Stopniowe uaktualnianie aplikacji: kierowanie procentu ruchu do nowego źródła i stopniowe zwiększanie go wraz z upływem czasu.
• Migracja aplikacji na platformę Azure: utwórz grupę pochodzenia z platformą Azure i źródłami zewnętrznymi. Dostosuj wagi, aby preferować nowe źródła, stopniowo zwiększając swój udział ruchu, dopóki nie obsłużą większości ruchu, a następnie wyłącz i usuń mniej preferowane źródła.
• Zwiększanie wydajności w chmurze dla dodatkowej pojemności: rozszerzanie wdrożeń lokalnych do chmury przez dodanie lub włączenie większej liczby źródeł i określenie dystrybucji ruchu.

Afiniczność sesji

Domyślnie usługa Azure Front Door przekazuje żądania od tego samego klienta do różnych źródeł. Koligacja sesji jest jednak przydatna w przypadku aplikacji stanowych lub scenariuszy, w których kolejne żądania od tego samego użytkownika muszą być przetwarzane przez to samo źródło. Ta funkcja zapewnia, że to samo źródło obsługuje sesję użytkownika, co jest korzystne w sytuacjach, takich jak uwierzytelnianie klienta.

** Usługa Azure Front Door używa afinacji sesji opartej na plikach cookie, gdzie zarządzane pliki cookie używają SHA256 z adresu URL źródła jako identyfikatora. Spowoduje to przekierowanie kolejnego ruchu z sesji użytkownika do tego samego źródła.

Koligację sesji można włączyć na poziomie grupy źródłowej w warstwach Azure Front Door Standard i Premium oraz na poziomie hosta frontowego w usłudze Azure Front Door (wersja klasyczna) dla każdej skonfigurowanej domeny lub poddomeny. Po włączeniu usługa Azure Front Door dodaje pliki cookie o nazwie ASLBSA i ASLBSACORS do sesji użytkownika. Te pliki cookie pomagają identyfikować różnych użytkowników, nawet jeśli mają ten sam adres IP, co pozwala na bardziej równomierny rozkład ruchu między źródłami.

Okres istnienia pliku cookie jest zgodny z sesją użytkownika, ponieważ usługa Front Door obecnie obsługuje tylko pliki cookie sesji.

Uwaga

Powiązanie sesji jest utrzymywane przez plik cookie sesji przeglądarki na poziomie domeny. Poddomeny w tej samej domenie wieloznacznej mogą współużytkować afinitet sesji, o ile przeglądarka użytkownika wysyła żądania dla zasobu z tej samej domeny.

Serwery proxy publiczne mogą zakłócać powiązanie sesji, ponieważ ustanowienie sesji wymaga, aby usługa Front Door dodała ciastko powiązania sesji do odpowiedzi. Nie można tego zrobić, jeśli odpowiedź jest buforowalna, ponieważ spowoduje to zakłócenia plików cookie dla innych klientów żądających tego samego zasobu. Aby temu zapobiec, powiązanie sesji nie zostanie ustanowione, jeśli źródło wysyła odpowiedź podlegającą buforowaniu. Jeśli sesja jest już ustanowiona, możliwość buforowania odpowiedzi nie ma znaczenia.

Przyległość do sesji zostanie ustanowiona w następujących okolicznościach innych niż standardowe, które nie podlegają buforowaniu.

• Odpowiedź zawiera nagłówek Cache-Control z no-store.
• Odpowiedź zawiera prawidłowy Authorization nagłówek.
• Odpowiedź to kod stanu HTTP 302.

Następne kroki

• Dowiedz się, jak utworzyć usługę Azure Front Door.
• Dowiedz się , jak działa usługa Azure Front Door.