Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Przekieruj funkcjonalność usług wspólnych lub specjalistycznych do serwera proxy bramowego. Takie podejście upraszcza tworzenie aplikacji dzięki scentralizowaniu zagadnień przekrojowych, takich jak kończenie połączeń TLS od strony klienta, w bramie sieciowej zamiast powielania ich w poszczególnych usługach.
Gdy wiele usług współdzieli obowiązki, takie jak uwierzytelnianie, monitorowanie lub tłumaczenie protokołu, konsolidowanie tych problemów w jednej bramie zmniejsza obciążenie związane z konfiguracją poszczególnych usług i ryzyko związane z wdrażaniem.
Kontekst i problem
Niektóre funkcje, często używane w wielu usługach, wymagają konfiguracji, zarządzania i konserwacji. Udostępniona lub wyspecjalizowana usługa dystrybuowana przy każdym wdrożeniu aplikacji zwiększa nakład pracy administracyjnej i zwiększa prawdopodobieństwo błędu wdrożenia. Należy wdrożyć wszystkie aktualizacje funkcji udostępnionej we wszystkich usługach, które udostępniają tę funkcję.
Problemy z zabezpieczeniami, takie jak walidacja tokenu, szyfrowanie i zarządzanie certyfikatami TLS, mogą wymagać od członków zespołu posiadania wysoce wyspecjalizowanych umiejętności. Na przykład bez bramy może być konieczne skonfigurowanie i wdrożenie certyfikatu dostępnego dla klienta w każdym wystąpieniu aplikacji. Należy śledzić termin jego ważności oraz aktualizować, testować i weryfikować je we wszystkich tych instancjach.
Wdrożenie innych typowych usług, takich jak uwierzytelnianie, autoryzacja, rejestrowanie, monitorowanie lub ograniczanie przepustowości, w wielu wdrożeniach może być trudne, podobnie jak zarządzanie nimi. Konsolidacja tego typu funkcji zmniejsza obciążenie i prawdopodobieństwo wystąpienia błędów.
Rozwiązanie
Przenieść część funkcji do bramy sieciowej. Następnie brama obsługuje aspekty przekrojowe, takie jak zarządzanie certyfikatami używanymi po stronie klienta, uwierzytelnianie, terminowanie połączeń TLS, monitorowanie, translację protokołów oraz ograniczanie szybkości na rzecz usług zaplecza.
Na poniższym diagramie przedstawiono bramę, która przerywa przychodzące połączenia TLS i stosuje funkcje udostępnione. Brama weryfikuje certyfikat zaplecza i ponownie szyfruje ruch za pośrednictwem oddzielnego połączenia TLS z usługą zaplecza.
Oto zalety tego wzorca:
Uprość opracowywanie usług przez scentralizowanie konfiguracji udostępnionej, takiej jak uwierzytelnianie, ograniczanie przepustowości i rejestrowanie żądań, zamiast implementowania ich w każdej usłudze zaplecza. Centralizacja zwiększa spójność i sprawia, że uaktualnienia usług są prostsze.
Dedykowane zespoły mogą implementować funkcje wymagające specjalistycznej wiedzy, na przykład zabezpieczenia. Twój główny zespół może wtedy skupić się na funkcjonalności aplikacji, pozostawiając te wyspecjalizowane, ale przekrojowe zagadnienia odpowiednim ekspertom.
Zapewnienie pewnego poziomu spójności rejestrowania oraz monitorowania żądań i odpowiedzi. Nawet jeśli usługa nie jest prawidłowo instrumentowana, brama może zapewnić poziom odniesienia monitorowania i rejestrowania.
Centralizowane zarządzanie ruchem świadome emisji dwutlenku węgla. Brama sieciowa może dostosować buforowanie, ograniczanie przepustowości i logowanie na podstawie sygnałów intensywności węglowej w czasie rzeczywistym. Azure API Management zapewnia te możliwości w ograniczonej wersji zapoznawczej, w wybranych regionach i warstwach klasycznych (Developer, Basic, Standard i Premium). Aby uzyskać szczegółowe informacje na temat dostępności i konfiguracji, zobacz Interfejsy API zrównoważone dla środowiska w Azure API Management.
Problemy i zagadnienia
Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:
Wysoka dostępność i odporność. Upewnij się, że brama jest wysoce dostępna i odporna na awarie. Aby uniknąć pojedynczych punktów awarii, uruchom wiele instancji bramy. Ponieważ brama przerywa połączenia klienta i może buforować jednostki żądań, należy wziąć pod uwagę sposób obsługi żądań w locie podczas awarii wystąpień. Użyj mechanizmów wygaszania połączeń lub łagodnego zamykania, aby usunięcie lub ponowne uruchomienie instancji bramy nie przerywało aktywnych sesji.
Pojemność i skalowanie. Brama powinna zostać zaprojektowana pod kątem wymagań aplikacji i punktów końcowych dotyczących pojemności i skalowania. Upewnij się, że brama nie staje się wąskim gardłem aplikacji i jest wystarczająco skalowalna. Brama musi być zwymiarowana tak, aby obsługiwać nagłe skoki ruchu, a nie tylko średnie obciążenie. Niedostateczne przydzielenie zasobów bramie w celu obniżenia kosztów bezpośrednio pogarsza wydajność każdej usługi korzystającej z niej.
Zakres odciążenia. Odciążanie funkcji współużytkowanych przez wiele usług lub tras przy ich scentralizowaniu zmniejsza zduplikowaną implementację i zarządzanie.
Separacja logiki biznesowej. Nigdy nie przenoś logiki biznesowej do bramy.
Śledzenie transakcji. Jeśli musisz śledzić transakcje, weź pod uwagę generowanie identyfikatorów korelacji dla celów rejestrowania.
Narzut opóźnienia. Brama dodaje dodatkowy etap w sieci do każdego żądania. Każda odciążona funkcja wykonywana przez bramę, taka jak zakończenie protokołu TLS, uwierzytelnianie lub inspekcja żądań, dodaje czas przetwarzania do ścieżki żądania. Buforowanie połączeń bramy i utrzymywanie aktywności połączeń z usługami zaplecza może częściowo zrównoważyć koszt opóźnienia, ponownie używając połączeń zamiast ustanawiania nowych połączeń dla każdego żądania. Oceń, czy łączne opóźnienie przejścia przez bramę i funkcji odciążonych jest akceptowalne względem docelowych parametrów wydajnościowych obciążenia.
Złożoność operacyjna. Scentralizowana brama konsoliduje zarządzanie, ale także koncentruje się na odpowiedzialności operacyjnej. Musisz zarządzać konfiguracją bramy, cyklem życia certyfikatu, aktualizacjami zasad i aktualizacjami wersji jako wspólną odpowiedzialnością. Upewnij się, że zespół odpowiedzialny za bramę ma pojemność i narzędzia do zarządzania nią w skali wszystkich usług, które od niej zależą.
Implikacje dotyczące zabezpieczeń. Brama jest cennym celem ataku, ponieważ centralizuje przekrojowe funkcje bezpieczeństwa, takie jak uwierzytelnianie, terminacja TLS i inspekcja żądań. Naruszenie zabezpieczeń bramy może uwidocznić wszystkie usługi podrzędne. Wzmacnianie zabezpieczeń bramy, ograniczanie jej obszaru zarządzania i monitorowanie go pod kątem nietypowego zachowania niezależnie od chronionych przez nią usług zaplecza.
Zapobieganie obejściu bramy. Skonfiguruj usługi backendowe tak, aby akceptowały żądania tylko za pośrednictwem właściwej ścieżki bramy. W przeciwnym razie klienci mogą łączyć się bezpośrednio z zapleczem i pomijać uwierzytelnianie, ograniczanie przepustowości, inspekcję żądań i rejestrowanie w bramie.
Propagacja tożsamości. Określ, czy każdy backend autoryzuje pierwotny obiekt wywołujący, tożsamość obciążenia roboczego bramy, czy oba te elementy. Zachowaj tokeny obiektu wywołującego lub zaufane oświadczenia tylko wtedy, gdy zaplecze wymaga delegowanego kontekstu użytkownika. Zawsze uwierzytelniaj bramę w zapleczu oddzielnie. Nie traktuj niezweryfikowanych nagłówków przekazanych jako dowód tożsamości.
Konserwacja protokołu TLS. Jeśli brama kończy połączenie TLS, ponownie ustanów połączenie TLS do systemu zaplecza. Nie przekazuj ruchu za pośrednictwem niezaszyfrowanego protokołu HTTP. Traktuj wszystkie sieci jako niezaufane. Ta topologia nadal wymaga procesu umożliwiającego wystawianie, odnawianie i odwoływanie certyfikatów back-endu.
Przekazane nagłówki i kontekst klienta. Gdy brama przerywa połączenia klienta i ustanawia nowe połączenia z usługami zaplecza, informacje takie jak adres IP klienta, oryginalny protokół i nazwa hosta zostaną utracone, chyba że brama jawnie przekaże je. Informacje o strategiach ograniczania ryzyka zawiera artykuł Zachowanie oryginalnej nazwy hosta HTTP między serwerem proxy odwrotnego a jego zapleczową aplikacją internetową.
Kiedy należy używać tego wzorca
Użyj tego wzorca, gdy:
- Wdrożenie aplikacji ma wspólne problemy, takie jak certyfikaty TLS lub szyfrowanie.
- Funkcja pospolita we wdrożeniach aplikacji może mieć różne wymagania dotyczące zasobów, takie jak zasoby pamięci, pojemność magazynu lub połączenia sieciowe.
- Chcesz przenieść odpowiedzialność za problemy, takie jak zabezpieczenia sieci, ograniczanie przepustowości lub inne obawy dotyczące granic sieci do bardziej wyspecjalizowanego zespołu.
Ten wzorzec może nie być odpowiedni w następujących przypadkach:
- Brama musi zawierać logikę specyficzną dla usługi lub reguły routingu, które ściśle paruje zmiany usługi zaplecza w zmianach konfiguracji bramy. Sprzężenie warstwy bramy z usługami wewnętrznymi oznacza, że aktualizacje zaplecza mogą wymusić ponowne wdrożenie bramy, co zmniejsza niezależność wdrożenia.
- Problem z odciążonym obciążeniem jest lekki, a obciążenie jest wrażliwe na opóźnienia. Dodatkowy przeskok sieci przez bramę może nie być uzasadniony, gdy obciążenie przewyższa korzyści związane z centralizacją.
- Centralizacja różnych kwestii we współdzielonej bramie tworzy wąskie gardło w zarządzaniu zmianami. Jeśli cykl wydań zespołu odpowiedzialnego za bramę jest wolniejszy niż cykl wydań zespołów usług, odciążenie może opóźnić aktualizacje certyfikatów, zasad uwierzytelniania lub reguł sieciowych.
Projektowanie obciążenia pracy
Architekt powinien ocenić, w jaki sposób wzorzec odciążania bramy może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Przykład:
| Filar | Jak ten wzorzec obsługuje cele filaru |
|---|---|
| Decyzje projektowe dotyczące niezawodności pomagają obciążeniom stały się odporne na awarię i zapewniają, że zostanie ono przywrócone do w pełni funkcjonalnego stanu po wystąpieniu awarii. | Przekładanie tej odpowiedzialności na bramę zmniejsza złożoność kodu aplikacji na węzłach zaplecza. W niektórych przypadkach przeniesienie funkcji całkowicie zastępuje funkcjonalność funkcją zapewnianą przez niezawodną platformą. - RE:01 Prostota i wydajność |
| Decyzje dotyczące projektowania zabezpieczeń pomagają zapewnić poufność, integralność i dostępność danych i systemów obciążenia. | Dodanie bramy do przepływu żądań umożliwia scentralizowanie kontrolek, takich jak zapory aplikacji internetowej i zasady protokołu TLS klienta. Każda odciążona funkcja udostępniana przez platformę oferuje już ulepszone zabezpieczenia. - SE:06 Kontrolki sieci - SE:08 Wzmacnianie zabezpieczeń zasobów |
| Optymalizacja kosztów koncentruje się na utrzymaniu i poprawiezwrotu obciążenia z inwestycji. | Ten wzorzec umożliwia przekierowanie kosztów z zasobów, które byłyby przypisane do poszczególnych węzłów, na implementację bramy. Koszty w modelu scentralizowanego przetwarzania są często niższe niż koszty modelu rozproszonego. - CO:14 Konsolidacja |
| Doskonałość operacyjna pomaga zapewnić jakość obciążeń dzięki ustandaryzowanym procesom i spójności zespołu. | W tym wzorcu konfiguracja i utrzymanie odciążonej funkcjonalności są powiązane z pojedynczym punktem, zamiast wymagać zarządzania z wielu węzłów. Ta centralizacja standaryzuje sposób stosowania aspektów przekrojowych, dzięki czemu rutynowe i doraźne zmiany operacyjne są spójne i przewidywalne. - OE:02 Standaryzacja operacji |
| Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu. | Dodanie bramy odciążającej do procesu obsługi żądań pozwala zużywać mniej zasobów na węzeł, ponieważ funkcjonalność jest scentralizowana w bramie. Można zoptymalizować implementację funkcjonalności odciążonej niezależnie od kodu aplikacji. Funkcje przeniesione na platformę prawdopodobnie będą wysoce wydajne. - PE:03 Wybieranie usług |
Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.
Example
Azure Application Gateway WAF_v2 może zaimplementować ten wzorzec dla regionalnej aplikacji internetowej. Brama sieciowa kończy połączenia TLS od klientów, stosuje zasady WAF i routingu oraz ustanawia nowe połączenia TLS z usługami zaplecza. To rozwiązanie oddziela wspólne aspekty przetwarzania żądań od kodu aplikacji backendowej.
Usługa Application Gateway z odciążaniem protokołu TLS
Na poniższym diagramie pokazano, jak usługa Application Gateway przerywa przychodzące połączenia TLS, sprawdza i filtruje ruch i ponownie szyfruje go przed przekazaniem go do puli zaplecza za pośrednictwem protokołu TLS.
Ta architektura używa następujących składników usługi Application Gateway do odciążania funkcji udostępnionych i ponownego szyfrowania ruchu zaplecza:
- Odbiornik HTTPS. Odbiornik HTTPS na porcie 443 akceptuje przychodzące połączenia TLS od klientów.
- Certyfikat TLS. Certyfikat PFX pochodzący z Azure Key Vault jest dołączony do odbiornika HTTPS. Usługa Application Gateway odszyfrowuje ruch przychodzący, aby go sprawdzić i trasować, a następnie ponownie go szyfruje przed przekazaniem do puli zaplecza. Serwery zaplecza nadal potrzebują certyfikatów dla ponownie zaszyfrowanych połączeń, ale w wielu przypadkach można użyć certyfikatów zarządzanych przez platformę.
- Pula zaplecza. Pula zaplecza definiuje zestaw serwerów HTTPS, które odbierają ponownie zaszyfrowany ruch. Obiektami docelowymi zaplecza mogą być maszyny wirtualne, zestawy skalowania maszyn wirtualnych platformy Azure, adresy IP lub wystąpienia usługi Azure App Service. Ogranicz dostęp do backendu, aby klienci nie mogli ominąć usługi Application Gateway i jej zasad WAF przez bezpośrednie nawiązywanie połączenia.
- Ustawienia HTTP zaplecza. Ustaw protokół zaplecza na HTTPS i port na port TLS zaplecza, taki jak 443. Skonfiguruj zaufanie do certyfikatu i nazwę hosta zgodną z certyfikatem backendu. W przypadku prywatnego urzędu certyfikacji skonfiguruj zaufany certyfikat główny. Aby uzyskać szczegółowe informacje, zobacz TLS typu end-to-end z jednostką SKU v2.
- Reguła routingu. Reguła routingu żądań kojarzy odbiornik z pulą zaplecza i ustawieniami http zaplecza. Reguły oparte na ścieżkach mogą kierować różne ścieżki adresów URL do różnych pul zaplecza.
- Zasada WAF. Zasady definiują zarządzane i niestandardowe reguły używane do inspekcji żądań, w tym wszelkie reguły zgodności geograficznej.
Ponieważ usługa Application Gateway odszyfrowuje ruch, może analizować zawartość żądań na potrzeby inteligentnego kierowania, modyfikować nagłówki HTTP i adresy URL oraz stosować reguły WAF. Następnie ponownie szyfruje ruch przed przekazaniem żądań do zaplecza.
Aby uzyskać wskazówki dotyczące konfiguracji, zobacz Kompleksowe szyfrowanie TLS w usłudze Application Gateway.
Technologie pomocnicze
Następujące usługi Azure mogą pomóc w zaimplementowaniu tego wzorca:
Użyj usługi Application Gateway dla regionalnego ruchu internetowego.
Użyj Azure Application Gateway for Containers do natywnej dla platformy Kubernetes obsługi ruchu przychodzącego dla obciążeń AKS.
Użyj Azure Front Door dla ruchu internetowego globalnego lub wieloregionowego.
Użyj Azure API Management dla problemów specyficznych dla interfejsu API, takich jak uwierzytelnianie, ograniczanie przepustowości, przekształcanie i monitorowanie.