Клиенты, размещение и среды выполнения

TL;DR

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

Толстый и тонкий клиент

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

Трехслойная (трехзвенная) архитектура с тонким клиентом

Преимущества:

1. Простота обновления клиентского ПО, реже возникает необходимость в таких обновлениях.
2. Минимальные требования к аппаратному обеспечению АРМ с клиентским ПО.
3. Удобство в реализации кроссплатформенности клиентского ПО.
4. Проще контролировать доступ к данным.

Недостатки:

1. Высокие требования к производительности и надежности телекоммуникационной подсистемы. Невозможность пользоваться ИС в случае отказа канала доступа к серверу.
2. Высокие требования к производительности серверного оборудования, необходимость балансировки нагрузки.

Трехслойная (трехзвенная) архитектура с толстым клиентом

Преимущества:

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

Недостатки:

1. Повышенные требования к аппаратному обеспечению АРМ с клиентским ПО
2. Сложнее реализовывать кроссплатформенное клиентское ПО
3. Более дорогостоящее администрирование, частые обновления клиентского ПО с необходимостью доступа к АРМ

Размещение программных частей

Выбор толстого или тонкого клиента влияет на то, где размещаются программные части системы.

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

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

Для модели ИС важно явно понимать:

• какие артефакты поставляются на клиентские устройства;
• какие артефакты развёрнуты на сервере приложений;
• где размещается СУБД или другое хранилище;
• какие внешние сервисы участвуют во взаимодействии;
• какие каналы связи критичны для работы системы.

Среды выполнения

Среда выполнения - это программная платформа, внутри которой работает артефакт. Например, браузер, JVM, Node.js, контейнер приложений, веб-сервер, мобильная ОС или СУБД.

Один и тот же компонент логической архитектуры может быть реализован разными артефактами и размещён в разных средах выполнения. Например, компонент “клиентское приложение” может быть реализован как web frontend, desktop application или mobile app. Компонент “сервер приложения” может быть развёрнут как jar-файл, контейнерный образ или набор сервисов.

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

Связь с нефункциональными требованиями

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

• производительность влияет на распределение нагрузки;
• доступность влияет на резервирование и каналы связи;
• безопасность влияет на размещение данных и границы доступа;
• сопровождаемость влияет на простоту обновления клиентских и серверных частей;
• совместимость влияет на выбор ОС, браузеров, runtimes и СУБД.

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