И. Соммервилл - Инженерия программного обеспечения (1133538), страница 59
Текст из файла (страница 59)
11.1 поюзан пример системы такого'гила. Это упрощенная модель системы управ. лепна транспортным потоком. Группа распределенных датчиков собирает информацию о величине потока. Собранные данные перед отправкой в'диспетчерскую обрабатываются на месте. На основании полученной информации операторы принимают регнения и управляют светофорами. В этом примере для управления датчиками, диспетчерской и светофорами имеются отдельные логические процессы.
Это могут быть как отдельные процессы, так н группа процео сов. В нашем примере они выполняются на разных процессорах. Пгзнспц3тныы 60тОкОм Пульты влерэтарев Сюофоры Рис. 1 1.1. Много процессор ппл оненмлп упрплмния деижеггиеи трлн спорны Системы ПО, одновременно выполняющие множество процессов, нс обязательно являются распределенными. Если в систеие более одного процессора, реализовать распределение процессов ие представляет труда. Однако при создании многопроцессорных про. граммных систем не обязательно отталкиваться только от распределенных систем.
При проектировании систем такого типа, по существу, используется тот же подход, что и при проектировании систем реального времени, которые рассматриваются в главе 13, 230 Часть 1П. Проектирование 11.2. Архитектура клиент/сервер В главе 1О уже рассматривалась концепция клиент/сервер. В архитектуре клиент/сервер программное приложение моделируется как набор сервисов, предоставляемых серверами, и множество клиентов, использующих эти сервисы [264, 2з]. Клиенты должны знать о доступных (имеющихся) серверах, хотя могут и нс иметь представления о существовании других клиентов. Как видно из рис. 11.2, на котором представлена схема распределенной архитектуры клиент/сервер, клиенты и серверы представляют разные процессы.
Прсежп сервера Процесс швента Рис. 11.2, Системс «лисят/сервер В системе между процессами и процессЬрами не обязательно должно соблюдаться отношение "один к одному". На рис. 11З показана физическзл архитектура системы, которая состоит из шести клиентских машин и двух серверов. На них запускаются клиентские и серверные процессы, изображенные иа рис. 11.2. В общем случае, говоря о клиентах и серверах, я подразумеваю скорее логические процессы, чси физические машины, на которых выполняются эти процессы.
Архитектура систсиы клиент/сервер должна отражать логическую структуру разрабатываемого программного приложения. На рис. 11 4 предласается еще один взгляд на про. граммнос приложение, структурированное в виде трех уровней. Уровень представлении обеспечивает информацию для пользователей н взаимодействие с ними. Уровень выполнения прнложепия реализус"г логику работы приложенил. На уровне управления данными выполнлются все операции с базамн данных. В централизованных системах между этими уровнями нет четкого разделения.
Однако прн проектировании распределенных систем необходимо разлсллть эти уровни, чтобы затем расположить каждый уровень на разных компьютерах. Самой простой архитектурой клиент/сервер является двухуровневая, в которой приложение состоит из сервера (или множества идентичных серверов) и группы кзиентов. Сушсствуот два вида такой архитектуры (рис. 11.5). 1. А(о~)ель яюяхого клкслзю. В втой подели вся работа приложения и управление даннымн выполняются на сервере.
На клиентской машине запускается только ПО уровня представления. 11. Архитектура распределепньпс систем 231 2. Модель оимсмого клигивиь В этой модели сервер только управляет данными. На клиентской машине реализована работа приложения и взаимодействие с пользователем системы. Рис. 11З. Кои яаююгрм е сгжи клиент/сеРееР Рис.
11лб р юени программного прнеожеиил Тонкий клиент двухуровневой архитектуры — самый простой способ перевода сугцсствующих централизованных систем (см. главу 2б) в архитектуру клиент/сервер. Пользовательский интерфейс в этих системах "переселяется" на персональный компьютер, а само программное приложение выполняет функции сервера, т.е. выполняет все процессы приложения и управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты представляют собой обычныс сетевые устройства, а нс персональные компьютеры или рабочис станции. Сетевые устройства запускают 1пгегпсг.броузер и пользователь:- ский интерфейс, реализованный внутри системы. 232 Масть Ш.
Проектирование Рис. П.5. Модгли тканного и товстого илигнтов Главный недостаток модели тонкого клиента — большая загруженность сервера и сети. Все вычисления выполняются на сервере, а это может привести к значительному сетевому графику между клиентом н сервером. В современных компьютерах достаточно вычислителыюй мощности, но она практически не используется в модели тонкого клиента банка. Напротив, модель толстого клиента использует вычислительную мощность локальных иагяин: и уровень выполненил приложения, и уровень представления помещаются на клиентский компьютер.
Сервер здесь, по существу, является сервером транзакций, который управляет всеми транзакцилми баз данных. Примером архитектуры такого типа могут служить системы банкоматов, в которых банкомат является клиентом, а сервер — центральным компьютером, обслуживающим базу данных по расчетам с клиентами. На рис. 11.6 показана сстсваа система банкоматов. Заметим, что банкоматы связаны с базой данных расчетов не напрямую, а через монитор телеобработки. Этот монитор является промежуточным звеном, которое взаимодействует с удаленными клиентами и организует запросы клиентов в последовательность транзакций для работы с базой данных. Использование последовательных транзакций при возникновении сбоев позволяет системс восстановиться без потери данных. Рис. П.б.
Сионами кливнвг/свйввР длл свми бонкаиитов Поскольку в модели толстого клиента выполнение программного приложения организовано более эффективно, чем в модели тонкого клиента, управлять такой системой сложнее, Здесь функции приложения распределены между множеством разных машин. Необходимость замены приложения приводит к его повторной инсталляции па всех клиентских компьютерах, что требует болыяих расходов, если в систеие сотни клиентов. 11. Архитектура распределенных систем 233 Появление языка )ага н загружаемых аплстов позволили разрабатывать модели кли. ент/сервер, которые находятся гдето посередине между моделями тонкого и толстого клиента. Часть программ, составляющих приложение, можно загружать на клиентской машине как аплеты 1ача и тем самым разгрузить сервер.
Интерфейс пользователя строится посредством )теЬброузера, который запускает аплеты )ага. Однако Ъ'еЬ.броузеры от различных производителей и даже различные версии %ЧеЬброузеров от одного производителя не всегда выполняются одинаково. Более ранние версии броузеров на старых ма. шинах не всегда могут запустить эплеты) ага. Следовательно, такой подход можно использовать только тогда, когда вы уверены, что у всех пользователей системы установлены броузеры, совместимые с)ача. В двухуровневой модели клиент/сервер существенной проблемой является размещение на двух компьютерных системах трех логических уровней — представления, выполне.
ния приложения и управления данными. Поэтому в данной модели часто возникают либо проблемы с масштабируемостью и производительностью, если выбрана модель тонкого клиента, либо проблеиы, связанные с управлением системой, если используется модель толстого клиента. Чтобы избежать этих проблем, необходимо применить альтернативный подход — трехуровневую модель архитектуры клиент/сервер (рис. 11.7).
В этой архитектуре уровням представления, выполнения приложения и управления данными соответствуют отдельные процессы. 1Ъе. 1Б 7. ТРехуувввевая ярхилихтуРп клиент/еервеР Архитектура ПО, построенная по трехуровневой модели клиент/сервер, не требует, чтобы в сеть были объединены три компьютерных системы. На одном компьютере. сервере можно запустить и выполнение приложения, и управление данными как отделы ные логические серверы. В то же время, если требования к системе возрастут, можно будет относительно просто разделить выполнение приложения и управление данными и выполнять их на разных процессорах. Банковскую систему, использующую 1пгегпег сервисы, можно реализовать с помощью трехуровневой архитектуры клиент/сервер.
База данных расчетов (обычно расположенная на главном компьютере) предоставляет сервисы управления данными, ЪтеЬсервер Поддерживает сервисы приложения, например средства перевода денег, генерацию отчетов, оплату счетов и др. А компьютер пользователя с 1пгсгпеоброузером является клиентом. Кяк показано на рис. 11.8, эта система масштабируема, так как в нес относительно просто добавить новые 1(гсЬсерверы при увеличении количества клиентов, Использование трехуровневой архитслчуры в этом примере позволило оптимизировать передачу данных мсжду%еЬ-сервером и сервером бэлы данных.
Взаимодействие ме. жду этими системами не обязательно строить иа сгандартах 1псегпец можно использовать более быстрые коммуникационные протоколы низкого уровня. Обычно информацию от базы данных обрабатывает эффективное промежугочное ПО, которое поддерживает запросы к базе даннык на языке структурированных запросов ЯЯ В некоторых случаях трехуровневую модель клиент/сервер можно перевести в много. уровневую, добавив в систему дополнительные серверы. Многоуровневые системы можно использовать и там, где приложениям необходимо иметь доступ к информации, находлщейся в разных базах данных. В этом случае объединяющий сервер располагается между 234 Часть П1.