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 podczas uruchamiania procesu projektowania, a następnie wybierz składniki, które najlepiej odpowiadają wymaganiom biznesowym. Artykuł zaleca podejście do projektowania star północnej 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 przy jednoczesnym zachowaniu następujących cech.
| Charakterystyka | Zagadnienia do rozważenia |
|---|---|
| Okres istnienia | Jaki jest oczekiwany okres istnienia zasobu względem innych zasobów w rozwiązaniu? Czy zasób powinien być na żywo lub współużytkować okres istnienia całego systemu lub regionu, czy też powinien być tymczasowy? |
| Stan | Jaki wpływ będzie miał stan utrwalone w tej warstwie na niezawodność lub możliwości zarządzania? |
| Usługa Reach | 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? Ile skali dostarcza zasób, aby dopasować je do tego zapotrzebowania? |
| Dostępność/odzyskiwanie po awarii | Jaki jest wpływ na dostępność po awarii w tej warstwie? Czy może to spowodować awarię systemową lub problem z lokalną pojemnością lub dostępnością? |
Ważne
Ten artykuł jest częścią serii obciążeń azure Well-Architected o znaczeniu krytycznym . Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tego, co to jest obciążenie o znaczeniu krytycznym?
Niektóre zasoby są globalnie współużytkowane przez zasoby wdrożone w poszczególnych regionach. Typowe przykłady to zasoby używane do dystrybucji ruchu między wieloma regionami, przechowywanie stanu trwałego dla całej aplikacji i monitorowanie zasobów dla nich.
| Charakterystyka | Zagadnienia do rozważenia |
|---|---|
| Okres istnienia | Oczekuje się, że te zasoby będą długotrwałe (nie efemeryczne). Ich okres istnienia obejmuje okres istnienia systemu lub dłużej. Często zasoby są zarządzane przy użyciu aktualizacji płaszczyzny sterowania i danych w miejscu, przy założeniu, że obsługują operacje aktualizacji bez przestojów. |
| Stan | Ponieważ te zasoby istnieją przez co najmniej okres istnienia systemu, ta warstwa jest często odpowiedzialna za przechowywanie globalnego, zreplikowanego geograficznie stanu. |
| Usługa Reach | 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łymi opóźnieniami 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 wpisy tajne przechowywane w jednym magazynie mogą mieć globalny wpływ, jeśli wystąpi awaria regionalna, w której znajduje się magazyn. |
| Limity skalowania | Często te zasoby są pojedynczymi wystąpieniami w systemie i powinny mieć możliwość skalowania w taki sposób, że mogą obsługiwać przepływność systemu jako całości. |
| Dostępność/odzyskiwanie po awarii | Zasoby regionalne i sygnaturowe 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 realizacji transakcji biznesowych. Sygnatura zazwyczaj odpowiada wdrożeniu w regionie świadczenia usługi Azure. Chociaż region może mieć więcej niż jedną sygnaturę.
| Charakterystyka | Zagadnienia do rozważenia |
|---|---|
| Okres istnienia | Oczekuje się, że zasoby będą miały krótki okres życia (efemeryczny) z zamiarem, że można je dynamicznie dodawać i usuwać, podczas gdy zasoby regionalne poza sygnaturą będą nadal utrzymywane. Efemeryczny charakter jest potrzebny, aby zapewnić większą odporność, skalę i bliskość użytkowników. |
| Stan | Ponieważ sygnatury są efemeryczne i zostaną zniszczone przy każdym wdrożeniu, sygnatura powinna być bezstanowa, jak to możliwe. |
| Usługa Reach | Może komunikować się z zasobami regionalnymi i globalnymi. Należy jednak unikać komunikacji z innymi regionami lub innymi sygnaturami. |
| Zależności | Zasoby sygnatury muszą być niezależne. Oczekuje się, że będą 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. Przepływność ogólnej sygnatury jest ograniczona do najmniej wydajnego zasobu. 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ę przez ponowne wdrożenie sygnatury. Jeśli zasoby są w złej kondycji, sygnatura jako całość może zostać zniszczona i wdrożona ponownie. |
System może mieć zasoby, które są wdrażane w regionie, ale przetrwać zasoby sygnatury. Na przykład zasoby umożliwiające obserwowanie, które monitorują zasoby na poziomie regionalnym, w tym sygnatury.
| Charakterystyka | Kwestie do rozważenia |
|---|---|
| Okres istnienia | Zasoby współdzielą okres istnienia regionu i na żywo zasoby sygnatury. |
| Stan | Stan przechowywany w regionie nie może żyć poza okresem istnienia regionu. Jeśli stan musi być współużytkowany między regionami, rozważ użycie globalnego magazynu danych. |
| Usługa Reach | 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 | Ustal limit skali zasobów regionalnych, łącząc wszystkie sygnatury w regionie. |
Te przykłady punktów odniesienia pełnią rolę zalecanej architektury star północnej dla aplikacji o znaczeniu krytycznym. Punkt odniesienia zdecydowanie zaleca konteneryzację i używanie orkiestratora kontenerów dla platformy aplikacji. Punkt odniesienia używa Azure Kubernetes Service (AKS).
Jeśli dopiero zaczynasz podróż o znaczeniu krytycznym, użyj tej architektury jako odwołania. Dostęp do obciążenia jest uzyskiwany za pośrednictwem publicznego punktu końcowego i nie wymaga łączności sieciowej z innymi zasobami firmy.
Ta architektura opiera się na architekturze punktu odniesienia. Projekt jest rozszerzony, aby zapewnić ścisłe mechanizmy kontroli sieci, aby zapobiec nieautoryzowanemu dostępowi publicznemu z Internetu do zasobów obciążeń.
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, rozważając usługę 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 Co to są kluczowe obszary projektowania?
Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi projektowania scenariuszy aplikacji o znaczeniu krytycznym.