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

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

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

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

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

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

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

Многопользовательский режим работы с данными;
Возможность централизованного управления доступом к данным;
Низкая стоимость разработки;

Недостатки:

Низкая производительность;
Низкая надежность;
Слабые возможности масштабирования;

Двухзвенная архитектура

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

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

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

Полная поддержка многопользовательской работы;
Гарантия целостности данных;

Недостатки:

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

Трёхзвенная архитектура

Четкое разделение логики обработки данных от логики представления доступа к данным привели к появлению трехзвенной (трехслойной) клиент-серверной архитектуры.

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

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

Недостатки:

Выше расходы на администрирование и обслуживание серверной части.