Архитектура информационной системы: компоненты, виды и их развитие

Архитектура информационной системы

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

Три компонента любой информационной системы

Каким бы сложным ни казался тот или иной продукт, в основе всякой информационной системы (ИС) лежат три составляющие:

• управление данными;
• бизнес-логика;
• пользовательский интерфейс.

Сами данные размещаются в базах данных, а распоряжается ими система управления базами данных (СУБД). Бизнес-логика задаёт правила, по которым сведения обрабатываются, и воплощается в наборе процедур, написанных на разных языках программирования. Наконец, интерфейс — это то, с чем непосредственно имеет дело пользователь: поля, кнопки, списки, таблицы и прочие элементы управления, за которыми скрывается вся логика работы системы.

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

Исторически сложились четыре основных вида архитектуры:

• локальная;
• файл-серверная;
• клиент-серверная;
• трёхуровневая (трёхслойная).

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

Локальные информационные системы были в ходу ещё до распространения компьютерных сетей. Здесь все три компонента — и данные, и бизнес-логика, и интерфейс — собраны на одном-единственном компьютере.

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

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

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

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

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

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

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

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

Централизованная обработка разгружает сеть и помогает поддерживать непротиворечивость данных. И всё же у клиент-серверной архитектуры остаётся уязвимое место. Языки хранимых процедур не рассчитаны на то, чтобы полноценно описывать бизнес-логику, поэтому её по-прежнему реализуют на стороне клиента. Такой компромисс влечёт за собой сразу несколько минусов:

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

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

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

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

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