Системная архитектура и развёртывание

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

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

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

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

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

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

Трёхзвенная архитектура разделяет представление, логику приложения и хранение данных. Клиент отвечает за интерфейс, сервер приложения — за обработку и правила, сервер БД — за хранение. Такой вариант лучше поддерживает обновление, масштабирование серверной части и контроль доступа к данным.

Вопросы развёртывания

Развёртывание отвечает на практические вопросы:

какие артефакты поставляются на клиентские устройства;
какие артефакты развёрнуты на сервере приложения;
где находится СУБД или другое хранилище;
какие внешние сервисы участвуют;
какие среды выполнения нужны: браузер, JVM, Node.js, контейнер, веб-сервер, мобильная ОС;
какие каналы связи критичны.

На модели развёртывания важно различать уровни:

Элемент	Что означает	Пример
Компонент	логическая часть программной системы	модуль уведомлений, backend API
Артефакт	физическая единица поставки	jar-файл, контейнерный образ, frontend bundle
Узел	вычислительный ресурс или устройство	сервер, смартфон, рабочая станция
Среда выполнения	программная платформа внутри узла	браузер, JVM, Node.js, СУБД
Канал связи	путь взаимодействия между узлами	сеть между клиентом и сервером

Связь с требованиями

Решения о клиенте, размещении и средах выполнения обычно выводятся из нефункциональных требований. Производительность влияет на распределение нагрузки. Доступность — на резервирование и каналы связи. Безопасность — на размещение данных и границы доступа. Сопровождаемость — на простоту обновления клиентских и серверных частей. Совместимость — на выбор ОС, браузеров, runtime и СУБД.

Протоколы тоже нужно указывать осмысленно. HTTPS корректен между браузером и веб-сервером как прикладной протокол взаимодействия. Между приложением и PostgreSQL можно указать PostgreSQL protocol или TCP в зависимости от уровня детализации. Но HTTP/HTTPS как “физический протокол между компьютерами” будет некорректным уровнем описания.

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

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

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