Понятие и виды архитектуры системы

Существует несколько основных типов архитектуры: многослойные, многоуровневые, сервис-ориентированные, микросервисные.

Определение архитектуры системы – это описание основных компонентов и модулей с принципами их работы и взаимосвязи друг с другом.

Операционное описание или Operation View, содержит в себе этапы применения системы оператором, сценарии и потоки работ:

• графический и числовой вид операций;
• организационную структуру схемы (organization charts);
• различные вариации использования (use cases) и сценарии;
• диаграммы потоков задач (task flow diagrams);
• диаграммы потоков информации (information flow diagrams).

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

• принципиальные схемы;
• функциональная декомпозиция (data flow chart);
• диаграммы IDEF0;
• схемы или диаграммы функциональных потоков (FFBD).

Физическое описание (Physical View) определяет видение системы с точки зрения экспертов по проектированию. Здесь определяется физическая граница системы и её компонентов, информационно-технологическая структура, взаимодействие модулей и их интерфейсов, структура данных и её внутренняя база, а также применяемые в разработке системы правил. Вот некоторые примеры физических описаний архитектуры системы:

• физические блок-схемы с подробной детализацией;
• классификация базы данных;
• контроль интерфейса документов и их управления (interface control document, ICD);
• стандарты.

Архитектура операционной системы должна логически связывать между собой все три вида описаний, которые на выходе образуют конечный продукт со всеми основными функциями. Существует термин «архитектурные требования». Он определяет запросы, имеющие максимальное влияние на проектирование архитектуры системы, и указывает на её неразрывную связь с требованиями.

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

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

Многослойная архитектура системы программ

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

Архитектура вычислительных систем разделяет ПО на следующие слои:

1. Слой представления (Presentation Layer). Это интерфейс пользователя, который несет ответственность за удовлетворение использования программы юзером.
2. Слой бизнес-логики (Business Logic Layer). Он разделяет UI/UX от вычислений, относящихся к бизнесу. Бизнес-требования постоянно меняются, а слой Business Logic Layer позволяет легко менять логику и подстраиваться под нововведения, никак не касаясь других слоев.
3. Слой передачи данных (Data Link Layer). Система постоянно коммуницирует с постоянными хранилищами и производит большое количество операций по обработке информации, не связанной с бизнесом. Именно за это взаимодействие и отвечает слой Data Link Layer.

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

Преимуществами многослойного построения архитектуры системы являются:

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

Вместе с тем, следует отметить и недостатки этого подхода:

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

Многоуровневая архитектура системы ПО

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

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

Работа двухуровневой системы строится на разделение работы физических машин сервера и пользователя. Такой подход обеспечивает обособленность операций по управлению данными, операций представления и обработки данных. Клиент включает в себя слои презентации, передачу данных и бизнес-логики. Сервер – базу данных и хранилище.

Трех и выше-уровневые системы наделены высоким уровнем масштабируемости как по вертикали, так и по горизонтали. Кроме того, n-уровневая система позволяет создать программу высокой производительности. Бюджет на создание такой системы будет гораздо выше. Высокая стоимость подразумевает использование метода в крупных программных разработках с комплексным решением (например, сложные ПО, требующие определенных параметров производительности и масштабируемости). В тандеме с современной сервис-ориентированной архитектурой это подход способен создавать самые сложные модели.

Сервис-ориентированная архитектура системы ПО (SOA)

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

Основы и элементы архитектуры системы такого типа:

• сервисы (Services);
• связующее программное обеспечение или сервисная шина (Service Bus);
• хранилище данных сервиса или сервисный репозиторий (ServiceRepository catalogue of services);
• безопасность набора архитектурных принципов –SOA (SOA Security);
• управление SOA (SOA Governance).

Существуют типы сервисов: организационные (Entity service), доменные (Domain Service), вспомогательные (Utility Service), интегрированные (Integrated Service), сервис безопасности (Security Service), сервис приложений (Application Service).

Mикросервисная архитектура

Микросервисная архитектура систем программирования основывается на разработке приложений как набора сервисов. Каждый из небольших сервисов обособлен в собственном процессе и связывается с несложными легковесными механизмами. Зачастую это API для HTTP-ресурса. Они имеют отдельный автоматизированный механизм и работают отдельно друг от друга.

Административное управление между сервисами сводится к минимуму. Они могут использовать разные технологии хранения данных и иметь отличные друг от друга языки написания.

Создание микросервисной архитектуры систем основывается на компонентизации сервисов, которая делит программное обеспечение на различные компоненты (сервисы), изолированные друг от друга. Каждый из таких сервисов несёт свою ответственность. Изменение одних компонентов не должны влиять на другие.

Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы) каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.

Микросервисы способны расширяться обособленно и не зависят друг от друга. Вот 5 основных компонентов такой архитектуры:

• сервисы (Services);
• сервисная шина (Service Bus);
• внешняя конфигурация (External configuration);
• шлюз API (API Gateway);
• контейнеры (Containers).

Основными преимуществами микросервисной архитектуры являются:

• Высокий уровень изоляции со слабой связанностью.
• Повышенная модульность.
• Изолированные системы предотвращают влияние сбоя в одном сервисе на другой.
• Гибкость и масштабируемость на высоком уровне.
• Ускоренные итерации, благодаря простой модификации.
• Улучшенная система обработки ошибок.
• В отличие от многослойной архитектуры, решает проблемы с потоками данных.

Заключение

Мы рассмотрели все виды архитектуры систем. Отражение взаимодействия бизнеса и ИТ является основной задачей при создании архитектуры. С одной стороны, это документирование и стандартизация бизнес-процессов. С другой – описание составляющих архитектуры веб-систем на логическом уровне с учетом связей с бизнес-процессами.