Style architektury

  • Artykuł

Styl architektury to rodzina architektur, które mają określoną wspólną charakterystykę. Popularnym stylem architektury jest na przykład architektura N-warstwowa. Niedawno popularność zaczęła zyskiwać architektura mikrousług. Style architektury nie wymagają korzystania z konkretnych technologii, ale niektóre technologie są szczególnie odpowiednie dla określonych architektur. Na przykład kontenery są naturalnie dopasowane do mikrousług.

Zidentyfikowaliśmy zestaw stylów architektury, które są zwykle stosowane w aplikacjach w chmurze. Artykuł dotyczący każdego stylu obejmuje:

  • Opis i diagram logiczny stylu.
  • Zalecenia dotyczące wyboru danego stylu.
  • Korzyści, wyzwania i najlepsze rozwiązania.
  • Zalecane wdrożenie przy użyciu odpowiednich usług platformy Azure.

Krótki przewodnik po stylach

Ta sekcja zawiera krótki przewodnik po zidentyfikowanych stylach architektury oraz pewne ogólne informacje dotyczące ich używania. Więcej szczegółów znajduje się w powiązanych tematach.

N-warstwowa

Diagram logiczny stylu architektury N-warstwowej.

Architektura N-warstwowa to tradycyjna architektura aplikacji dla przedsiębiorstw. Zależności są zarządzane przez podzielenie aplikacji na warstwy, które wykonują funkcje logiczne, takie jak prezentacja, logika biznesowa i dostęp do danych. Warstwa może wywoływać tylko te warstwy, które znajdują się poniżej niej. Jednak to ułożenie warstw w poziomie może rodzić wyzwania. Może być trudno wprowadzić zmiany w jednej części aplikacji bez ingerowania w pozostałe części aplikacji. Sprawia to, że częste aktualizacje stają się wyzwaniem, ograniczając szybkość dodawania nowych funkcji.

Architektura N-warstwowa jest naturalnym wyborem w przypadku migrowania istniejących aplikacji, które już używają architektury warstwowej. Z tego powodu architektura N-warstwowa najczęściej występuje w rozwiązaniach typu infrastruktura jako usługa (IaaS) lub aplikacjach korzystających z kombinacji modelu IaaS i usług zarządzanych.

Sieć web-kolejka-proces roboczy

Diagram logiczny stylu architektury Web-Queue-Worker.

W przypadku czystego rozwiązania PaaS należy rozważyć wybór architektury Sieć web-kolejka-proces roboczy . W przypadku tego stylu aplikacja ma fronton sieci Web, który obsługuje żądania HTTP, oraz wewnętrzny proces roboczy, który wykonuje zadania intensywnie wykorzystujące procesor CPU lub długotrwałe operacje. Fronton komunikuje się z procesem roboczym za pośrednictwem kolejki komunikatów asynchronicznych.

Architektura Sieć web-kolejka-proces roboczy jest odpowiednia dla stosunkowo prostych domen z niektórymi zadaniami intensywnie korzystającymi z zasobów. Podobnie jak architektura N-warstwowa, jest łatwa do zrozumienia. Korzystanie z usług zarządzanych upraszcza wdrożenie i obsługę. Jednak w złożonych domenach zarządzanie zależnościami może być trudne. Fronton i proces roboczy mogą łatwo stać się dużymi, monolitycznymi składnikami, które jest trudno utrzymywać i aktualizować. Tak jak w przypadku architektury N-warstwowej, może to zmniejszyć częstotliwość aktualizacji i ograniczyć wprowadzanie innowacji.

Mikrousługi

Diagram logiczny stylu architektury mikrousług.

Jeśli aplikacja ma bardziej złożoną domenę, należy rozważyć przejście do architektury Mikrousługi . Aplikacja mikrousług składa się z wielu małych, niezależnych usług. Każda usługa implementuje jedną funkcję biznesową. Usługi są luźno powiązane, komunikując się za pomocą kontraktów interfejsów API.

Każda usługa może być tworzona przez mały, dedykowany zespół deweloperów. Poszczególne usługi mogą być wdrażane bez dużej koordynacji między tymi zespołami, co zachęca do częstych aktualizacji. Architektura mikrousług jest bardziej złożona, jeśli chodzi o kompilację i zarządzanie, porównując z architekturą N-warstwową i architekturą Sieć web-kolejka-proces roboczy. Wymaga dojrzałej kultury deweloperskiej i metodyki DevOps. Jeśli jednak ten styl jest wdrażany prawidłowo, może prowadzić do szybszego opracowywania wersji, wprowadzania innowacji i stworzenia bardziej odpornej architektury.

Architektura sterowana zdarzeniami

Diagram stylu architektury opartej na zdarzeniach.

Architektury sterowane zdarzeniami korzystają z modelu publikowanie-subskrypcja (pub-sub), w którym producenci publikują zdarzenia, a odbiorcy je subskrybują. Producenci są niezależni od odbiorców, a odbiorcy są niezależni od siebie nawzajem.

Architekturę sterowaną zdarzeniami należy rozważyć w przypadku aplikacji, które pozyskują i przetwarzają duże ilości danych z bardzo małymi opóźnieniami, takich jak rozwiązania IoT. Ten styl jest również przydatny, gdy różne podsystemy muszą wykonywać różne typy przetwarzania na tych samych danych zdarzeń.

Dane Big Data, Duże wystąpienia obliczeniowe

Diagram logiczny stylu architektury danych big data.

Architektury Dane Big Data i Duże wystąpienia obliczeniowe to wyspecjalizowane style architektury dla obciążeń odpowiadającym pewnym określonym profilom. Architektura Dane Big Data dzieli bardzo duże zestawy danych na fragmenty, wykonując przetwarzanie równoległe w obrębie całego zestawu na potrzeby analizy i raportowania. Architektura Duże wystąpienia obliczeniowe, nazywana również obliczeniami o wysokiej wydajności (HPC), wykonuje obliczenia równoległe w wielu rdzeniach (tysiącach rdzeni). Domeny zawierają symulacje, modelowanie i renderowanie 3D.

Style architektury jako ograniczenia

Styl architektury nakłada ograniczenia dotyczące projektu, w tym zestawu elementów, które mogą być wyświetlane, i dozwolonych relacji między tymi elementami. Ograniczenia określają „kształt” architektury, ograniczając środowisko wyborów. Gdy architektura spełnia ograniczenia konkretnego stylu, wyłaniają się określone pożądane właściwości.

Na przykład ograniczenia w architekturze mikrousług obejmują:

  • Usługa reprezentuje jeden obszar odpowiedzialności.
  • Każda usługa jest niezależna od innych.
  • Dane są prywatne dla usługi, która jest ich właścicielem. Usługi nie udostępniają danych.

Dzięki przestrzeganiu tych ograniczeń powstaje system, w którym usługi mogą być wdrażane niezależnie, błędy są izolowane, możliwe są częste aktualizacje i łatwo jest wprowadzać nowe technologie do aplikacji.

Przed wybraniem stylu architektury upewnij się, że rozumiesz podstawowe zasady i ograniczenia tego stylu. W przeciwnym razie możesz uzyskać projekt, który będzie pozornie zgodny ze stylem, ale nie osiągnie potencjału tego stylu. Ważne jest również pragmatyczne podejście. Czasami lepiej poluzować ograniczenia, niż nalegać na czystość architektury.

W poniższej tabeli pokazano, w jaki sposób poszczególne style zarządzają zależnościami, oraz typy domen, które najlepiej nadają się dla każdego z nich.

Styl architektury Zarządzanie zależnościami Typ domeny
N-warstwowa Warstwy poziome podzielone według podsieci Tradycyjna domena dla biznesu. Częstotliwość aktualizacji jest niska.
Web-queue-worker Zadania frontonu i zaplecza rozdzielone za pomocą asynchronicznej obsługi komunikatów. Stosunkowo prosta domena z pewnymi zadaniami intensywnie korzystającymi z zasobów.
Mikrousługi Pionowo (funkcjonalnie) rozdzielone usługi, które wywołują się nawzajem za pośrednictwem interfejsów API. Skomplikowane domeny. Częste aktualizacje.
Architektura sterowana zdarzeniami Producent/odbiorca. Niezależny widok dla podsystemu. Systemy IoT i czasu rzeczywistego.
Dane Big Data Dzielenie bardzo dużego zestawu danych na małe fragmenty. Równoległe przetwarzanie w lokalnych zestawach danych. Dane wsadowe i analiza danych w czasie rzeczywistym. Analiza predykcyjna z wykorzystaniem uczenia maszynowego.
Duże wystąpienia obliczeniowe Alokowanie danych do tysięcy rdzeni. Domeny intensywnie wykorzystujące zasoby obliczeniowe, takie jak symulacje.

Rozważanie wyzwań i korzyści

Ograniczenia mogą również stawać się wyzwaniaami, dlatego ważne jest, aby mieć na uwadze osiągnięcie kompromisu podczas wdrażania każdego z tych stylów. Warto zadać sobie pytanie, czy korzyści ze stylu architektury przeważają nad wyzwaniami dla danej domeny podrzędnej i kontekstu ograniczonego.

Poniżej przedstawiono niektóre rodzaje wyzwań, które należy wziąć pod uwagę podczas wybierania stylu architektury:

  • Złożoność. Czy złożoność architektury jest usprawiedliwiona w przypadku Twojej domeny? Z drugiej strony, czy styl nie jest zbyt uproszczony dla domeny? Wyzwaniem tutaj jest ryzyko powstania tzw. systemu „big ball of mud”, gdy architektura nie ułatwia prawidłowego zarządzania zależnościami.

  • Asynchroniczna obsługa komunikatów i spójność ostateczna. Asynchroniczna obsługa komunikatów może służyć do rozdzielania usług i zwiększenia niezawodności (ponieważ komunikaty mogą być ponawiane) oraz skalowalności. Jednak powoduje to też problemy z zapewnieniem ostatecznej spójności i może generować zduplikowane komunikaty.

  • Komunikacja między usługami. W przypadku rozdzielania aplikacji na osobne usługi istnieje ryzyko, że komunikacja między usługami będzie powodować niedopuszczalne opóźnienia lub przeciążenie sieci (na przykład w architekturze mikrousług).

  • Możliwości zarządzania. Jak ciężko jest zarządzać aplikacją, monitorowaniem, wdrażaniem aktualizacji itd.?