Ta architektura zawiera wskazówki dotyczące projektowania obciążenia o znaczeniu krytycznym na platformie Azure. Wykorzystuje ona możliwości natywne dla chmury, aby zmaksymalizować niezawodność i efektywność operacyjną. Stosuje metodologię projektowania dla dobrze zaprojektowanych obciążeń o znaczeniu krytycznym dla aplikacji dostępnej z Internetu, w której dostęp do obciążenia odbywa się za pośrednictwem publicznego punktu końcowego i nie wymaga prywatnej łączności sieciowej z innymi zasobami firmy.
Ważne
Wskazówki są wspierane przez przykładową implementację klasy produkcyjnej, która prezentuje tworzenie aplikacji o kluczowym znaczeniu na platformie Azure. Ta implementacja może służyć jako podstawa do dalszego opracowywania rozwiązań w pierwszym kroku w kierunku produkcji.
Warstwa niezawodności
Niezawodność jest względną koncepcją i aby obciążenie było odpowiednio niezawodne, powinno odzwierciedlać wymagania biznesowe związane z nim, w tym cele poziomu usług (SLO) i umowy dotyczące poziomu usług (SLA), aby przechwycić procent czasu, w jaki aplikacja powinna być dostępna.
Ta architektura jest przeznaczona dla celu slo na 99,99%, co odpowiada dozwolonemu rocznemu przestojowi 52 minut i 35 sekund. Wszystkie objęte decyzje projektowe mają zatem na celu osiągnięcie tego celu slo.
Napiwek
Aby zdefiniować realistyczny cel slo, ważne jest, aby zrozumieć umowę SLA wszystkich składników platformy Azure w ramach architektury. Te poszczególne liczby powinny być agregowane w celu określenia złożonej umowy SLA , która powinna być zgodna z celami obciążenia.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o krytycznym znaczeniu: Projektowanie pod kątem wymagań biznesowych.
Kluczowe strategie projektowania
Wiele czynników może mieć wpływ na niezawodność aplikacji, na przykład możliwość odzyskania sprawności po awarii, dostępności regionalnej, skuteczności wdrożenia i zabezpieczeń. Ta architektura stosuje zestaw nadrzędnych strategii projektowych mających na celu rozwiązanie tych czynników i zapewnienie osiągnięcia docelowej warstwy niezawodności.
Nadmiarowość w warstwach
Wdróż w wielu regionach w modelu aktywny-aktywny. Aplikacja jest dystrybuowana w co najmniej dwóch regionach świadczenia usługi Azure, które obsługują aktywny ruch użytkowników.
Skorzystaj z Strefy dostępności (AZ) dla wszystkich rozważanych usług, aby zmaksymalizować dostępność w jednym regionie świadczenia usługi Azure, dystrybuując składniki w fizycznie oddzielnych centrach danych w regionie.
Wybierz zasoby, które obsługują dystrybucję globalną.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: Dystrybucja globalna.
Sygnatury wdrożenia
Wdróż sygnaturę regionalną jako jednostkę skalowania, w której można niezależnie aprowizować logiczny zestaw zasobów, aby nadążyć za zmianami zapotrzebowania. Każda sygnatura stosuje również wiele zagnieżdżonych jednostek skalowania, takich jak interfejsy API frontonu i procesory w tle, które mogą być skalowane niezależnie i w poziomie.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: architektura jednostki skalowania.
Niezawodne i powtarzalne wdrożenia
Zastosuj zasadę infrastruktury jako kodu (IaC) przy użyciu technologii, takich jak Terraform, w celu zapewnienia kontroli wersji i ustandaryzowanego podejścia operacyjnego dla składników infrastruktury.
Zaimplementuj potoki wdrażania bez przestoju niebieskiego/zielonego. Potoki kompilacji i wydania muszą być w pełni zautomatyzowane, aby wdrażać sygnatury jako pojedynczą jednostkę operacyjną przy użyciu wdrożeń niebieskich/zielonych z zastosowaniem ciągłej weryfikacji.
Zastosuj spójność środowiska we wszystkich rozważanych środowiskach z tym samym kodem potoku wdrażania w środowiskach produkcyjnych i przedprodukcyjnych. Eliminuje to ryzyko związane z wdrażaniem i odmianami procesów w środowiskach.
Ciągła walidacja przez zintegrowanie zautomatyzowanego testowania w ramach procesów DevOps, w tym zsynchronizowanego obciążenia i testowania chaosu, w celu pełnego zweryfikowania kondycji kodu aplikacji i podstawowej infrastruktury.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: Wdrażanie i testowanie.
Szczegółowe informacje operacyjne
Mają obszary robocze federacyjne w celu obserwowania danych. Dane monitorowania zasobów globalnych i zasobów regionalnych są przechowywane niezależnie. Scentralizowany magazyn obserwacji nie jest zalecany, aby uniknąć pojedynczego punktu awarii. Wykonywanie zapytań między obszarami roboczymi służy do osiągnięcia ujednoliconego ujścia danych i pojedynczego okienka szkła na potrzeby operacji.
Skonstruuj model kondycji warstwowej, który mapuje kondycję aplikacji na model światła drogowego na potrzeby kontekstowego określania kontekstu. Wyniki kondycji są obliczane dla każdego składnika, a następnie agregowane na poziomie przepływu użytkownika i połączone z kluczowymi wymaganiami niefunkcjonalnościowymi, takimi jak wydajność, jako współczynniki kwantyfikowania kondycji aplikacji.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o krytycznym znaczeniu: Modelowanie kondycji.
Architektura
*Pobierz plik programu Visio tej architektury.
Składniki tej architektury mogą być szeroko podzielone na kategorie. Aby uzyskać dokumentację produktu dotyczącą usług platformy Azure, zobacz Powiązane zasoby.
Zasoby globalne
Zasoby globalne są długotrwałe i współdzielą okres istnienia systemu. Mają one możliwość globalnego udostępniania w kontekście modelu wdrażania w wielu regionach.
Poniżej przedstawiono ogólne zagadnienia dotyczące składników. Aby uzyskać szczegółowe informacje na temat decyzji, zobacz Zasoby globalne.
Globalny moduł równoważenia obciążenia
Globalny moduł równoważenia obciążenia ma kluczowe znaczenie dla niezawodnego kierowania ruchu do wdrożeń regionalnych przy użyciu pewnego poziomu gwarancji na podstawie dostępności usług zaplecza w regionie. Ponadto ten składnik powinien mieć możliwość sprawdzania ruchu przychodzącego, na przykład za pośrednictwem zapory aplikacji internetowej.
Usługa Azure Front Door jest używana jako globalny punkt wejścia dla całego przychodzącego ruchu HTTP klienta z funkcjami zapory aplikacji internetowej (WAF) zastosowanymi do bezpiecznego ruchu przychodzącego warstwy 7. Używa protokołu TCP Anycast do optymalizowania routingu przy użyciu sieci szkieletowej firmy Microsoft i umożliwia przezroczyste przejście w tryb failover w przypadku obniżonej kondycji regionalnej. Routing jest zależny od niestandardowych sond kondycji, które sprawdzają złożone ciepło kluczowych zasobów regionalnych. Usługa Azure Front Door udostępnia również wbudowaną sieć dostarczania zawartości (CDN) do buforowania statycznych zasobów dla składnika witryny internetowej.
Inną opcją jest usługa Traffic Manager, która jest opartym na systemie DNS modułem równoważenia obciążenia warstwy 4. Jednak niepowodzenie nie jest niewidoczne dla wszystkich klientów, ponieważ propagacja DNS musi wystąpić.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: globalny routing ruchu.
Baza danych
Cały stan związany z obciążeniem jest przechowywany w zewnętrznej bazie danych Azure Cosmos DB for NoSQL. Ta opcja została wybrana, ponieważ ma zestaw funkcji wymagany do dostrajania wydajności i niezawodności, zarówno po stronie klienta, jak i serwera. Zdecydowanie zaleca się, aby konto ma włączoną funkcję zapisu wielowzorcowego.
Uwaga
Podczas gdy konfiguracja zapisu w wielu regionach reprezentuje złoty standard niezawodności, istnieje znaczny kompromis kosztów, który należy odpowiednio rozważyć.
Konto jest replikowane do każdej sygnatury regionalnej, a także ma włączoną nadmiarowość strefową. Ponadto skalowanie automatyczne jest włączone na poziomie kontenera, aby kontenery automatycznie skalowały aprowizowaną przepływność zgodnie z potrzebami.
Aby uzyskać więcej informacji, zobacz Platforma danych dla obciążeń o znaczeniu krytycznym.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: rozproszony globalnie wielopisania magazyn danych.
Rejestr kontenerów
Usługa Azure Container Registry służy do przechowywania wszystkich obrazów kontenerów. Ma ona możliwości replikacji geograficznej, które umożliwiają zasobom działanie jako pojedynczy rejestr, obsługujących wiele regionów z rejestrami regionalnymi z wieloma głównymi rejestrami regionalnymi.
Jako środek zabezpieczeń zezwalaj tylko na dostęp do wymaganych jednostek i uwierzytelnianie tego dostępu. Na przykład w implementacji dostęp administratora jest wyłączony. Dlatego klaster obliczeniowy może ściągać obrazy tylko w przypadku przypisań ról firmy Microsoft Entra.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: Rejestr kontenerów.
Zasoby regionalne
Zasoby regionalne są aprowidowane w ramach sygnatury wdrożenia w jednym regionie świadczenia usługi Azure. Te zasoby nie mają nic wspólnego z zasobami w innym regionie. Można je usunąć niezależnie lub replikować do dodatkowych regionów. Współdzielą one jednak zasoby globalne między sobą.
W tej architekturze ujednolicony potok wdrażania wdraża sygnaturę z tymi zasobami.
Poniżej przedstawiono ogólne zagadnienia dotyczące składników. Aby uzyskać szczegółowe informacje o decyzjach, zobacz Zasoby sygnatur regionalnych.
Fronton
Ta architektura używa aplikacji jednostronicowej (SPA), która wysyła żądania do usług zaplecza. Zaletą jest to, że zasoby obliczeniowe potrzebne do środowiska witryny internetowej są odciążane do klienta zamiast serwerów. SPA jest hostowana jako statyczna witryna internetowa na koncie usługi Azure Storage.
Innym wyborem jest usługa Azure Static Web Apps, która wprowadza dodatkowe zagadnienia, takie jak uwidocznienie certyfikatów, łączność z globalnym modułem równoważenia obciążenia i inne czynniki.
Zawartość statyczna jest zwykle buforowana w magazynie blisko klienta przy użyciu sieci dostarczania zawartości (CDN), dzięki czemu dane mogą być obsługiwane szybko bez bezpośredniej komunikacji z serwerami zaplecza. Jest to ekonomiczny sposób na zwiększenie niezawodności i zmniejszenie opóźnienia sieci. W tej architekturze wbudowane funkcje usługi CDN usługi Azure Front Door są używane do buforowania zawartości statycznej witryny internetowej w sieci brzegowej.
Klaster obliczeniowy
Środowisko obliczeniowe zaplecza uruchamia aplikację składającą się z trzech mikrousług i jest bezstanowa. W związku z tym konteneryzacja jest odpowiednią strategią hostowania aplikacji. Wybrano usługę Azure Kubernetes Service (AKS), ponieważ spełnia ona większość wymagań biznesowych, a platforma Kubernetes jest powszechnie stosowana w wielu branżach. Usługa AKS obsługuje zaawansowane topologie skalowalności i wdrażania. Warstwa SLA czasu działania usługi AKS jest zdecydowanie zalecana do hostowania aplikacji o znaczeniu krytycznym, ponieważ zapewnia gwarancje dostępności dla płaszczyzny sterowania platformy Kubernetes.
Platforma Azure oferuje inne usługi obliczeniowe, takie jak Azure Functions i aplikacja systemu Azure Services. Te opcje odciążają dodatkowe obowiązki związane z zarządzaniem platformą Azure kosztem elastyczności i gęstości.
Uwaga
Unikaj przechowywania stanu w klastrze obliczeniowym, pamiętając o efemerycznym charakterze sygnatur. Jak najwięcej, utrzymuj stan w zewnętrznej bazie danych, aby zachować uproszczone operacje skalowania i odzyskiwania. Na przykład w usłudze AKS zasobniki zmieniają się często. Dołączanie stanu do zasobników spowoduje dodanie obciążenia spójności danych.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o krytycznym znaczeniu: Orkiestracja kontenerów i Platforma Kubernetes.
Broker komunikatów regionalnych
Aby zoptymalizować wydajność i zachować czas reakcji podczas szczytowego obciążenia, projekt używa asynchronicznych komunikatów do obsługi intensywnych przepływów systemowych. Ponieważ żądanie jest szybko potwierdzane z powrotem do interfejsów API frontonu, żądanie jest również kolejkowane w brokerze komunikatów. Te komunikaty są następnie używane przez usługę zaplecza, która na przykład obsługuje operację zapisu w bazie danych.
Cała sygnatura jest bezstanowa z wyjątkiem niektórych punktów, takich jak ten broker komunikatów. Dane są kolejkowane w brokerze przez krótki czas. Broker komunikatów musi zagwarantować co najmniej jednokrotne dostarczanie. Oznacza to, że komunikaty będą znajdować się w kolejce, jeśli broker stanie się niedostępny po przywróceniu usługi. Jednak użytkownik ponosi odpowiedzialność za ustalenie, czy te komunikaty nadal wymagają przetwarzania. Kolejka jest opróżniana po przetworzeniu i zapisaniu komunikatu w globalnej bazie danych.
W tym projekcie jest używana usługa Azure Event Hubs . Dodatkowe konto usługi Azure Storage jest aprowidowane na potrzeby tworzenia punktów kontrolnych. Usługa Event Hubs jest zalecanym wyborem dla przypadków użycia wymagających wysokiej przepływności, takich jak przesyłanie strumieniowe zdarzeń.
W przypadku przypadków użycia, które wymagają dodatkowych gwarancji komunikatów, zalecane jest użycie usługi Azure Service Bus. Umożliwia ona zatwierdzanie dwufazowe z kursorem po stronie klienta, a także funkcje, takie jak wbudowana kolejka utraconych komunikatów i możliwości deduplikacji.
Aby uzyskać więcej informacji, zobacz Usługi obsługi komunikatów dla obciążeń o znaczeniu krytycznym.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: luźno połączona architektura sterowana zdarzeniami.
Regionalny magazyn wpisów tajnych
Każda sygnatura ma własną usługę Azure Key Vault , która przechowuje wpisy tajne i konfigurację. Istnieją typowe wpisy tajne, takie jak parametry połączenia do globalnej bazy danych, ale istnieją również informacje unikatowe dla pojedynczej sygnatury, takie jak usługa Event Hubs parametry połączenia. Ponadto niezależne zasoby unikają pojedynczego punktu awarii.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: Ochrona integralności danych.
Potok wdrażania
Potoki kompilacji i wydawania dla aplikacji o znaczeniu krytycznym muszą być w pełni zautomatyzowane. W związku z tym żadna akcja nie powinna być wykonywana ręcznie. Ten projekt pokazuje w pełni zautomatyzowane potoki, które stale wdrażają zweryfikowaną sygnaturę. Innym alternatywnym podejściem jest wdrożenie aktualizacji rolowych tylko w istniejącej sygnaturze.
Repozytorium kodu źródłowego
Usługa GitHub jest używana do kontroli źródła, zapewniając platformę git opartą na wysokiej dostępności na potrzeby współpracy nad kodem aplikacji i kodem infrastruktury.
Potoki ciągłej integracji/ciągłego dostarczania (CI/CD)
Zautomatyzowane potoki są wymagane do kompilowania, testowania i wdrażania obciążenia misji w środowiskach przedprodukcyjnych i produkcyjnych. Usługa Azure Pipelines jest wybierana, biorąc pod uwagę bogaty zestaw narzędzi, który może kierować się na platformę Azure i inne platformy w chmurze.
Innym wyborem jest funkcja GitHub Actions dla potoków ciągłej integracji/ciągłego wdrażania. Dodatkową korzyścią jest to, że kod źródłowy i potok można sortować. Jednak usługa Azure Pipelines została wybrana z powodu bogatszych możliwości ciągłego wdrażania.
Zapoznaj się z tematem Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: procesy DevOps.
Agenci kompilacji
Agenci kompilacji hostowani przez firmę Microsoft są używane przez tę implementację w celu zmniejszenia złożoności i nakładu pracy związanego z zarządzaniem. Agentów hostowanych samodzielnie można używać w scenariuszach wymagających wzmocnionego poziomu zabezpieczeń.
Uwaga
Użycie własnych agentów jest pokazane w implementacji referencyjnej Mission Critical — Połączenie ed.
Zasoby do obserwowania
Dane operacyjne z aplikacji i infrastruktury muszą być dostępne, aby umożliwić efektywne operacje i zmaksymalizować niezawodność. Ta dokumentacja stanowi punkt odniesienia umożliwiający uzyskanie całościowej obserwacji aplikacji.
Ujednolicony ujście danych
- Usługa Azure Log Analytics jest używana jako ujednolicony ujście do przechowywania dzienników i metryk dla wszystkich składników aplikacji i infrastruktury.
- aplikacja systemu Azure Szczegółowe informacje jest używany jako narzędzie do zarządzania wydajnością aplikacji (APM) do zbierania wszystkich danych monitorowania aplikacji i przechowywania ich bezpośrednio w usłudze Log Analytics.
Dane monitorowania zasobów globalnych i zasobów regionalnych powinny być przechowywane niezależnie. Pojedynczy, scentralizowany magazyn obserwacji nie jest zalecany, aby uniknąć pojedynczego punktu awarii. Wykonywanie zapytań między obszarami roboczymi służy do osiągnięcia jednego okienka szkła.
W tej architekturze zasoby monitorowania w regionie muszą być niezależne od samej sygnatury, ponieważ w przypadku usunięcia sygnatury nadal chcesz zachować możliwość obserwowania. Każda sygnatura regionalna ma własną dedykowaną aplikację Szczegółowe informacje i obszar roboczy usługi Log Analytics. Zasoby są aprowidowane w poszczególnych regionach, ale przeżywają sygnatury.
Podobnie dane z usług udostępnionych, takich jak Azure Front Door, Azure Cosmos DB i Container Registry, są przechowywane w dedykowanym wystąpieniu obszaru roboczego usługi Log Analytics.
Archiwizowanie i analiza danych
Dane operacyjne, które nie są wymagane w przypadku aktywnych operacji, są eksportowane z usługi Log Analytics do kont usługi Azure Storage na potrzeby przechowywania danych oraz do zapewnienia źródła analitycznego dla metodyki AIOps, które można zastosować do optymalizacji modelu kondycji aplikacji i procedur operacyjnych.
Zapoznaj się z dobrze zaprojektowanymi obciążeniami o krytycznym znaczeniu: działanie predykcyjne i operacje sztucznej inteligencji.
Przepływy żądań i procesora
Na tej ilustracji przedstawiono przepływ procesora żądania i tła implementacji odwołania.
Opis tego przepływu znajduje się w poniższych sekcjach.
Przepływ żądań witryny internetowej
Żądanie interfejsu użytkownika sieci Web jest wysyłane do globalnego modułu równoważenia obciążenia. W przypadku tej architektury globalny moduł równoważenia obciążenia to Azure Front Door.
Reguły zapory aplikacji internetowej są oceniane. Reguły zapory aplikacji internetowej pozytywnie wpływają na niezawodność systemu, chroniąc przed różnymi atakami, takimi jak wykonywanie skryptów między witrynami (XSS) i wstrzyknięcie kodu SQL. Usługa Azure Front Door zwróci błąd do osoby żądającego, jeśli zostanie naruszona reguła zapory aplikacji internetowej i przetwarzanie zostanie zatrzymane. Jeśli nie zostaną naruszone żadne reguły zapory aplikacji internetowej, usługa Azure Front Door kontynuuje przetwarzanie.
Usługa Azure Front Door używa reguł routingu, aby określić, do której puli zaplecza należy przesłać żądanie. Sposób dopasowywania żądań do reguły routingu. W tej implementacji referencyjnej reguły routingu umożliwiają usłudze Azure Front Door kierowanie żądań interfejsu użytkownika i interfejsu API frontonu do różnych zasobów zaplecza. W tym przypadku wzorzec "/*" jest zgodny z regułą routingu interfejsu użytkownika. Ta reguła kieruje żądanie do puli zaplecza zawierającej konta magazynu ze statycznymi witrynami internetowymi hostujących aplikację jednostronicową (SPA). Usługa Azure Front Door używa priorytetu i wagi przypisanej do zapleczy w puli, aby wybrać zaplecze w celu kierowania żądania. Metody routingu ruchu do źródła. Usługa Azure Front Door używa sond kondycji, aby upewnić się, że żądania nie są kierowane do zapleczy, które nie są w dobrej kondycji. SPA jest obsługiwane z wybranego konta magazynu ze statyczną witryną internetową.
Uwaga
Terminy pule zaplecza i zaplecza w usłudze Azure Front Door Classic są nazywane grupami pochodzenia i źródłami w warstwach Standardowa lub Premium usługi Azure Front Door.
SPA wykonuje wywołanie interfejsu API do hosta frontonu usługi Azure Front Door. Wzorzec adresu URL żądania interfejsu API to "/api/*".
Przepływ żądania interfejsu API frontonu
Reguły zapory aplikacji internetowej są oceniane podobnie jak w kroku 2.
Usługa Azure Front Door dopasuje żądanie do reguły routingu interfejsu API według wzorca "/api/*". Reguła routingu interfejsu API kieruje żądanie do puli zaplecza zawierającej publiczne adresy IP kontrolerów ruchu przychodzącego NGINX, które wiedzą, jak kierować żądania do właściwej usługi w usłudze Azure Kubernetes Service (AKS). Podobnie jak wcześniej usługa Azure Front Door używa priorytetu i wagi przypisanej do zapleczy w celu wybrania poprawnego zaplecza kontrolera ruchu przychodzącego NGINX.
W przypadku żądań GET interfejs API frontonu wykonuje operacje odczytu w bazie danych. W przypadku tej implementacji referencyjnej baza danych jest globalnym wystąpieniem usługi Azure Cosmos DB. Usługa Azure Cosmos DB ma kilka funkcji, które sprawiają, że jest dobrym wyborem dla obciążenia o znaczeniu krytycznym, w tym możliwość łatwego konfigurowania regionów z wieloma zapisami, co umożliwia automatyczne przechodzenie w tryb failover dla operacji odczytu i zapisu w regionach pomocniczych. Interfejs API używa zestawu SDK klienta skonfigurowanego z logiką ponawiania prób do komunikowania się z usługą Azure Cosmos DB. Zestaw SDK określa optymalną kolejność dostępnych regionów usługi Azure Cosmos DB do komunikowania się na podstawie parametru ApplicationRegion.
W przypadku żądań POST lub PUT interfejs API frontonu wykonuje operacje zapisu w brokerze komunikatów. W implementacji referencyjnej broker komunikatów to Azure Event Hubs. Alternatywnie możesz wybrać usługę Service Bus. Procedura obsługi będzie później odczytywać komunikaty z brokera komunikatów i wykonywać wszystkie wymagane zapisy w usłudze Azure Cosmos DB. Interfejs API używa zestawu SDK klienta do wykonywania operacji zapisu. Klienta można skonfigurować pod kątem ponownych prób.
Przepływ procesora w tle
Procesory w tle przetwarzają komunikaty z brokera komunikatów. Procesory w tle używają zestawu SDK klienta do wykonywania operacji odczytu. Klienta można skonfigurować pod kątem ponownych prób.
Procesory w tle wykonują odpowiednie operacje zapisu w globalnym wystąpieniu usługi Azure Cosmos DB. Procesory w tle używają zestawu SDK klienta skonfigurowanego przy użyciu ponawiania prób w celu nawiązania połączenia z usługą Azure Cosmos DB. Listę preferowanych regionów klienta można skonfigurować z wieloma regionami. W takim przypadku, jeśli zapis zakończy się niepowodzeniem, próba zostanie wykonana w następnym preferowanym regionie.
Obszary projektowe
Zalecamy zapoznanie się z tymi obszarami projektowania pod kątem zaleceń i wskazówek dotyczących najlepszych rozwiązań podczas definiowania architektury o znaczeniu krytycznym.
| Obszar projektowania | opis |
|---|---|
| Projekt aplikacji | Wzorce projektowe, które umożliwiają skalowanie i obsługę błędów. |
| Platforma aplikacji | Opcje infrastruktury i środki zaradcze dla potencjalnych przypadków awarii. |
| Platforma danych | Wybory w technologiach magazynu danych, informowane przez ocenę wymaganej ilości, szybkości, różnorodności i właściwości wierzchołków. |
| Sieć i łączność | Zagadnienia dotyczące sieci dotyczące routingu ruchu przychodzącego do sygnatur. |
| Modelowanie kondycji | Zagadnienia dotyczące obserwacji za pośrednictwem analizy wpływu klientów skorelowane monitorowanie w celu określenia ogólnej kondycji aplikacji. |
| Wdrażanie i testowanie | Strategie dotyczące potoków ciągłej integracji/ciągłego wdrażania i zagadnień automatyzacji, z włączonymi scenariuszami testowania, takimi jak synchronizowane testowanie obciążenia i testowanie błędów (chaos). |
| Bezpieczeństwo | Środki zaradcze wektorów ataków za pośrednictwem modelu Microsoft Zero Trust. |
| Procedury operacyjne | Procesy związane z wdrażaniem, zarządzaniem kluczami, stosowaniem poprawek i aktualizacjami. |
** Wskazuje zagadnienia dotyczące obszaru projektowania specyficzne dla tej architektury.
Powiązane zasoby
Aby uzyskać dokumentację produktu dotyczącą usług platformy Azure używanych w tej architekturze, zobacz te artykuły.
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Program Azure Log Analytics
- Azure Key Vault
- Azure Service Bus
- Azure Kubernetes Service
- Azure Application Insights
- Azure Event Hubs
- Azure Blob Storage
Wdrażanie tej architektury
Wdróż implementację referencyjną, aby uzyskać pełną wiedzę na temat rozważanych zasobów, w tym sposobu ich działania w kontekście o znaczeniu krytycznym. Zawiera on przewodnik wdrażania przeznaczony do zilustrowania podejścia zorientowanego na rozwiązanie na potrzeby tworzenia aplikacji o kluczowym znaczeniu na platformie Azure.
Następne kroki
Jeśli chcesz rozszerzyć architekturę linii bazowej przy użyciu kontrolek sieci w ruchu przychodzącym i wychodzącym, zobacz tę architekturę.