W tym artykule opisano sposób wdrażania aplikacji internetowych o znaczeniu krytycznym przy użyciu usługi aplikacja systemu Azure Service. Architektura używa niezawodnego wzorca aplikacji internetowej jako punktu wyjścia. Użyj tej architektury, jeśli masz starsze obciążenie i chcesz wdrożyć usługi typu "platforma jako usługa" (PaaS).
Niezawodny wzorzec aplikacji internetowej dla platformy .NET zawiera wskazówki dotyczące aktualizowania lub ponownego tworzenia aplikacji internetowych, które są przenoszone do chmury, minimalizowania wymaganych zmian kodu i określania celu poziomu usług (SLO) na poziomie 99,9%. Obciążenia o krytycznym znaczeniu mają wymagania dotyczące wysokiej niezawodności i dostępności. Aby osiągnąć cel SLO 99,95%, 99,99%, lub wyższy, należy zastosować dodatkowe wzorce projektowe o krytycznym znaczeniu i strukturę operacyjną. W tym artykule opisano kluczowe obszary techniczne oraz sposób wdrażania i wprowadzania rozwiązań projektowych o krytycznym znaczeniu.
Uwaga
Wskazówki zawarte w tym artykule są oparte na metodologii projektowania i najlepszych rozwiązaniach w serii obciążeń o znaczeniu krytycznym dla architektury Well-Architected Framework.
W poniższych sekcjach opisano, jak:
- Przejrzyj istniejące obciążenie, aby zrozumieć jego składniki, przepływy użytkownika i systemu oraz wymagania dotyczące dostępności i skalowalności.
- Opracuj i zaimplementuj architekturę jednostki skalowania, aby zoptymalizować kompleksową skalowalność poprzez podział i standaryzację procesu dodawania i usuwania pojemności.
- Zaimplementuj bezstanowe, efemeryczne jednostki skalowania lub sygnatury wdrożenia, aby umożliwić skalowanie i wdrożenia bez przestojów.
- Ustal, czy możesz podzielić obciążenie na składniki, aby przygotować się do skalowalności. Poszczególne składniki są wymagane do skalowania i oddzielenia przepływów.
- Przygotuj się do dystrybucji globalnej, wdrażając obciążenie w więcej niż jednym regionie świadczenia usługi Azure, aby zwiększyć bliskość klienta i przygotować się do potencjalnych awarii regionalnych.
- Rozdziel składniki i zaimplementuj architekturę opartą na zdarzeniach.
Architektura
Na poniższym diagramie opisano poprzednie zagadnienia dotyczące niezawodnego wzorca aplikacji internetowej.
Pobierz plik programu Visio z tą architekturą.
Czerwone pole reprezentuje jednostkę skalowania z usługami, które skalują się razem. Aby efektywnie skalować je razem, zoptymalizuj rozmiar usługi, jednostkę SKU i dostępne adresy IP. Na przykład maksymalna liczba żądań, które aplikacja systemu Azure Configuration obsługuje, jest skorelowana z liczbą żądań na sekundę zapewnianą przez jednostkę skalowania. Po dodaniu większej pojemności w regionie należy również dodać więcej pojedynczych jednostek skalowania.
Te poszczególne jednostki skalowania nie mają żadnych zależności między nimi i komunikują się tylko z usługami udostępnionymi poza jednostką skalowania indywidualnego. Możesz testować niezależne jednostki skalowania z góry. Aby uniknąć wpływu na inne obszary wdrażania, należy wdrożyć niezależne jednostki skalowania i wprowadzić opcję zastąpienia usług w nowej wersji.
W przypadku obciążeń o znaczeniu krytycznym niezależne jednostki skalowania są tymczasowe, co optymalizuje procesy wdrażania i zapewnia skalowalność w obrębie regionów i między nimi. Unikaj przechowywania stanu w niezależnych jednostkach skalowania. Rozważ użycie usługi Azure Cache for Redis do magazynowania w jednostce skalowania i przechowywanie tylko stanu krytycznego lub danych przechowywanych w bazie danych. Jeśli wystąpi awaria jednostki skalowania lub przełączysz się do innej jednostki skalowania, może wystąpić spowolnienie lub wymagane nowe logowanie, ale usługa Azure Cache for Redis nadal działa.
Szczegółowe informacje aplikacji jest wykluczona z jednostki skalowania. Wyklucz usługi, które przechowują lub monitorują dane. Rozdziel je na własną grupę zasobów przy użyciu własnego cyklu życia.
Po zastąpieniu jednostki skalowania lub wdrożeniu nowego zachowaj dane historyczne i użyj jednego wystąpienia na region.
Aby uzyskać więcej informacji, zobacz Projektowanie aplikacji obciążeń o znaczeniu krytycznym na platformie Azure.
Składniki
Ta architektura używa następujących składników.
- Usługa App Service to platforma hostingu aplikacji.
- Żądania pamięci podręcznej Azure Cache for Redis Cache.
- Usługa App Configuration przechowuje ustawienia konfiguracji.
- Usługa Azure SQL to baza danych zaplecza.
- Aplikacja Szczegółowe informacje pobiera dane telemetryczne z aplikacji.
Alternatywy
W niezawodnym wzorcu aplikacji internetowej można wykonywać następujące czynności:
- Użyj usługi Azure Kubernetes Service (AKS) zamiast usługi App Service. Ta opcja dobrze sprawdza się w przypadku złożonych obciążeń, które mają dużą liczbę mikrousług. Usługa AKS zapewnia większą kontrolę nad podstawową infrastrukturą i umożliwia złożone konfiguracje wielowarstwowe.
- Konteneryzowanie obciążenia. Usługa App Service obsługuje konteneryzację, ale w tym przykładzie obciążenie nie jest konteneryzowane. Użyj kontenerów, aby zwiększyć niezawodność i przenośność.
Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące platformy aplikacji dotyczące obciążeń o znaczeniu krytycznym na platformie Azure.
Wybieranie platformy aplikacji
Poziom dostępności zależy od wybranej i konfiguracji platformy aplikacji. Weź pod uwagę następujące wskazówki krytyczne dla misji:
- Jeśli to możliwe, użyj stref dostępności.
- Wybierz odpowiednią usługę platformy dla obciążenia.
- Konteneryzowanie obciążenia.
Zestawy dostępności rozpowszechniają wdrożenia w wielu domenach błędów i aktualizacji w centrum danych. Strefy dostępności rozmieszczają wdrożenia w poszczególnych centrach danych w regionie świadczenia usługi Azure. Strefy dostępności są często priorytetowe, ale używana strategia zależy od obciążenia. Na przykład obciążenia wrażliwe na opóźnienia lub czatty mogą korzystać z określania priorytetów zestawów dostępności. W przypadku rozłożenia obciążenia między strefy dostępności może zwiększyć opóźnienie i koszt ruchu między strefami. W przypadku korzystania ze stref dostępności upewnij się, że wszystkie usługi w jednostce skalowania obsługują je. Wszystkie usługi we wzorcu niezawodnej aplikacji internetowej obsługują strefy dostępności.
Wybieranie platformy danych
Wybrana platforma bazy danych ma wpływ na ogólną architekturę obciążenia, zwłaszcza obsługę konfiguracji aktywne-aktywne lub aktywne-pasywne platformy. Niezawodny wzorzec aplikacji internetowej korzysta z usługi Azure SQL, która nie obsługuje natywnie wdrożeń aktywnych-aktywnych z operacjami zapisu w więcej niż jednym wystąpieniu. Dlatego poziom bazy danych jest ograniczony do strategii aktywne-pasywne. Strategia aktywna-aktywna na poziomie aplikacji jest możliwa, jeśli istnieją repliki tylko do odczytu i zapisujesz tylko w jednym regionie.
Pobierz plik programu Visio z tą architekturą.
Wiele baz danych jest często spotykanych w złożonych architekturach, takich jak architektury mikrousług, które mają bazę danych dla każdej usługi. Wiele baz danych umożliwia wdrożenie wielodostępnej bazy danych zapisu, takiej jak Azure Cosmos DB, co zwiększa wysoką dostępność i małe opóźnienia. Opóźnienie między regionami może powodować ograniczenia. Ważne jest, aby wziąć pod uwagę niefunkcjonalne wymagania i czynniki, takie jak spójność, funkcjonalność, koszt i złożoność. Umożliwianie poszczególnym usługom używania oddzielnych magazynów danych i wyspecjalizowanych technologii danych w celu spełnienia ich unikatowych wymagań. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące platformy danych dotyczące obciążeń o znaczeniu krytycznym na platformie Azure.
Definiowanie modelu kondycji
W złożonych wielowarstwowych obciążeniach rozmieszczonych w wielu centrach danych i regionach geograficznych należy zdefiniować model kondycji. Definiowanie przepływów użytkownika i systemu, określanie i zrozumienie zależności między usługami, zrozumienie wpływu awarii lub obniżenia wydajności na jedną z usług może mieć ogólne obciążenie oraz monitorowanie i wizualizowanie środowiska klienta w celu umożliwienia odpowiedniego monitorowania i ulepszania ręcznych i zautomatyzowanych akcji.
Na poprzednim diagramie pokazano, jak awaria lub spadek pojedynczego składnika, takiego jak App Configuration, może spowodować potencjalne obniżenie wydajności klienta.
Po rozdzieleniu składników na jednostki skalowania można zatrzymać wysyłanie ruchu do objętej części aplikacji, takiej jak jednostka skalowania, której dotyczy problem, lub cały region.
Aby uzyskać więcej informacji, zobacz Modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure.
Zabezpieczenia i sieć
Istnieją ścisłe wymagania dotyczące sieci i zabezpieczeń dla obciążeń migrowanych z lokalnego wdrożenia przedsiębiorstwa. Nie wszystkie ustanowione procesy lokalne przekładają się na środowisko chmury. Oceń te wymagania, jeśli mają zastosowanie w środowiskach chmury.
Tożsamość jest często podstawowym obwodem zabezpieczeń dla wzorców natywnych dla chmury. Klienci korporacyjni mogą potrzebować bardziej znaczących środków zabezpieczeń. Aby spełnić wymagania dotyczące zabezpieczeń sieci, większość usług PaaS platformy Azure może używać usługi Azure Private Link do implementowania sieci jako obwodu zabezpieczeń. Usługa Private Link może zagwarantować, że usługi są dostępne tylko z poziomu sieci wirtualnej. Wszystkie usługi są dostępne tylko za pośrednictwem prywatnych punktów końcowych. Na poniższym diagramie pokazano, jak jedynym publicznym punktem końcowym dostępnym z Internetu jest usługa Azure Front Door.
Pobierz plik programu Visio z tą architekturą.
Aby wzorzec niezawodnej aplikacji internetowej skonfigurować sieć jako obwód zabezpieczeń, musi być używany:
- Usługa Private Link dla wszystkich usług, które go obsługują.
- Usługa Azure Front Door Premium jest jedynym publicznym punktem końcowym dostępnym z Internetu.
- Serwery przesiadkowe w celu uzyskiwania dostępu do usług za pośrednictwem usługi Azure Bastion.
- Własnych agentów kompilacji, którzy mogą uzyskiwać dostęp do usług.
Innym typowym wymaganiem sieciowym dla aplikacji o krytycznym znaczeniu jest ograniczenie ruchu wychodzącego w celu zapobiegania eksfiltracji danych. Ogranicz ruch wychodzący, rozsyłając zaporę platformy Azure przez odpowiednie urządzenie zapory i filtrując je za pomocą urządzenia. Architektura punktu odniesienia o krytycznym znaczeniu platformy Azure z kontrolkami sieci używa zapory i usługi Private Link.
Wdrażanie i testowanie
Przestój spowodowany błędami lub błędami ludzkimi może być problemem dla obciążenia, które musi być zawsze dostępne. Oto kilka kluczowych obszarów, które należy wziąć pod uwagę:
- Wdrożenia bez przestojów
- Efemeryczne wdrożenia niebieskie/zielone
- Analizowanie cyklu życia poszczególnych składników i grupowanie ich razem
- Ciągła walidacja
Wdrożenia bez przestojów są kluczowe dla obciążeń o znaczeniu krytycznym. Obciążenie, które musi być zawsze uruchomione, nie może mieć okna obsługi do wdrożenia nowszych wersji. Aby obejść to ograniczenie, architektura platformy Azure o znaczeniu krytycznym jest zgodna ze wzorcem wdrożeń bez przestojów. Zmiany są wdrażane jako nowe jednostki skalowania lub sygnatury, które są testowane na końcu przed przyrostowym kierowaniem ruchu do nich. Po skierowaniu całego ruchu do nowej sygnatury stare sygnatury są wyłączone i usuwane.
Aby uzyskać więcej informacji, zobacz Wdrażanie i testowanie obciążeń o znaczeniu krytycznym na platformie Azure.
Następne kroki
- ścieżka Edukacja: Tworzenie obciążeń o znaczeniu krytycznym na platformie Azure
- Projekt wyzwania: Projektowanie aplikacji internetowej o krytycznym znaczeniu
- Moduł szkoleniowy: Projektowanie modelu kondycji dla obciążenia o krytycznym znaczeniu
Powiązane zasoby
- Architektura punktu odniesienia o krytycznym znaczeniu na platformie Azure
- Architektura punktu odniesienia o krytycznym znaczeniu z kontrolkami sieci
- Architektura punktu odniesienia o krytycznym znaczeniu w strefie docelowej platformy Azure
- Ciągła walidacja przy użyciu testowania obciążenia platformy Azure i usługi Azure Chaos Studio