ћерион Ќетворкс

4 минуты

¬ этой статье мы расскажем про самые попул€рные и полезные паттерны архитектуры программного обеспечени€.


ћногоуровнева€ архитектура (n-уровнева€)

ћногоуровнева€ архитектура €вл€етс€ одной из самых распространенных. ≈е иде€ заключаетс€ в том, что компоненты с одинаковыми функци€ми организованы в горизонтальные слои, или уровни. ¬ результате чего каждый уровень выполн€ет определенную роль в приложении.

¬ таком варианте архитектуры нет ограничени€ на количество уровней, которое может иметь приложение. ѕри этом здесь также продвигаетс€ концепци€ разграничени€ полномочий. ћногоуровнева€ архитектура абстрагирует представление о программном обеспечении как о едином целом; предоставл€€ достаточно информации дл€ понимани€ ролей каждого уровн€ и взаимосв€зи между ними. —тандартной реализацией такой модели может быть:

  • ѕользовательский интерфейс/уровень представлени€: отображение и запуск пользовательского интерфейса, отправка запросов серверному приложению.
  • ”ровень приложений: содержит уровень представлени€, уровень приложени€, уровень предметной области и уровень хранени€ и управлени€ данными.
  • ”ровень предметной области: этот уровень содержит всю логику предметной области, сущности, событи€ и другие типы объектов, которые содержат логику предметной области.
  • ”ровень базы данных: это уровень данных, который используетс€ дл€ сохранени€ данных, которые будут использоватьс€ сервером приложений.
ћногоуровнева€ архитектура

ѕример: десктоп приложение, электронна€ коммерци€ или веб-приложени€ и т.д.


 лиент-сервер

Ёто наипростейша€ архитектура, состо€ща€ из сервера и нескольких клиентов. ќна представл€ет собой распределенную структуру, котора€ распредел€ет задачи или рабочую нагрузку между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.

ѕри такой архитектуре, когда клиент отправл€ет запрос данных на сервер, сервер принимает этот запрос и отвечает клиенту, предоставл€€ требуемые данные.  лиенты своими ресурсами не дел€тс€.

 лиент-сервер

ѕример: электронна€ почта, обмен документами, банковские операции и т.д.


Event-Bus (событийно-ориентированна€ архитектура)

Ёто распределенна€ асинхронна€ архитектура дл€ создани€ быстро масштабируемых реактивных приложений. “ака€ архитектура подходит дл€ стека приложений любого уровн€, от маленьких до сложных. ќсновна€ иде€ Ц асинхронна€ доставка и обработка событий.

Ёта модель состоит из четырех основных компонентов:

  • »сточник событи€
  • ѕолучатель событи€
  •  анал
  • Ўина событий

»сточник публикует сообщение в определенный канал на шине событий. ѕолучатель подписываетс€ на определенный канал и получает сообщени€, которые публикуютс€ на канале, на который они подписаны.

Event-Bus

ѕример: электронна€ коммерци€, разработка мобильных приложений, службы уведомлений и т.д.


Ўаблон брокера

Ётот шаблон можно использовать дл€ структурировани€ распределенных систем с несв€занными компонентами, взаимодействующими посредством удаленных вызовов служб.  омпонент брокер отвечает за координацию обмена данными между компонентами; таких как переадресаци€ запросов, а также передача результатов и исключений.

—ерверы публикуют свои возможности (услуги и характеристики) брокеру.  лиенты запрашивает услугу у брокера, и затем брокер перенаправл€ет клиента к подход€щей услуге из своего реестра.

Ўаблон брокера<

ѕример: ѕќ брокера сообщений, Apache ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging и т.д.


ћикросервисный шаблон

¬ данной модели службы взаимодействуют с использованием синхронных протоколов, таких как HTTP/REST, или асинхронных протоколов, таких как AMQP (Advanced Message Queuing Protocol - расширенный протокол организации очереди сообщений). —лужбы можно разрабатывать и разворачивать независимо, и кажда€ служба будет иметь собственную базу данных. —огласованность данных между службами поддерживаетс€ с помощью шаблона Saga (последовательность локальных транзакций).

ћикросервисный шаблон

ѕример: может быть реализован в различных вариантах использовани€, особенно в обширном конвейере данных


ќднорангова€ модель (Peer-to-Peer)

«десь, как и в обычной клиент-серверной архитектуре, несколько клиентов взаимодействуют с центральным сервером. Ќо модель одноранговой сети (–2–) состоит из децентралированной сети одноранговых узлов.

¬ этом шаблоне узлы ведут себ€ и как клиенты, и как серверы. ќдноранговые узлы могут функционировать как клиент, запрашивающий услуги у других одноранговых узлов, и как сервер, предоставл€ющий услуги другим одноранговым узлам.

—ети –2– распредел€ют рабочую нагрузку между одноранговыми узлами, и все они внос€т и потребл€ют ресурсы внутри сети без необходимости использовани€ централизованного сервера. ќдноранговый узел может динамически мен€ть свою роль с течением времени

ќднорангова€ модель

ѕример: файлообменные сети, мультимедийные протоколы PDTP, P2PTV, биткоин, блокчен и т.д.


Blackboard (доска объ€влений)

ƒанный паттерн полезен при решении задач, дл€ которых не известны детерминированные стратегии решени€.

¬се компоненты имеют доступ к Ђдоске объ€вленийї.  омпоненты могут создавать новые объекты данных, которые в последствие будут добавлены на эту доску.  омпоненты ищут определенные типы данных на доске и наход€т их по образцу, совпадающему с существующим источником знаний.

Ётот шаблон состоит из трех основных компонентов:

  • ƒоска объ€влений: структурированна€ глобальна€ пам€ть, котора€ содержит объекты из пространства решений.
  • »сточник знаний: специализированные модули с собственным представлением решени€
  •  омпонент управлени€: выбирает, настраивает и выполн€ет модули
Blackboard

ѕример: быстрое распознавание, идентификаци€ структуры белка, интерпретаци€ сигналов звуколокатора, программы машинного обучени€ и т.д.


—кидки 50% в Merion Academy

¬ыбрать курс