Требования к архитектурному построению систем распределённой обработки информации

Исторически первым вариантом архитектурного построения вычислительной системы была архитектура с централизованной обработкой информации, когда одна мощная универсальная ЭВМ являлась единственной платформой, выполняющей все слои логики приложения. Централизованная архитектура характеризуется рядом существенных достоинств: простота разработка приложений, легкость обслуживания и управления. Именно эти достоинства обеспечили широкое практическое применение и долгое существование вычислительных систем с централизованной обработкой информации [21].

Появление классов мини и микро-ЭВМ, а особенно класса персональных компьютеров (ПК) привело к разработке архитектур с децентрализованной обработкой информации, функционирующих в рамках парадигмы построения сетей, называемой моделью клиент/сервер (client/server model). Клиентами (client) в данном случае считаются вычислительные машины, нуждающиеся в получении тех или иных услуг, а серверами (server) — вычислительные машины, которые эти услуги предоставляют.

На уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. Так в рассмотренных выше архитектурных построениях при размещении процессов клиента и сервера на одной машине (обычно принято называть эту машину звеном, или ярусом — от англ. «tier») говорят об однозвенной реализации архитектуры клиент/сервер, а при размещении процессов клиента и сервера соответственно на двух разных машинах говорят о двухзвенной реализации такой архитектуры. Таким образом под общим концептуальным названием модели «клиент/сервер» скрывается несколько вариантов архитектурного построения вычислительных систем, а именно архитектуры однозвенные, двухзвенные, трехзвенные и т. д. (обычно при числе звеньев более трех архитектуру называют многозвенной) [24].

Однозвенная архитектура вырождается в классическую архитектуру с централизованной обработкой информации. В двухзвенной архитектуре приложение разделено на две части: клиентскую и серверную. Возможные варианты распределения слоев прикладного программного обеспечения в двухзвенной архитектуре представлены на Рисунке 1. Обычно сторона клиента содержит логику представления, а логика доступа к данным (как правило СУБД) и сама база данных находятся на стороне сервера. Алгоритмы бизнес-логики могут быть размещены либо полностью на стороне сервера (конфигурация так называемого «тонкого» клиента, Рисунок 1б), либо частично или полностью на машине клиента вместе с логикой представления (конфигурация так называемого «толстого» клиента, Рисунок 1 В, Рисунок 1г). В случае размещения на стороне клиента лишь части логики представления, минимально достаточной для функционирования клиента (что характерно для современных архитектур так называемых «терминальных», или «бездисковых», рабочих станций), конфигурация обычно носит наименование «сверхтонкого» клиента (Рисунок 1а)[25].

Рисунок 1 — Варианты построения схемы двухзвенной архитектуры клиент/сервер.

Стремление повысить гибкость и масштабируемость многопользовательской распределенной системы привело к архитектурным решениям с тремя и более звеньями. С середины 1990;х годов интенсивное практическое внедрение получила трехзвенная архитектура, которая, как и двухзвенная, поддерживает концепцию «клиент/сервер», но разделяет систему по функциональным границам между тремя слоями: логикой представления, бизнес-логикой и логикой доступа к данным (Рисунок 2). В трехзвенной архитектуре появилось дополнительное звено (так называемый «сервер приложений»), целиком предназначенное для реализации бизнес-логики. Трехзвенная архитектура позволила более явно отделить прикладную логику от пользовательского интерфейса и уровня баз данных. Так как в трехзвенной архитектуре под бизнес-логику обычно выделяется отдельная машина-сервер, то это повышает гибкость распределенной системы обработки информации (поскольку все три слоя отделены друг от друга, то становится возможным относительно легкое изменение либо перемещение любого из них без существенного влияния на остальные слои)[23].

Характерным примером использования трехзвенной архитектуры являются веб-приложения, которые реализуются посредством трех компонентов: веб-браузера клиента, веб-сервера и реляционной базы данных. Веб-браузер на машине-клиенте обычно отвечает за предоставление клиенту графического интерфейса, который облегчает доступ к удаленным документам. Браузер интерпретирует страницы, написанные с использованием языка HTML, и формирует их представление на мониторе клиента. Для извлечения удаленного документа браузер связывается с веб-сервером по протоколу HTTP, а затем сервер по тому же протоколу передает клиенту HTML-документ, найденный в базе данных. При этом уровень клиента, уровень сервера и уровень данных физически разнесены по разным машинам[27].

Именно выделение бизнес-логики в отдельное звено позволяет преодолеть фундаментальные ограничения двухзвенной архитектуры. Клиенты в этом случае не поддерживают постоянного соединения с базой данных, а обмениваются информацией со средним звеном только тогда, когда это необходимо. В то же время процесс среднего звена поддерживает всего несколько активных соединений с базой данных, но использует их многократно. Поэтому процессы в среднем звене могут предоставлять обслуживание теоретически неограниченному числу клиентов [22].

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

Рисунок 3 — Схема четырехзвенной архитектуры клиент/сервер.

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