Projektowanie rozproszonej geograficznie architektury sieci
W aplikacji rozproszonej sprawą zasadniczą jest zagwarantowanie, że w przypadku wystąpienia awarii składniki będą mogły komunikować się niezawodnie, a żądania będą mogły być kierowane do innego składnika lub regionu.
Zdecydowaliśmy się na ponowne zaprojektowanie architektury naszego portalu wysyłkowego na platformie Azure w celu zmniejszenia podatności na awarie regionalne. Chcemy mieć pewność, że aplikacja ulegnie awarii składnikom w regionie pomocniczym, gdy region podstawowy jest niedostępny. Przejście w tryb failover powinno spowodować minimalne zakłócenia dostarczania usług użytkownikom.
Tutaj dowiesz się, jak usługi Azure DNS, Traffic Manager, Front Door i Azure CDN obsługują architekturę aplikacji firmy kurierskiej.
Usługa DNS platformy Azure
Jak wspomniano wcześniej, nie trzeba wprowadzać żadnych zmian w implementacji usługi Azure DNS. Używamy usługi Azure DNS do hostowania rekordów nazw domen, które identyfikują naszą aplikację.
Usługa Azure DNS zapewnia rozpoznawanie nazw wyłącznie za pośrednictwem infrastruktury platformy Azure. Ta usługa z założenia działa w wielu regionach, dlatego nie ma potrzeby modyfikowania istniejącej konfiguracji usługi Azure DNS, aby mogła ona obsługiwać tę funkcję w naszym nowym projekcie architektury.
Umowa SLA usługi Azure DNS ma również 100% gwarancji, że prawidłowe żądania DNS otrzymują odpowiedź od co najmniej jednego serwera nazw usługi Azure DNS przez cały czas.
Wybór routera ruchu
Potrzebujemy usługi, która może równoważyć obciążenie i przekierowywać ruch do wielu regionów zawierających rozproszone aplikacje internetowe.
Platforma Azure udostępnia kilka różnych usług, które mogą kierować ruch do składników frontonu. Jak pamiętasz, musimy zastąpić usługę Azure Application Gateway, ponieważ jest ona powiązana z pojedynczym regionem. Jeśli w tym regionie wystąpi awaria, nie będzie narzędzia, które będzie kierować ruchem.
Na platformie Azure istnieją dwa routery ruchu, które mogą wykonywać globalny routing między wieloma regionami i nie są narażone na awarię jednego regionu:
- Azure Traffic Manager
- Azure Front Door
Poznajmy bliżej te dwie usługi, aby móc wybrać router odpowiedni dla naszej aplikacji.
Co to jest Azure Traffic Manager?
Azure Traffic Manager to globalny moduł równoważenia obciążenia, który za pomocą rekordów DNS kieruje ruch do miejsc docelowych w wielu regionach świadczenia usługi Azure.
Usługę Traffic Manager można skonfigurować tak, aby kierowała wszystkie żądania do naszego regionu podstawowego i monitorowała czas odpowiedzi usługi App Service w tym regionie. Jeśli usługa App Service w regionie podstawowym ulegnie awarii, usługa Traffic Manager automatycznie ponownie skieruje żądania użytkowników do usługi App Service w regionie pomocniczym. Ta zmiana trasy uruchamia przejście w tryb failover zapewniający ciągłość działania usługi. Taki układ nazywamy trybem routingu opartego na priorytecie.
Ponieważ usługa Traffic Manager używa systemu DNS do kierowania ruchu, kierowane są wszystkie protokoły, a nie tylko ruch HTTP. Jednak usługa Traffic Manager nie może kierować ani filtrować ruchu na podstawie właściwości protokołu HTTP, takich jak kody kraju klienta czy nagłówki user-agent. Ta usługa nie może również zakończyć protokołu Transport Layer Security (TLS), co wiąże się z odszyfrowywaniem żądań i szyfrowaniem odpowiedzi przez router z jednoczesnym odciążeniem serwerów wirtualnych usługi App Service. Jeśli potrzebujemy jednej z tych funkcji, musimy użyć usługi Azure Front Door.
Usługa Traffic Manager korzysta z wysoce konfigurowalnego monitorowania punktów końcowych. Na przykład możemy zdefiniować protokół, port, ścieżkę, niestandardowe ustawienia nagłówka, oczekiwane zakresy kodu stanu i tolerowaną liczbę awarii. Monitorowanie punktów końcowych zapewnia nam ciągły wgląd w ogólną kondycję wszystkich części naszej aplikacji.
Co to jest usługa Azure Front Door?
Podobnie jak Traffic Manager, usługa Azure Front Door to globalny moduł równoważenia obciążenia. W przeciwieństwie do usługi Traffic Manager działa ona w warstwie aplikacji sieciowej (w warstwie 7) i korzysta z właściwości protokołów HTTP i HTTPS do filtrowania i routingu.
Usługa Front Door obsługuje wiele typów routingu niedostępnych dla usługi Traffic Manager. Można na przykład kierować ruch na podstawie kodu kraju przeglądarki. Usługa Front Door obsługuje również kończenie protokołu TLS.
Istnieje jednak jeden wyjątek. Jeśli chcemy kierować ruch dla dowolnego protokołu innego niż HTTP i HTTPS, musimy użyć usługi Traffic Manager.
Usługa Front Door umożliwia przypisywanie priorytetów do różnych zapleczy tworzących portal śledzenia. Te priorytety umożliwiają usłudze Front Door kierowanie żądań zgodnie z potrzebami. Przypisujemy nasze usługi regionu podstawowego z najwyższym priorytetem i naszą usługą regionu pomocniczego o niższym priorytcie.
Usługa Front Door implementuje sondy kondycji monitorujące stan kondycji naszych usług, dzięki czemu w przypadku wykrycia awarii może nastąpić prawidłowe przekierowanie ruchu. Tryb routingu oparty na priorytecie i monitorowanie punktów końcowych w usłudze Front Door to funkcje podobne do funkcji istniejących w usłudze Traffic Manager, z tą różnicą, że sondy kondycji zawsze działają za pośrednictwem protokołu HTTP.
Cały ruch internetowego interfejsu użytkownika naszego portalu wysyłki i jego interfejsów API odbywa się za pośrednictwem protokołu HTTPS, dzięki czemu możemy przełączyć się z usługi Traffic Manager do usługi Front Door. Możemy również skonfigurować usługę Front Door z priorytetowym przypisaniem zaplecza.
Azure CDN
W naszej architekturze z obsługą jednego regionu użyliśmy usługi Azure CDN do buforowania zawartości statycznej z usługi Azure Blob Storage. Usługa Azure CDN to globalna sieć serwerów, która buforuje zawartość statyczną w pobliżu użytkowników. Nie trzeba modyfikować tej usługi w architekturze z obsługą wielu regonów. Istnieją jednak zagadnienia dotyczące naszego konta usługi Azure Storage, które omówimy w następnej lekcji.