Styl architektury n-warstwowej

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Architektura N-warstwowa dzieli aplikację na warstwy logiczne i warstwy fizyczne.

Diagram logiczny stylu architektury N-warstwowej

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. 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.
  • 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.
  • 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.

Najlepsze rozwiązania

Architektura n-warstwowa na maszynach wirtualnych

W tej sekcji opisano zalecaną architekturę n-warstwową działającą na maszynach wirtualnych.

Fizyczny diagram architektury N-warstwowej

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 i w tym przykładzie scenariusza wysokiej dostępności i odzyskiwania po awarii dla aplikacji IaaS.

  • 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.