Wzorzec routingu bramy

Kierowanie żądań do wielu usług lub wielu wystąpień usługi przy użyciu jednego punktu końcowego. Wzorzec jest przydatny, gdy chcesz:

• Uwidacznianie wielu usług w jednym punkcie końcowym i kierowanie do odpowiedniej usługi na podstawie żądania
• Uwidacznianie wielu wystąpień tej samej usługi w jednym punkcie końcowym na potrzeby równoważenia obciążenia lub dostępności
• Uwidacznianie różnych wersji tej samej usługi w jednym punkcie końcowym i kierowanie ruchu między różnymi wersjami

Kontekst i problem

Gdy klient musi korzystać z wielu usług, wiele wystąpień usługi lub kombinacji obu tych usług, klient musi zostać zaktualizowany po dodaniu lub usunięciu usług. Rozważ następujące scenariusze.

• Wiele różnych usług — aplikacja do handlu elektronicznego może świadczyć usługi , takie jak wyszukiwanie, przeglądy, koszyk, wyewidencjonowanie i historia zamówień. Każda usługa ma inny interfejs API, z którego musi korzystać klient. Musi on również mieć informacje o poszczególnych punktach końcowych, aby łączyć się z usługami. Zmiana interfejsu API wymaga również aktualizacji klienta. Jeśli zrefaktoryzujesz usługę na co najmniej dwie oddzielne usługi, musisz zmienić zarówno kod usługi, jak i kod klienta.
• Wiele wystąpień tej samej usługi — system może wymagać uruchomienia wielu wystąpień tej samej usługi w tych samych lub różnych regionach. Uruchamianie wielu wystąpień można wykonać w celach równoważenia obciążenia lub spełnić wymagania dotyczące dostępności. Za każdym razem, gdy wystąpienie jest ponownie uruchomione w górę lub w dół w celu dopasowania do zapotrzebowania, klient musi zostać zaktualizowany.
• Wiele wersji tej samej usługi — w ramach strategii wdrażania można wdrożyć nowe wersje usługi wraz z istniejącymi wersjami. Jest to nazywane niebieskimi zielonymi wdrożeniami. W tych scenariuszach klient musi być aktualizowany za każdym razem, gdy nastąpi zmiana procentu ruchu kierowanego do nowej wersji i istniejącego punktu końcowego.

Rozwiązanie

Umieść bramę przed zestawem aplikacji, usług lub wdrożeń. Kieruj żądania do odpowiednich wystąpień za pomocą routingu w warstwie 7 aplikacji.

W przypadku tego wzorca aplikacja kliencka musi wiedzieć tylko o jednym punkcie końcowym i komunikować się z jednym punktem końcowym. Poniżej przedstawiono sposób, w jaki wzorzec routingu bramy rozwiązuje trzy scenariusze opisane w sekcji kontekstowej i problemu.

Wiele różnych usług

Wzorzec routingu bramy jest przydatny w tym scenariuszu, w którym klient korzysta z wielu usług. Jeśli usługa jest skonsolidowana, rozłożona lub zamieniona, klient nie musi wymagać aktualizacji. Może on wciąż wysyłać żądania do bramy przy zmienionym routingu.

Brama pozwala również wyodrębniać usługi zaplecza z klientów, co umożliwia zachowanie prostoty wywołań klienta oraz wprowadzanie zmian w usługach zaplecza za bramą. Wywołania klienta można kierować do dowolnych usług przeznaczonych do obsługi oczekiwanego zachowania klienta, co pozwala dodawać, dzielić i reorganizować usługi za bramą bez zmieniania klienta.

Wiele wystąpień tej samej usługi

Elastyczność jest kluczowa w przetwarzaniu w chmurze. Usługi można połączyć, aby zaspokoić rosnące zapotrzebowanie lub zmniejszyć się, gdy zapotrzebowanie jest niskie, aby zaoszczędzić pieniądze. Złożoność rejestrowania i wyrejestrowania wystąpień usługi jest hermetyzowana w bramie. Klient nie jest świadomy wzrostu lub spadku liczby usług.

Wystąpienia usługi można wdrożyć w jednym lub wielu regionach. Wzorzec geode zawiera szczegółowe informacje na temat sposobu, w jaki wdrożenie obejmujące wiele regionów i aktywne-aktywne może zwiększyć opóźnienie i zwiększyć dostępność usługi.

Wiele wersji tej samej usługi

Ten wzorzec może służyć do wdrożeń, umożliwiając zarządzanie wdrażaniem aktualizacji dla użytkowników. Nową wersję usługi można wdrożyć równolegle z bieżącą wersją. Routing pozwala kontrolować, jaka wersja usługi jest prezentowana klientom, zapewniając elastyczność korzystania z różnych strategii wydania, zarówno przyrostowych, równoległych, jak i kompletnych wdrożeń aktualizacji. Wszelkie problemy wykryte po wdrożeniu nowej usługi można szybko rozwiązać, wprowadzając zmianę konfiguracji w bramie, bez wywierania wpływu na klientów.

Problemy i kwestie do rozważenia

• Usługa bramy może wprowadzić pojedynczy punkt awarii. Upewnij się, że została ona prawidłowo zaprojektowana w celu spełnienia wymagań dotyczących dostępności. Rozważ odporność i odporność na uszkodzenia w implementacji.
• Usługa bramy może powodować wąskie gardło. Zadbaj o to, aby brama miała odpowiednią wydajność, wymaganą do obsługi obciążenia, i aby można ją było łatwo skalować zgodnie z rosnącymi potrzebami.
• Wykonaj testowanie obciążenia bramy, aby mieć pewność, że nie występują kaskadowe awarie usług.
• Routing bramy ma poziom 7. Może korzystać z adresów IP, portów, nagłówków lub adresów URL.
• Usługi bramy mogą być globalne lub regionalne. Usługa Azure Front Door to brama globalna, a usługa aplikacja systemu Azure Gateway jest regionalna. Użyj bramy globalnej, jeśli rozwiązanie wymaga wdrożeń usług w wielu regionach. Rozważ użycie usługi Application Gateway, jeśli masz obciążenie regionalne, które wymaga szczegółowej kontroli nad zrównoważonym ruchem. Na przykład chcesz równoważyć ruch między maszynami wirtualnymi.
• Usługa bramy jest publicznym punktem końcowym dla usług, które znajduje się przed. Rozważ ograniczenie dostępu sieci publicznej do usług zaplecza, dzięki czemu usługi są dostępne tylko za pośrednictwem bramy lub za pośrednictwem prywatnej sieci wirtualnej.

Kiedy używać tego wzorca

Użyj tego wzorca, gdy:

• Klient musi korzystać z wielu usług, które mogą znajdować się za bramą.
• Chcesz uprościć aplikacje klienckie przy użyciu jednego punktu końcowego.
• Chcesz kierować żądania z punktów końcowych o adresach zewnętrznych do wewnętrznych, wirtualnych punktów końcowych, na przykład w związku z udostępnianiem portów na maszynie wirtualnej w celu ujęcia wirtualnych adresów IP w klaster.
• Klient musi korzystać z usług działających w wielu regionach w celu uzyskania korzyści z opóźnienia lub dostępności.
• Klient musi korzystać ze zmiennej liczby wystąpień usługi.
• Chcesz zaimplementować strategię wdrażania, w której klienci uzyskują dostęp do wielu wersji usługi w tym samym czasie.

Ten wzorzec może być nieodpowiedni, jeśli masz prostą aplikację, która korzysta tylko z jednej lub dwóch usług.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec routingu bramy może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

W poniższym przykładzie użyto routera Nginx. Przykład ten zawiera prosty plik konfiguracji serwera, który kieruje żądania od aplikacji znajdujących się w wielu katalogach wirtualnych do różnych maszyn na zapleczu.

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

Następujące usługi platformy Azure mogą służyć do implementowania wzorca routingu bramy:

• Wystąpienie usługi Application Gateway, które zapewnia routing warstwy regionalnej 7.
• Wystąpienie usługi Azure Front Door, które zapewnia globalny routing warstwy 7.

Powiązane zasoby

• Wzorzec zapleczy dla frontonów
• Wzorzec agregacji za pomocą bramy
• Wzorzec odciążania bramy