Главная

Архитектура программного обеспечения

Объяснение общих шаблонов архитектуры

Поделиться:
 

4+

Архитектурный шаблон — это общее решение часто встречающейся проблемы в архитектуре программного обеспечения в заданном контексте. Паттерн — это решение проблемы в частном контексте. Сегодня многие программисты все еще не понимают разницы в шаблонах архитектуры, да и вообще мало чего знают о ней.
Давайте объясним…!

1. Многоуровневая архитектура (с англ. Layered Architecture)
2. Шаблон каналов и фильтров (с англ. Pipe and Filter)
3. Клиент-Сервер (с англ. Client Server)
4. Модель-Представление-Контроллер (с англ. Model View Controller)
5. Архитектура, управляемая событиями (с англ. Event Driven Architecture)
6. Архитектура микросервисов (с англ. Microservices Architecture)

Многоуровневая архитектура

Наиболее распространенный шаблон архитектуры — это многоуровневая архитектура, еще известная как n-уровневая архитектура. Этот шаблон должен быть знаком большинству архитекторов, дизайнеров и разработчиков программного обеспечения. Хотя нет никаких конкретных ограничений в отношении количества и типа слоев, которые должны существовать, большая часть архитектуры состоит из четырех основных уровней: Представление, Бизнес-логика, Постоянство и База данных.

Image for post

✐ Контекст

Все крупные и сложные системы нуждаются в независимой разработке и развитии отдельных частей системы. По этой причине разработчикам систем необходимо четкое и хорошо задокументированное разделение задач, чтобы можно было независимо разрабатывать и поддерживать модули системы.

✔ Решение

Чтобы добиться эффективного разделения задач, многоуровневый шаблон делит программное обеспечение на блоки, которые называют слоями или уровнями. Каждый уровень представляет собой группу модулей, которые исполняют один тип задач. Слои полностью разделяют программное обеспечение, и каждый раздел доступен через открытый интерфейс.

Первая концепция заключается в том, что каждый из уровней имеет определенную роль и ответственность. Например, уровень представления будет отвечать за обработку всего пользовательского интерфейса. Такое разделение задач в многоуровневой архитектуре значительно упрощает разработку.

Согласно второй концепции, шаблон многоуровневой архитектуры представляет собой технически разделенную архитектуру, в отличие от доменно-разделенной архитектуры. Это группы компонентов, а не домены.
Последняя концепция заключается в том, что каждый из уровней в многоуровневой архитектуре помечен как закрытый или открытый. Закрытый уровень предполагает, что запрос перемещается от уровня к уровню, он должен пройти через уровень прямо под ним, чтобы перейти на уровень ниже. Запрос не может проходить сквозь уровни.

Image for post

✖ Недостатки

Многоуровневая архитектура снижает производительность. Этот шаблон не подходит для приложений, требующих высокой производительности, ибо неэффективно проходить через несколько уровней архитектуры для выполнения какого-либо бизнес-запроса. Добавление уровней также увеличивает первоначальные затраты и усложняет систему.

Применение

Этот шаблон стоит использовать для небольших и простых приложений и сайтов. Это хороший выбор при ситуации с очень ограниченным бюджетом и временем.

Multi-Tier архитектура

✐ Контекст

При распределенном развертывании часто возникает необходимость разделить инфраструктуру системы на отдельные подмножества.

⚠ Проблема

Как можно разделить систему на ряд вычислительно независимых исполнительных структур: software и hardware?

✔ Решение

Image for post

Структуры исполнения многих систем организованы как набор логических групп компонентов. Каждая группа называется ярусом(tier с англ.).

✖ Недостатки

Значительные первоначальные затраты и сложность.

Применение

Используется в распределенных системах.

Шаблон каналов и фильтров (с англ. Pipe and Filter)

Один из архитектурных шаблонов, который используется повсеместно, — это шаблон каналов и фильтров.

Image for post

✐ Контекст

Многие системы должны перенаправлять потоки данных из ввода в вывод. Многие типы перенаправлений повторяются неоднократно, поэтому желательно создавать их как независимые, повторно используемые части.

⚠ Проблема

Такие системы необходимо разделять на повторно-используемые, слабо связанные компоненты с простыми общими механизмами взаимодействия. Таким образом, их можно гибко комбинировать друг с другом. Компоненты, будучи общими и слабо связанными, легко использовать повторно. Компоненты, будучи независимыми, могут выполняться параллельно.

✔ Решение

Pipe` ы в этой архитектуре образуют канал связи между фильтрами. Первая концепция заключается в том, что каждый из каналов является ненаправленным. Канал принимает входные данные от одного источника и всегда направляет выходные данные в другой.

Существует четыре типа фильтров:
● производитель (source): отправная точка процесса.
● преобразователь (map): выполняет преобразование некоторых или всех данных.
● tester (reduce): проверяет один или несколько критериев.
● потребитель (sink): конечная точка.

✖ Недостатки

Это не лучший выбор для интерактивных систем по причине их трансформирующего характера. Чрезмерный синтаксический анализ и разбор приводит к потере производительности и увеличению сложности написания самих фильтров.

Применение

Архитектура конвейерного фильтра используется в различных приложениях, особенно в тех, которые облегчают простую одностороннюю обработку, такие как инструменты EDIETL. Компиляторы: последовательные фильтры выполняют лексический анализ, синтаксический анализ, семантический анализ и генерацию кода.

Клиент серверная архитектура

Image for post

✐ Контекст

Существуют общие ресурсы и службы, к которым желают получить доступ большое количество клиентов. Доступ к этим службам/ресурсам должен быть качественным и быстрым.

⚠ Проблема

Управляя набором общих ресурсов и служб, мы можем обеспечить возможность модификации и повторного использования, выделив общие службы и изменив их в одном месте или в небольшом количестве мест. Мы хотим улучшить масштабируемость и доступность за счет централизации управления этими ресурсами и службами, одновременно распределяя ресурсы между несколькими физическими серверами.

✔ Решение

В архитектуре клиент-сервер компоненты и коннекторы имеют определенное поведение.
● Компоненты, называемые «клиентами», отправляют запросы компоненту, называемому «сервер», и ждут ответа.
● Серверный компонент получает запрос от клиента и отправляет ему ответ.

✖ Недостатки

Сервер может стать слабым местом производительности, а также быть единственной точкой отказа системы.
После создания системы, решения о том, где разместить функциональные возможности (на клиенте или на сервере), часто являются сложными и дорогостоящими.

Применение

Мы можем использовать архитектуру клиент-сервер для проектирования части системы, которая имеет множество компонентов, отправляющих запросы (клиентов) другому компоненту (серверу), который предлагает услуги: онлайн-приложения, такие как электронная почта, совместное использование документов и банковское дело.

MVP (Model View Controller)

✐ Контекст

Пользовательский интерфейс обычно является наиболее часто изменяемой частью интерактивного приложения. Пользователи часто хотят смотреть на данные различными способами, например с гистограммы или круговой диаграммы. Оба эти представления должны отражать текущее состояние данных.

⚠ Проблема

Как можно отделить функционал пользовательского интерфейса от функционала приложения и при этом реагировать на ввод данных пользователем или на изменения в базовом приложении?
Как можно создавать, поддерживать и координировать несколько представлений пользовательского интерфейса при изменении данных базового приложения?

✔ Решение

Шаблон Model View Controller (MVC) разделяет функционал приложения на три вида компонентов:
● Модель, содержащая данные приложения.
● Представление, которое отображает некоторую часть базовых данных и взаимодействует с пользователем.
● Контроллер, который является посредником между моделью и представлением и управляет уведомлениями об изменениях состояния.

✖ Недостатки

Для простых пользовательских интерфейсов сложность может не окупиться. Абстракции модели, представления и контроллера могут не подойти для некоторых видов пользовательского интерфейса.

Применение

MVC — это архитектурный шаблон, который обычно используется в веб и мобильных приложениях при разработке пользовательских интерфейсов.

Архитектура, управляемая событиями

✐ Контекст

Необходимо предоставить вычислительные и информационные ресурсы для обработки входящих независимых асинхронных событий, генерируемых приложением, таким образом, чтобы можно было масштабировать их по мере увеличения спроса.

⚠ Проблема

Создание распределенных систем, которые могут обслуживать асинхронные уведомления, связанные с событием, и которые могут масштабироваться от маленьких и простых до больших и сложных.

✔ Решение

Image for post

Разверните независимые процессы для обработки событий. Поступающие события ставятся в очередь. Планировщик извлекает события из очереди и распределяет их в соответствующий обработчик событий на основе алгоритма планирования.

✖ Недостатки

Производительность и восстановление после ошибок слабое место данной архитектуры.

Применение

Приложение электронной коммерции, использующее этот подход, будет работать следующим образом:
Служба заказов ставит заказ в состоянии ожидания и публикует событие OrderCreated.
● Служба поддержки клиентов получает событие и пытается зарезервировать кредит для этого заказа. Затем он публикует событие Credit Reserved или CreditLimitExceeded.
● Служба заказов получает событие от службы поддержки клиентов и меняет состояние заказа на одобренное или отмененное.

Архитектура микросервисов

✐ Контекст

Развёртывание серверных корпоративных приложений, которые поддерживаемые различными браузерами и собственными мобильными клиентами. Приложения обрабатывают клиентские запросы, выполняя бизнес-логику, обращаясь к базе данных, обмениваясь сообщениями с другими системам. Приложения могут предоставлять сторонний API.

⚠ Проблема

Монолитные приложения могут стать слишком большими и сложными для эффективной поддержки и развертывания для оптимального использования распределенных ресурсов, например в облачных средах.

✔ Решение

Image for post

Создавайте приложения как наборы служб. Каждая служба развертывается и масштабируется независимо и имеет собственное API. Различные сервисы могут быть написаны на разных языках программирования, управлять собственной базой данных и разрабатываться разными командами.

✖ Недостатки

Системы должны быть спроектированы так, чтобы терпеть отказы обслуживания, требующие более тщательного мониторинга системы. Также нужно больше памяти.

Применение

Для архитектуры микро сервисов применимы многие варианты использования, особенно те, которые включают обширный конвейер данных. Например, система на основе микро сервисов идеально подойдет для системы отчетности о продажах в розничных магазинах компании. Каждый этап в процессе подготовки данных будет обрабатываться микро сервисом: сбор данных, очистка, нормализация, обогащение, агрегирование, отчетность и т. Д.

Не так уж все и сложно, правда?
Спасибо, вот вам еще несколько полезных ссылок

4+