top of page
Oleg Tovma

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

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

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


Содержание


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

Прежде всего, начнем с базовой терминологии.


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


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


Архитектура важна, потому что от нее зависит, как система работает, насколько она стабильна, гибка, безопасна и готова к развитию в будущем.


С развитием ИТ сферы и продуктов формировались и подходы к построению архитектуры ПО.


Рассмотрим основные типы архитектуры ПО, которые сегодня активно используются.



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

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


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

Схема монолитной архитектуры


Плюсы:

  • Простота разработки, особенно в начале.

  • Легче тестировать и запускать программу, поскольку она представляет из себя единное целое.

  • Четкое представление обо всех взаимосвязях в программе.

Минусы:

  • С ростом системы код становится громоздким и трудным для поддержки.

  • Изменение одной части может повлиять на другие части, что может привести к ошибкам.

  • Сложно масштабировать отдельные функции системы.


Шаблон "Слои (Layers)"

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

  • Презентационный слой (интерфейс пользователя)

  • Логический слой (бизнес-логика)

  • Слой доступа к данным (работа с базой данных)


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

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


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

Схема микросервисной архитектуры

Плюсы:

  • Легче масштабировать отдельные части системы.

  • Можно обновлять или изменять один микросервис, не касаясь других.

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

Минусы:

  • Сложность в настройке взаимодействия между микросервисами.

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

  • Усложнено управление инфраструктурой, поскольку каждый микросервис нуждается в отдельных ресурсах.


Шаблон "Gateway/Facade" (Шлюз/Фасад)

В этом шаблоне единый шлюз (API Gateway) отвечает за взаимодействие между клиентом и набором микросервисов. Клиент не обращается к микросервисам напрямую, а использует шлюз, распределяющий запросы.


Шаблон "Database per Service" (Отдельная база данных для каждого сервиса)

Каждый микросервис имеет свою базу данных и отвечает за свой набор данных.



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

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

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

Схема клиент-серверной архитектуры

Плюсы:

  • Четкое разделение на две части: клиент для взаимодействия с пользователем, сервер для обработки данных.

  • Сервер можно легко обновлять и изменять, не затрагивая клиент.

Минусы:

  • Если сервер не работает, клиент не может работать.

  • Клиент и сервер должны постоянно взаимодействовать, что может создавать проблемы с производительностью или соединением.


Шаблон "Proxy" (Прокси-сервер)

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



Архитектура с использование серверов обработки событий(Event-driven architecture)

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

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

Плюсы:

  • Высокая производительность, поскольку сервисы реагируют на события, только когда они происходят.

  • Легко масштабировать и расширять, добавляя новые обработчики событий..

Минусы:

  • Труднее тестировать и отслеживать все события.

  • Если события обрабатываются неправильно, это может создать хаос в системе.Важче тестувати та відстежувати всі події.


Шаблон "Event Sourcing" (Источник событий)

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


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

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


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

Схема сервис-ориентированной архитектура (SOA)

Плюсы:

  • Гибкость в использовании разных технологий и языков программирования для разных сервисов.

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

Минусы:

  • Сложная интеграция и настройка коммуникаций между сервисами.

  • Труднее обеспечивать согласованность данных между разными сервисами.


Шаблон "Service Registry" (Реетр сервисов)

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


Различия между типами архитектуры программного обеспечения

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

  • Клиент-сервер имеет четкое разделение между тем, что видит пользователь (клиент), и работающим на заднем плане (backend, сервер). Микросервисная и SOA архитектура больше ориентирована на разделение сервисов, но SOA ориентируется на большие системы, тогда как микросервисы — на меньшие и независимые.

  • Архитектура обработки событий фокусируется на реакции на события, а не на постоянном обмене данными между частями системы, как это происходит в других архитектурах.


Для чего бизнес-аналитикам знать архитектурные шаблоны

Нам, как аналитикам, понимание архитектурных шаблонов позволяет получить следующие преимущества:

  1. Улучшение коммуникации с техническими командами.

  2. Принятие решений по функциональным и нефункциональным требованиям.

  3. Повышение качества анализа и прогнозирование влияния изменений.

  4. Оценка технической жизнеспособности бизнес-решений.

  5. Управление рисками и издержками.

  6. Содействие долгосрочному стратегическому планированию.

  7. Улучшение оценки времени и ресурсов для проектов.


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


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


А чтобы узнать подробнее о тонкостях архитектуры, шаблонов и получить другие технические знания – приходите знакомиться с нами на курс Технические навыки для бизнес-аналитиков.


433 просмотра0 комментариев

コメント


bottom of page