Ta przeglądarka nie jest już obsługiwana.
Przejdź na przeglądarkę Microsoft Edge, aby korzystać z najnowszych funkcji, aktualizacji zabezpieczeń i pomocy technicznej.
W tym artykule przedstawiono kluczowy wzorzec architektur o znaczeniu krytycznym na platformie Azure. Zastosuj ten wzorzec po rozpoczęciu procesu projektowania, a następnie wybierz składniki, które najlepiej nadają się do wymagań biznesowych. Artykuł zaleca north star podejście projektowe i zawiera inne przykłady z typowymi składnikami technologii.
Zalecamy ocenę kluczowych obszarów projektowych, zdefiniowanie krytycznych przepływów użytkownika i systemu korzystających z podstawowych składników oraz opracowanie macierzy zasobów platformy Azure i ich konfiguracji, mając na uwadze następujące cechy.
| Charakterystyczny | Zagadnienia dotyczące |
|---|---|
| Czas życia | Jaki jest oczekiwany okres istnienia zasobu względem innych zasobów w rozwiązaniu? Czy zasób powinien przetrwać okres istnienia lub dzielić czas życia z całym systemem lub regionem, czy powinien być tymczasowy? |
| Stan | Jaki wpływ będzie miał stan utrwalony w tej warstwie na niezawodność lub zarządzalność? |
| Zasięg | Czy zasób musi być dystrybuowany globalnie? Czy zasób może komunikować się z innymi zasobami znajdującymi się globalnie lub w tym regionie? |
| Zależności | Jakie są zależności od innych zasobów? |
| Limity skalowania | Jaka jest oczekiwana przepływność dla tego zasobu? Jaką skalę zapewnia zasób, aby zaspokoić to zapotrzebowanie? |
| Dostępność/odzyskiwanie po awarii | Jaki jest wpływ na dostępność z awarii w tej warstwie? Czy może to spowodować awarię systemową, czy tylko lokalny problem z pojemnością lub dostępnością? |
Ważny
Ten artykuł jest częścią serii obciążeń Well-Architected azure Well-Architected o znaczeniu krytycznym. Jeśli nie znasz tej serii, zalecamy rozpoczęcie od czym jest zadanie o znaczeniu krytycznym?
Niektóre zasoby są globalnie współużytkowane przez zasoby wdrożone w każdym regionie. Typowe przykłady to zasoby, które są używane do dystrybucji ruchu między wieloma regionami, przechowywania stanu trwałego dla całej aplikacji i monitorowania zasobów dla nich.
| Charakterystyczny | Zagadnienia dotyczące |
|---|---|
| Czas życia | Oczekuje się, że te zasoby będą długotrwałe (nie efemeryczne). Ich okres istnienia obejmuje żywotność systemu lub dłużej. Często zasoby są zarządzane za pomocą aktualizacji danych i płaszczyzny sterowania na miejscu, zakładając, że obsługują operacje aktualizacji bez przestojów. |
| Państwo | Ponieważ te zasoby istnieją przez co najmniej okres istnienia systemu, ta warstwa jest często odpowiedzialna za przechowywanie globalnego, zreplikowanego geograficznie stanu. |
| Zasięg | Zasoby powinny być globalnie dystrybuowane i replikowane do regionów hostujących te zasoby. Zaleca się, aby te zasoby komunikowały się z zasobami regionalnymi lub innymi zasobami z małym opóźnieniem i żądaną spójnością. |
| Zależności | Zasoby powinny unikać zależności od zasobów regionalnych, ponieważ ich niedostępność może być przyczyną awarii globalnej. Na przykład certyfikaty lub sekrety przechowywane w jednym skarbcu mogą mieć globalny wpływ, jeśli wystąpi awaria regionalna, w miejscu, gdzie znajduje się skarbiec. |
| Limity skalowania | Często te zasoby są instancjami singletonami w systemie i powinny być w stanie skalować się w taki sposób, aby mogły obsługiwać przepływność systemu jako całości. |
| Dostępność/odzyskiwanie po awarii | Zasoby regionalne i zasoby stempli mogą używać zasobów globalnych. Ważne jest, aby zasoby globalne zostały skonfigurowane z wysoką dostępnością i odzyskiwaniem po awarii dla kondycji całego systemu. |
Sygnatura zawiera aplikację i zasoby, które uczestniczą w realizowaniu transakcji biznesowych. Sygnatura zazwyczaj odpowiada wdrożeniu w regionie świadczenia usługi Azure. Chociaż region może mieć więcej niż jedną pieczęć.
| Charakterystyczny | Zagadnienia dotyczące |
|---|---|
| Okres życia | Oczekuje się, że zasoby będą miały krótki okres życia (efemeryczny), aby mogły być dynamicznie dodawane i usuwane, podczas gdy zasoby regionalne poza znacznikami będą nadal utrwalane. Efemeryczny charakter jest potrzebny, aby zapewnić większą odporność, skalę i bliskość użytkowników. |
| Stan | Ponieważ znaczki są efemeryczne i zostaną zniszczone przy każdym wdrożeniu, znaczki powinny być bezstanowe na tyle, na ile to możliwe. |
| Osiągnąć | Może komunikować się z zasobami regionalnymi i globalnymi. Należy jednak unikać komunikacji z innymi regionami lub innymi znaczkami. |
| Zależności | Zasoby pieczęci muszą być niezależne. Oczekuje się, że będą one mieć zależności regionalne i globalne, ale nie powinny polegać na składnikach w innych sygnaturach w tych samych lub innych regionach. |
| Limity skalowania | Przepływność jest ustanawiana przez testowanie. Przepustowość całego znaku jest ograniczona przez najmniej wydajny zasób. Przepływność sygnatur musi oszacować wysoki poziom zapotrzebowania spowodowany przejściem w tryb failover do innej sygnatury. |
| Dostępność/odzyskiwanie po awarii | Ze względu na tymczasowy charakter sygnatur odzyskiwanie po awarii odbywa się poprzez ponowne wdrożenie sygnatury. Jeśli zasoby są w złej kondycji, znacznik jako całość może zostać zniszczony i ponownie wdrożony. |
System może mieć zasoby wdrożone w regionie, które mogą trwać dłużej niż tymczasowe zasoby. Na przykład, zasoby obserwowalności, które monitorują zasoby na poziomie regionalnym, w tym znaczniki.
| Charakterystyczny | Rozwaga |
|---|---|
| Długość życia | Zasoby współdzielą okres istnienia regionu i przeżywają zasoby stempla. |
| Stan | Stan przechowywany w regionie nie może przetrwać dłużej niż czas życia regionu. Jeśli stan musi być dzielony między różne regiony, rozważ użycie globalnego magazynu danych. |
| Zasięg | Zasoby nie muszą być dystrybuowane globalnie. Należy unikać bezpośredniej komunikacji z innymi regionami za wszelką cenę. |
| Zależności | Zasoby mogą mieć zależności od zasobów globalnych, ale nie zasobów sygnatur, ponieważ sygnatury mają być krótkotrwałe. |
| Limity skalowania | Określ zakres skali zasobów regionalnych, łącząc wszystkie stemple w regionie. |
Te przykłady punktów odniesienia służą jako zalecana architektura gwiazdy północnej dla aplikacji o krytycznym znaczeniu. Punkt odniesienia zdecydowanie zaleca konteneryzację i używanie orkiestratora kontenerów dla platformy aplikacji. Punkt odniesienia używa usługi Azure Kubernetes Service (AKS).
Zapoznaj się z Well-Architected obciążeniami o znaczeniu krytycznym: konteneryzacja.
Jeśli dopiero zaczynasz swoją podróż o krytycznym znaczeniu, użyj tej architektury jako punktu odniesienia. Dostęp do obciążenia jest uzyskiwany za pośrednictwem publicznego punktu końcowego i nie wymaga prywatnej łączności sieciowej z innymi zasobami firmy.
Ta architektura opiera się na architekturze punktu odniesienia. Projekt został rozszerzony w celu zapewnienia ścisłej kontroli sieci w celu zapobiegania nieautoryzowanemu dostępowi publicznemu z Internetu do zasobów obciążenia.
Ta architektura jest odpowiednia, jeśli wdrażasz obciążenie w konfiguracji przedsiębiorstwa, w której wymagana jest integracja w szerszej organizacji. Obciążenie korzysta ze scentralizowanych usług udostępnionych, wymaga łączności lokalnej i integruje się z innymi obciążeniami w przedsiębiorstwie. Jest on wdrażany w subskrypcji strefy docelowej platformy Azure dziedziczonej z grupy zarządzania Corp.
Ta architektura rozszerza odniesienia, biorąc pod uwagę usługi App Services jako podstawową technologię hostingu aplikacji, zapewniając łatwe w użyciu środowisko na potrzeby wdrożeń kontenerów.
Zalecamy użycie podanych wskazówek projektowych w celu nawigowania po kluczowych decyzjach projektowych w celu osiągnięcia optymalnego rozwiązania. Aby uzyskać informacje, zobacz Jakie są kluczowe obszary projektowania?
Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi projektowania scenariuszy aplikacji o znaczeniu krytycznym.