Architektura N-warstwowa dzieli aplikację na warstwy logiczne i warstwy fizyczne.
Warstwy służą do rozdzielenia odpowiedzialności i zarządzania zależnościami. Każda warstwa ma konkretną odpowiedzialność. Wyższe warstwy mogą korzystać z usług w niższej warstwie, ale nie odwrotnie.
Warstwy są fizycznie oddzielone, uruchomione na oddzielnych maszynach. W umowie warstwa może mieć swoje modele komunikacji ścisłe lub zrelaksowane. W ścisłym modelu żądanie musi przechodzić przez sąsiadujące warstwy, po jednym po drugim i nie może pominąć żadnej warstwy między. Na przykład z zapory aplikacji internetowej do warstwy internetowej, a następnie do warstwy środkowej 1 itd. Natomiast w przypadku złagodzonego podejścia żądanie może pominąć niektóre warstwy, jeśli jest to konieczne. Ścisłe podejście ma większe opóźnienie i obciążenie, a podejście zrelaksowane ma więcej sprzężeń, a następnie trudniej jest zmienić. System może korzystać z podejścia hybrydowego: w razie potrzeby zarówno złagodzone, jak i ścisłe warstwy.
Warstwa może wywoływać inną warstwę bezpośrednio lub używać wzorców asynchronicznych obsługi komunikatów za pośrednictwem kolejki komunikatów. Mimo że każda warstwa może być hostowana we własnej warstwie, nie jest to wymagane. Kilka warstw może być hostowanych na tej samej warstwie. Fizyczne odseparowanie warstw poprawia skalowalność i odporność, ale również dodaje opóźnienie spowodowane dodatkową komunikacją sieciową.
Tradycyjna aplikacja trójwarstwowa ma warstwę prezentacji, warstwę środkową i warstwę bazy danych. Warstwa środkowa jest opcjonalna. Bardziej złożone aplikacje mogą mieć więcej niż trzy warstwy. Na powyższym diagramie przedstawiono aplikację z dwiema warstwami środkowymi, hermetyzującymi różne obszary funkcji.
N-warstwowa aplikacja może mieć zamkniętą architekturę warstwową lub otwartą architekturę warstwową:
- W zamkniętej architekturze warstwowej warstwa może wywoływać tylko następną warstwę bezpośrednio pod nią.
- W otwartej architekturze warstwowej warstwa może wywoływać dowolną z warstw poniżej niej.
Zamknięta architektura warstwowa ogranicza zależności między warstwami. Może jednak generować niepotrzebny ruch sieciowy, jeśli jedna warstwa po prostu przekazuje żądania do następnej warstwy.
Kiedy stosować tę architekturę
Architektury n-warstwowe są zwykle implementowane jako aplikacje typu infrastruktura jako usługa (IaaS), z każdą warstwą uruchomioną w osobnym zestawie maszyn wirtualnych. Jednak aplikacja n-warstwowa nie musi być czystą aplikacją IaaS. Często korzystne jest użycie usług zarządzanych dla niektórych części architektury, szczególnie buforowania, obsługi komunikatów i magazynu danych.
Architekturę N-warstwową należy rozważyć w przypadku:
- Prostych aplikacji internetowych.
- Dobry punkt wyjścia, gdy wymagania dotyczące architektury nie są jeszcze jasne.
- Migrowania aplikacji lokalnej do platformy Azure z minimalną refaktoryzacją.
- Ujednolicone opracowywanie aplikacji lokalnych i w chmurze.
Architektury n-warstwowe są bardzo popularne w tradycyjnych aplikacjach lokalnych, a więc jest to naturalny wybór na potrzeby migrowania istniejących obciążeń na platformę Azure.
Świadczenia
- Przenośność między środowiskiem lokalnym a chmurą oraz między platformami chmury.
- Mniej nauki dla większości deweloperów.
- Stosunkowo niski koszt dzięki niewzłodnianiu architektury rozwiązania
- Naturalna ewolucja z tradycyjnego modelu aplikacji.
- Otwartość na środowiska heterogeniczne (Windows/Linux)
Wyzwania
- Łatwo skończyć z warstwą środkową, która tylko wykonuje operacje CRUD na bazie danych, dodając opóźnienie bez wykonywania jakiejkolwiek przydatnej pracy.
- Monolityczny projekt uniemożliwia niezależne wdrażanie funkcji.
- Zarządzanie aplikacją IaaS wymaga więcej pracy niż zarządzanie aplikacją, która korzysta tylko z usług zarządzanych.
- Zarządzanie zabezpieczeniami sieci w dużym systemie może być trudne.
- Przepływy użytkowników i danych zwykle obejmują wiele warstw, co zwiększa złożoność problemów, takich jak testowanie i obserwowanie.
Najlepsze rozwiązania
- Używanie skalowania automatycznego do obsługi zmian obciążenia. Zobacz Autoscaling best practices (Najlepsze rozwiązania dotyczące skalowania automatycznego).
- Użyj asynchronicznej obsługi komunikatów , aby rozdzielić warstwy.
- Buforuj dane semistatyczne. Zobacz Caching best practices (Najlepsze rozwiązania dotyczące buforowania).
- Skonfiguruj warstwę bazy danych pod kątem wysokiej dostępności przy użyciu rozwiązania, takiego jak zawsze włączone grupy dostępności programu SQL Server.
- Umieszczenie zapory aplikacji internetowych między frontonem a Internetem.
- Umieszczenie każdej warstwy w jej własnej podsieci i używanie podsieci jako granicy zabezpieczeń.
- Ograniczenie dostępu do warstwy danych przez zezwolenie na żądania tylko z warstw środkowych.
Architektura n-warstwowa na maszynach wirtualnych
W tej sekcji opisano zalecaną architekturę n-warstwową działającą na maszynach wirtualnych.
Każda warstwa składa się z co najmniej dwóch maszyn wirtualnych umieszczonych w zestawie dostępności lub zestawie skalowania maszyn wirtualnych. Wiele maszyn wirtualnych zapewnia odporność na wypadek awarii jednej maszyny wirtualnej. Moduły równoważenia obciążenia są używane do rozkładania żądań na maszyny wirtualne w warstwie. Warstwę można skalować w poziomie przez dodawanie większej liczby maszyn wirtualnych do puli.
Każda warstwa jest również umieszczona wewnątrz swojej własnej podsieci, co oznacza, że jej adresy IP należą do tego samego zakresu adresów. Ułatwia to stosowanie reguł sieciowej grupy zabezpieczeń i tabel tras do poszczególnych warstw.
Warstwy internetowe i biznesowe są bezstanowe. Dowolna maszyna wirtualna może obsługiwać każde żądanie dla tej warstwy. Warstwa danych powinna składać się z replikowanej bazy danych. W przypadku systemu Windows zalecamy używanie zawsze włączonych grup dostępności programu SQL Server w celu zapewnienia wysokiej dostępności. W przypadku systemu Linux wybierz bazę danych, która obsługuje replikację, taką jak Apache Cassandra.
Sieciowe grupy zabezpieczeń ograniczają dostęp do każdej warstwy. Na przykład warstwa bazy danych umożliwia dostęp z warstwy biznesowej.
Uwaga
Warstwa oznaczona etykietą "Warstwa biznesowa" na naszym diagramie odniesienia jest pseudonimem dla warstwy logiki biznesowej. Podobnie nazywamy warstwę prezentacji warstwą "Warstwa internetowa". W naszym przykładzie jest to aplikacja internetowa, chociaż architektury wielowarstwowe mogą być również używane dla innych topologii (takich jak aplikacje klasyczne). Nazwij warstwy, które najlepiej sprawdzają się dla zespołu, aby komunikować intencję tej warstwy logicznej i/lub fizycznej w aplikacji — można nawet wyrazić, że nazewnictwo w zasobach, które wybierzesz do reprezentowania tej warstwy (np. vmss-appName-business-layer).
Uwagi dodatkowe
Architektury n-warstwowe nie są ograniczone do trzech warstw. W przypadku bardziej złożonych aplikacji często mają więcej warstw. W takim przypadku należy rozważyć użycie routingu 7 warstwy w celu kierowania żądań trasy do określonej warstwy.
Warstwy są granicą skalowalności, niezawodności i zabezpieczeń. Należy rozważyć utworzenie oddzielnych warstw dla usług z różnymi wymaganiami w tych obszarach.
Użyj zestawów skalowania maszyn wirtualnych do skalowania automatycznego.
Poszukaj miejsc w architekturze, w których można użyć usługi zarządzanej bez znaczącej refaktoryzacji. W szczególności przyjrzyj się buforowaniu, obsłudze komunikatów, magazynowi i bazom danych.
W celu zapewnienia wyższego poziomu zabezpieczeń można umieścić strefę DMZ sieci przed aplikacją. Strefa DMZ obejmuje wirtualne urządzenia sieciowe (urządzenia WUS), które implementują funkcje zabezpieczeń, takie jak zapory i inspekcja pakietów. Aby uzyskać więcej informacji, zobacz architekturę referencyjną strefy DMZ sieci.
W celu zapewnienia wysokiej dostępności umieść co najmniej dwa urządzenia WUS w zestawie dostępności, z zewnętrznym modułem równoważenia obciążenia w celu rozkładania żądań internetowych między wystąpienia. Aby uzyskać więcej informacji, zobacz Wdrażanie wirtualnych urządzeń sieciowych o wysokiej dostępności.
Nie zezwalaj na bezpośredni dostęp przy użyciu protokołu RDP lub SSH do maszyn wirtualnych, na których działa kod aplikacji. Zamiast tego operatorzy powinni logować się do serwera przesiadkowego, nazywanego również hostem bastionu. Jest to maszyna wirtualna w sieci, której administratorzy używają do łączenia się z innymi maszynami wirtualnymi. Serwer przesiadkowy ma sieciową grupę zabezpieczeń, która zezwala na protokół RDP lub SSH tylko z zatwierdzonych publicznych adresów IP.
Sieć wirtualną platformy Azure można rozszerzyć na sieć lokalną za pomocą prywatnej sieci wirtualnej (VPN) typu lokacja-lokacja lub usługi Azure ExpressRoute. Aby uzyskać więcej informacji, zobacz architekturę referencyjną sieci hybrydowej.
Jeśli Twoja organizacja używa usługi Active Directory do zarządzania tożsamościami, możesz rozszerzyć środowisko usługi Active Directory do sieci wirtualnej platformy Azure. Aby uzyskać więcej informacji, zobacz architekturę referencyjną dotyczącą zarządzania tożsamościami.
Jeśli potrzebujesz wyższej dostępności niż zapewniana przez umowę SLA platformy Azure dla maszyn wirtualnych, zreplikuj aplikację w dwóch regionach i użyj usługi Azure Traffic Manager dla trybu failover. Aby uzyskać więcej informacji, zobacz Uruchamianie maszyn wirtualnych z systemem Windows w wielu regionach lub Uruchamianie maszyn wirtualnych z systemem Linux w wielu regionach.
Powiązane zasoby
- Aplikacja N-warstwowa z usługą Apache Cassandra
- [Aplikacja N-warstwowa systemu Windows na platformie Azure z programem SQL Server] [n-tier-windows-SQL]
- Moduł Microsoft Learn: przewodnik po stylu architektury N-warstwowej
- Azure Bastion
- Więcej informacji na temat obsługi komunikatów w stylu architektury N-warstwowej na platformie Azure