И. Соммервилл - Инженерия программного обеспечения (1133538), страница 58
Текст из файла (страница 58)
Проблемы проектирования распределенных систем Проблема проекти- Описание роваиия Ресурсы в распределенной системе располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимы с пи ресурсы и ссылаться на них. Примером может служить система унифицированного указателя ресурсов (ЛИ., которая определяет адреса%с)ьстраниц. Без легковоспринимаемой и универсальной системы идентификации большая часть ресурсов окажется недоступной пользователям системы Идентификация ре. сурсов 5. Оэломоуплайчкээпя Наличие нескольких компьютеров и возможность дублирования информации означает. что распределенные системы устойчивы к определенным аппаратным и программным ошибкам (см.
главу 18). Большинство распределенных систем в случае ошибки, как правило, мокнут поддерживать хотя бы частичную функциональность. Полный сбой в работе системы происходит только в случае сетевых ошибок. б. Пэозфачнэсжь Это свойство означает, что пользователям предоставлен полностью прозрачный доступ к ресурсам и в то же время от них скрыта информация о распределении ресурсов в системе. Однако во многих случаях конкретные знания об органиэации системы помогают пользователю лучше использовать ресурсы. Разумеется, распределенным системам присущ ряд недостатков.
° Сложнопл Распределенные системы сложнее централизованных. Намного труднее понять и оценить свойства распределенных систем в целом, а также тестировать эти системы. Например, здесь производительность системы зависит не от скорости работы одного процессора, а от полосы пропускания сети и скорости работы разных процессоров. Перемещая ресурсы из одной части систеиы в другую, можно радикально повлиять на производительность системы.
° Безоллпиюиь. Обычно доступ к системе можно получить с нескольких разных ма. шин, сообщения в сети мокнут просматриваться или перехватыватьсл. Поэтому, в распределенной системе намного сложнее поддерживать безопасность. ° Упрааллачосжь. Система может состоять из разнотипных компьютеров, на которых мокнут быть установлены разные версии операционных систем. Ошибки на одной машине могут распространиться на другие пашины с непредсказуемыми последствиями. Поэтому требуется значительно больше усилий, чтобы управлять и поддерживать систему в рабочем состоянии. ° Нелредпчиуакопль Как известно всем пользователям ЪЧеЬсети, реакция распреде.
ленных систем на определенные события непредсказуема и зависит от полной загрузки систеь~ы, ее организации и сетевой нагрузки. Так как все эти параметры ма. тут постоянно меняться, вреия, затраченное па выполнение запроса пользователя, в тот или иной момент может существенно различаться. При обсуждении преимуществ и недостатков распределенных систем в книге [81) определяется ряд критических проблем проектирования таких систем (табл. 11.1). В этой главе основное внимание уделяется архитектуре распределенного ПО, так как я полагаю, что при разработке программных продуктов наиболее значимым является именно этот момент.
Если вас интерес)ют другие темы, обратитесь к специализированным книгам цо распределенным системам. 228 Часть 1П. Проектирование Окончание табл. 11.1 Проблема проекти- Описание рования Универсальная работоспособность 1псегпсг и эффективная реали- зация протоколов ТСР/1Р в 1гпсгпсг для большинства распредс- ленных систем служат примером наиболсс эффсктивного способа организации взаимодействия между компьютерами.
Однако там, гдс на производительность, надежность и прочее накладываются специальные требования, можно воспользоваться альтернатив- ными способами системных коммуникаций Качество сервиса, прсдлагасмос систсмой, отражает сс произво. дительность, работоспособность и надежность. На качество сер- виса влияет целый ряд факторов: распределение системных про- цессов, распредсленис рссурсов, системныс и сетевые аппаратные средства и возможности адаптации системы Архитскгура программного обеспечения описывает распрсдслс- ние системных функций по компонентам системы, а также рас- пределение этих компонентов по процессорам.
Если необходимо поддсрживать высокое качество системного сервиса, выбор пра- вильной архитскгуры оказывается решающим фактором Коммуникации Качество системного сервиса Архитектура программного обсспсчсния Задача разработчиков распределенных систем — спроектировать программное или аппаратное обеспечение так. чтобы предоставить все необходимые характеристики распредслснной системы. А для этого требустся знать преимущества и недостатки различных ар.
хитсктур распределенных систем. Здесь выделястся два родственных типа архитектур распределенных систем. 1. Архимгкзгузп кгкекж/гглвгуз В этой модели систему можно представить как набор сервисов, прсдоставляемых серверами клиентам. В таких системак серверы и клиенты значитсльно отличаются друг от друга. 2. Лрхитекэгуугп Распуггделгинык обгекякм. В этом случае между серверами и клиентами нот различий и систему можно представить как набор взаимодействующих объектов, местоположение которых нс имеет особого значения.
Между поставщиком сервисов и их пользователями не существуст различий. В распределенной системе разные системные компоненты могут быть реализованы на разных языках программирования и выполняться на разных типах процессоров. Модели дапггых, нрсдставлснис информации и протоколы взаимодействия — все это нс обязательно будет однотипным в распрсделеиной системе. Следовательно, для распредслснных систсм необходимо такос программное обеспечение, которое могло бы управлять этими разнотипнымн частями и гарантировать взаимодействие и обмен данными между ними. ПРвкежутпчкпе ярогрпгсннпе обеспечашг о го осигся именно к такому классу ПО.
Оно находится как бы посерсднис между разными частями распределенных компонентов системы. В статье 1371 описаны различныс типы промежуточного ПО, которое может поддер живать рзспределснныс вычисления. Как правило. такое ПО составляется из готовых компонентов и нс требует от разработчиков специальных доработок.
В качестве примеров промежуточного ПО можно привести программы управления взаимодействием с базами данных, менеджеры транзакций, преобразователи данных, коммуникационные инспекторы и др. Далсе в главе будет описана структура распределенных систем как класс промеж1чечгюго ПО. 11. Архитектура расиредвлеииых систем 229 Распределенные системы обычно разрабатываются на основе объектно.ориентированного подхода.
Эти системы создаются иэ слабо интегрированных частей, каждал нэ которых может непосредственно взаимодейспювать как с пользователем, так и с другими часгямн системы. Этн части по возможности догокны реагировать на независимые события. Программные объекты. построенные на основе таких принципов, являются естественными компонентами распределенных систем.
Если вы еще не знакомы с концепцией объектов, рекомендую сначала прочитать главу 12, а затем вновь вернуться к данной главе. 11.1. Многопроцессорная архитектура Самой простой распределенной системой является многопроцессорнал сисгеиа. Она состоит иэ множества различных процессов, которые могут (но не обязательно) выполняться на разных процессорах. Данная модель часто используется в больших системах реального време. ни.
Как вы узнаете из главы 13, эти системы собирают информацию, принимают на ее основе решения и отправляют сигналы исполнительному механизму, который изменяет системное окружение. В принципе все процессы, связанные со сбором информации, принятием решений и управлением исполнительным механизмом, могут выполняться на одном процессоре под управлением планировщика заданий. Использование нескольких процессоров повышает про. изводительность системы и ее способность к восстановлению. Распределение процессов менду процессорами может переопрепеляться (присуще критическим системам) или жс находиться под управлением диспетчера процессов. На рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
