Системная архитектура и развёртывание
Если программная архитектура описывает внутреннюю организацию ПО, то системная архитектура показывает, где и в какой среде это ПО работает. Она связывает программные решения с инфраструктурой.
Классические варианты системной архитектуры помогают понять эволюцию размещения.
Файл-серверная архитектура предполагает, что данные находятся на файловом сервере, а большая часть обработки выполняется на клиентских рабочих местах. Основная проблема такого подхода — сложность обеспечения целостности данных и слабые возможности масштабирования. При нескольких пользователях либо возникают проблемы с блокировками, либо падает производительность.
Двухзвенная архитектура разделяет клиентское приложение и сервер данных. Клиент работает с логической схемой данных, а сервер управляет хранением. Это позволяет лучше поддерживать многопользовательскую работу и целостность данных. Но остаётся вопрос, где находится бизнес-логика: на клиенте или ближе к серверу.
Из этого вопроса появляются варианты толстого и тонкого клиента. В толстом клиенте значительная часть обработки находится на рабочем месте пользователя. Это может повысить автономность, но усложняет обновление и администрирование. В тонком клиенте основная логика находится на сервере, а клиент в основном отображает данные и принимает действия пользователя.
Трёхзвенная архитектура разделяет представление, логику приложения и хранение данных. Клиент отвечает за интерфейс, сервер приложения — за обработку и правила, сервер БД — за хранение. Такой вариант лучше поддерживает обновление, масштабирование серверной части и контроль доступа к данным.
Развёртывание отвечает на практические вопросы:
- какие артефакты поставляются на клиентские устройства;
- какие артефакты развёрнуты на сервере приложения;
- где находится СУБД или другое хранилище;
- какие внешние сервисы участвуют;
- какие среды выполнения нужны: браузер, JVM, Node.js, контейнер, веб-сервер, мобильная ОС;
- какие каналы связи критичны.
На модели развёртывания важно различать уровни:
| Элемент | Что означает | Пример |
|---|---|---|
| Компонент | логическая часть программной системы | модуль уведомлений, backend API |
| Артефакт | физическая единица поставки | jar-файл, контейнерный образ, frontend bundle |
| Узел | вычислительный ресурс или устройство | сервер, смартфон, рабочая станция |
| Среда выполнения | программная платформа внутри узла | браузер, JVM, Node.js, СУБД |
| Канал связи | путь взаимодействия между узлами | сеть между клиентом и сервером |
Решения о клиенте, размещении и средах выполнения обычно выводятся из нефункциональных требований. Производительность влияет на распределение нагрузки. Доступность — на резервирование и каналы связи. Безопасность — на размещение данных и границы доступа. Сопровождаемость — на простоту обновления клиентских и серверных частей. Совместимость — на выбор ОС, браузеров, runtime и СУБД.
Протоколы тоже нужно указывать осмысленно. HTTPS корректен между браузером и веб-сервером как прикладной протокол взаимодействия. Между приложением и PostgreSQL можно указать PostgreSQL protocol или TCP в зависимости от уровня детализации. Но HTTP/HTTPS как “физический протокол между компьютерами” будет некорректным уровнем описания.
При построении deployment-представления полезно идти от сценария. Где пользователь запускает клиент? Куда клиент обращается? Где выполняется бизнес-логика? Где хранятся данные? Какие внешние системы вызываются? Какие артефакты поставляются на каждый узел? Такой порядок снижает риск нарисовать инфраструктуру, которая не связана с поведением системы.