Udostępnij za pośrednictwem

Style architektoniczne

Styl architektury to rodzina architektur, które mają pewne cechy. Na przykład N-warstwowy jest typowym stylem architektury. Ostatnio architektury mikrousług zaczęły zyskiwać na korzyść. Style architektury nie wymagają użycia określonych technologii, ale niektóre technologie są dobrze odpowiednie dla niektórych architektur. Na przykład kontenery są naturalnym rozwiązaniem dla mikrousług.

Zidentyfikowaliśmy zestaw stylów architektury, które są często spotykane w aplikacjach w chmurze. Artykuł dla każdego stylu obejmuje:

  • Opis i diagram logiczny stylu.
  • Zalecenia dotyczące tego, kiedy wybrać ten styl.
  • 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 wraz z niektórymi zagadnieniami wysokiego poziomu dotyczącymi ich użycia. Należy pamiętać, że lista nie jest wyczerpująca. Przeczytaj więcej szczegółów w połączonych tematach.

architektura N-warstwowa

Diagram logiczny stylu architektury N-warstwowej.

N-warstwowa to tradycyjna architektura dla 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 odwoływać się tylko do warstw, które znajdują się poniżej. Jednak ten poziomy układ może stanowić zagrożenie. Wprowadzenie zmian w jednej części aplikacji może być trudne bez dotykania reszty aplikacji. To sprawia, że częste aktualizacje stają się wyzwaniem, ograniczając szybkość dodawania nowych funkcji.

Architektura wielowarstwowa naturalnie pasuje do migrowania istniejących aplikacji, które już korzystają z architektury warstwowej. Z tego powodu architektura N-warstwowa jest najczęściej spotykana w rozwiązaniach typu infrastruktura jako usługa (IaaS) lub w aplikacjach korzystających z połączenia usług IaaS i usług zarządzanych.

Kolejka Pracownik sieci WWW

Logiczny diagram stylu architektury Web-Queue-Worker.

W przypadku rozwiązania PaaS należy wziąć pod uwagę architekturę Web-Queue-Worker . W tym stylu aplikacja ma interfejs webowy, który obsługuje żądania HTTP, oraz proces roboczy na zapleczu, który wykonuje zadania intensywnie korzystające z procesora lub długotrwałe operacje. Interfejs użytkownika komunikuje się z pracownikiem za pośrednictwem asynchronicznej kolejki wiadomości.

Web-queue-worker jest odpowiedni dla stosunkowo prostych domen z zadaniami, które zużywają dużo zasobów. Podobnie jak architektura N-warstwowa, jest łatwa do zrozumienia. Korzystanie z usług zarządzanych upraszcza wdrażanie i operacje. Jednak w przypadku złożonych domen zarządzanie zależnościami może być trudne. Interfejs i moduł roboczy mogą łatwo stać się dużymi, monolitycznymi składnikami, które trudno konserwować i aktualizować. Podobnie jak w przypadku warstwy N, może to zmniejszyć częstotliwość aktualizacji i ograniczyć innowacje.

Mikrousługi

Diagram logiczny stylu architektury mikrousług.

Jeśli aplikacja ma bardziej złożoną domenę, rozważ przejście do architektury mikrousług . 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 pośrednictwem kontraktów interfejsu API.

Każda usługa może zostać utworzona przez niewielki, skoncentrowany zespół programistyczny. Poszczególne usługi można wdrażać bez dużej koordynacji między zespołami, co zachęca do częstych aktualizacji. Architektura mikrousług jest bardziej skomplikowana do stworzenia i zarządzania niż architektura N-warstwowa lub web-queue-worker. Wymaga to dojrzałej kultury programowania i metodyki DevOps. Jednak ten styl może prowadzić do zwiększenia szybkości wydawania, szybszej innowacji i bardziej odpornej architektury.

Architektura sterowana zdarzeniami

Diagram przedstawiający styl architektury opartej na zdarzeniach.

Event-Driven Architectures używają modelu publish-subscribe (pub-sub), w którym producenci publikują zdarzenia, a konsumenci je subskrybują. Producenci są niezależni od konsumentów, a konsumenci są niezależni od siebie.

Rozważ architekturę opartą na zdarzeniach dla aplikacji, które pozyskiwają i przetwarzają dużą ilość danych z bardzo małymi opóźnieniami, takimi jak rozwiązania IoT. Styl jest również przydatny, gdy różne podsystemy muszą wykonywać różne typy przetwarzania na tych samych danych zdarzenia.

Big Data, Duże Sprzężenie Obliczeniowe

Diagram logiczny stylu architektury danych big data.

Big Data i Big Compute to wyspecjalizowane style architektury dla obciążeń, które pasują do konkretnych profili. Dane big data dzielą bardzo duży zestaw danych na fragmenty, wykonując przetwarzanie równoległe w całym zestawie na potrzeby analizy i raportowania. Wysokowydajne obliczenia, znane również jako przetwarzanie o wysokiej wydajności (HPC), wykonują równoległe obliczenia na dużej liczbie (tysiące) rdzeni. Domeny obejmują symulacje, modelowanie i renderowanie 3-W.

Style architektury jako ograniczenia

Styl architektury nakłada ograniczenia na projekt, w tym zestaw elementów, które mogą pojawić się i dozwolone relacje między tymi elementami. Ograniczenia kierują "kształtem" architektury, ograniczając wszechświat wyborów. Gdy architektura jest zgodna z ograniczeniami określonego stylu, pojawiają się pewne pożądane właściwości.

Na przykład ograniczenia w mikrousługach obejmują:

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

Stosując się do tych ograniczeń, pojawia się system, w którym usługi można wdrażać niezależnie, błędy są izolowane, częste aktualizacje są możliwe i łatwo wprowadzać nowe technologie do aplikacji.

Każdy styl architektury ma własne kompromisy. Dlatego przed wybraniem dowolnego stylu architektury upewnij się, że rozumiesz podstawowe zasady i ograniczenia tego stylu. W przeciwnym razie można skończyć z projektem, który jest zgodny z stylem na powierzchownym poziomie, ale nie osiąga pełnego potencjału tego stylu. Musisz zwrócić uwagę bardziej na to, dlaczego wybierasz określony styl architektoniczny niż do sposobu jej implementacji. Ważne jest również, aby być pragmatycznym. Czasami lepiej jest zrelaksować ograniczenie, a nie nalegać na czystość architektury.

Wybór odpowiedniego stylu architektury powinien być dokonany najlepiej w porozumieniu z poinformowanymi interesariuszami obciążenia. Zespół ds. obciążeń powinien najpierw zidentyfikować charakter problemu, który próbuje rozwiązać. Następnie należy zidentyfikować czynniki biznesowe i odpowiednie cechy architektury (znane również jako wymagania niefunkcjonalne), a następnie określić ich priorytety. Na przykład, jeśli potrzebują krótszego czasu wprowadzenia na rynek, mogą priorytetyzować łatwość utrzymania, testowalność i niezawodność poprzez możliwości szybkiego wdrażania. Lub jeśli zespół ds. obciążeń ma ograniczony budżet, może ustalić priorytety wykonalności i prostoty. Wybór i utrzymanie stylu architektury nie jest jednorazowym działaniem, ale ciągłym podejściem: architektura powinna być stale mierzona, weryfikowana i dostrojona w czasie. Zwykle wiąże się to ze znacznymi kosztami zmiany stylu architektury, więc większe nakłady pracy z góry mogą być uzasadnione w przypadku długoterminowej wydajności zespołu i ograniczania ryzyka.

Poniższa tabela zawiera podsumowanie sposobu zarządzania zależnościami w każdym stylu oraz typów domen, które najlepiej nadają się dla każdego z nich.

Styl architektury Zarządzanie zależnościami Typ domeny
architektura N-warstwowa Warstwy poziome podzielone według podsieci Tradycyjna domena biznesowa. Częstotliwość aktualizacji jest niska.
Pracownik kolejki sieciowej Zadania frontendowe i backendowe są oddzielane za pomocą komunikatów asynchronicznych. Stosunkowo prosta domena z niektórymi zadaniami intensywnie korzystającymi z zasobów.
Mikrousługi Usługi pionowo rozdzielone (funkcjonalnie), które komunikują się za pośrednictwem interfejsów API. Skomplikowana domena. Częste aktualizacje.
Architektura sterowana zdarzeniami Producent/konsument. Niezależny widok dla każdego podsystemu. Systemy IoT i czasu rzeczywistego.
Duże zbiory danych Podziel ogromny zestaw danych na małe fragmenty. Przetwarzanie równoległe w lokalnych zestawach danych. Analiza danych wsadowych i w czasie rzeczywistym. Analiza predykcyjna przy użyciu uczenia maszynowego.
Duże obliczenia Alokacja danych do tysięcy rdzeni. Domeny intensywnie korzystające z obliczeń, takie jak symulacja.

Rozważ wyzwania i korzyści

Ograniczenia tworzą również wyzwania, dlatego ważne jest, aby zrozumieć kompromisy podczas wdrażania któregokolwiek z tych stylów. Czy zalety stylu architektury przewyższają wyzwania dla tej poddomeny i ograniczonego kontekstu.

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

  • Złożoność. Czy złożoność architektury jest uzasadniona dla Twojej domeny? Z drugiej strony, czy styl jest zbyt uproszczony dla domeny? W takim przypadku ryzykujesz otrzymaniem "dużej kuli błota", ponieważ architektura nie pomaga w skutecznym zarządzaniu zależnościami.

  • Asynchroniczne komunikaty i spójność ostateczna. Asynchroniczne komunikaty mogą służyć do oddzielenia usług i zwiększenia niezawodności (ponieważ komunikaty mogą być ponawiane) i skalowalności. Jednak stwarza to również wyzwania związane z obsługą spójności ostatecznej, a także możliwość duplikowania komunikatów.

  • Komunikacja między usługami. W miarę rozkładania aplikacji na oddzielne usługi istnieje ryzyko, że komunikacja między usługami spowoduje niedopuszczalne opóźnienie lub przeciążenie sieci (na przykład w architekturze mikrousług).

  • Możliwość zarządzania. Jak trudno jest zarządzać aplikacją, monitorować, wdrażać aktualizacje itd.?