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 aparatu reguł usługi Front Door, można skonfigurować reguły tak, aby nadpisać konfiguracje tras w warstwach Azure Front Door Standard i Premium lub zastąpić pulę zaplecza w Azure Front Door (wersja klasyczna) dla żądania. Grupa źródłowa lub pula zaplecza ustawiona przez silnik reguł zastępuje 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. Ten zakres jest oparty na ustawieniu czułości na opóźnienia grupy pochodzenia oraz opóźnieniu najbliższych punktów początkowych.
   • 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 włączysz koligację sesji, pierwsze żądanie w sesji następuje zgodnie z wcześniej opisanym przepływem. Kolejne żądania przechodzą 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ść, wdróż usługi kopii zapasowej w celu przejęcia w przypadku awarii usługi podstawowej. Ta konfiguracja jest znana jako wdrożenie aktywne/czuwające lub aktywne/pasywne. Metoda Priority routowania ruchu w Azure Front Door pomaga zaimplementować mechanizm awaryjnego przełączania.

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ódeł 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, którzy mają bardzo niską liczbę żądań na sekundę (RPS), ze względu na sposób dystrybucji punktów obecności AFD i maszyn, Azure Front Door nie może zagwarantować, że skonfigurowane wagi będą ściśle przestrzegane, a równoważenie obciążenia może wydawać się niesprawiedliwe.

Metoda routingu ważonego ruchu dystrybuuje ruch 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 ustawisz czułość opóźnienia na 0 milisekund, wagi będą obowiązywać 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. Ta metoda kieruje kolejny ruch z sesji użytkownika do tego samego źródła.

Koligację sesji można włączyć na poziomie grupy źródłowej w usługach Azure Front Door Standard i Premium oraz na poziomie hosta frontowego w Azure Front Door (wersja klasyczna) dla każdej skonfigurowanej domeny lub poddomeny. Po włączeniu tej funkcji Azure Front Door dodaje pliki cookie o nazwie ASLBSA i ASLBSACORS do sesji użytkownika. Te pliki cookie pomagają zidentyfikować różnych użytkowników, nawet jeśli mają ten sam adres IP, co umożliwia 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

Plik cookie sesji przeglądarki utrzymuje koligację sesji 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.

Publiczne serwery proxy mogą zakłócać powiązanie sesji, ponieważ ustanowienie sesji wymaga, aby Front Door dodał plik cookie powiązania sesji do odpowiedzi. Tej akcji nie można wykonać, jeśli odpowiedź jest zapisywalna w pamięci podręcznej, ponieważ spowoduje to zakłócenia plików cookie dla innych klientów żądających tego samego zasobu. Aby zapobiec temu problemowi, koligacja sesji nie jest ustanawiana, jeśli źródło wysyła odpowiedź z możliwością buforowania. Jeśli sesja jest już nawiązana, pamięć podręczna odpowiedzi nie ma znaczenia.

Przywiązanie sesji jest ustanawiane w następujących okolicznościach poza standardowymi scenariuszami, które nie mogą być zapisane w pamięci podręcznej:

• 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.