Файл: Распределенная технология обработки информации (Архитектурное построение систем распределенной обработки информации).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 04.04.2023

Просмотров: 207

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Концептуально распределенные системы строятся послойно и могут быть представлены в виде набора из трех частей:

1) Презентационный слой (уровень алгоритмов представления)

2) Слой прикладной логики (уровень бизнес-логики вычислительных и управляющих алгоритмов)

3) Слой управления ресурсами (уровень доступа к данным)

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

Рассмотрим каждый слой более подробно.

1.2.1 Презентационный слой

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

1.2.2 Слой прикладной логики

Любые системы программного обеспечения демонстрируют информацию, а также осуществляют обработку данных. Эта обработка производится программой, реализующей фактические операции, запрошенные клиентом посредством презентационного слоя. Такая программа называется программой слоя прикладной логики. Иногда такие программы называются службами, предлагаемыми распределенными системами.

В зависимости от сложности выполняемой логики этот слой может быть назван бизнес логикой, бизнес процессом, бизнес правилами или просто сервером.

1.2.3 Слой управления ресурсами

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

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


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

1.3 Архитектурное построение систем распределенной обработки информации

1.3.1 Одноярусные

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

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

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

Таким образом, значительный процент трафика SSL будет напрямую добавляться в магазины. Используя уровень доступа внутри интрасети, вы можете устранить эту проблему и, ограничив направления соединения, дополнительно защитить интрасеть от несанкционированного доступа.


1.3.2 Двухъярусные

Появились после возникновения персональных ЭВМ, на которых стало возможно не просто отображать информацию, но и обрабатывать ее. Роль сервера по-прежнему играла большая ЭВМ, но презентационный слой больше не требовалось объединять с другими слоями системы. У такого подхода есть два важных преимущества: использование вычислительных мощностей персональных ЭВМ (снятие нагрузки с других слоев), и использование одного презентационного слоя для разных целей, без усложнения системы.

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

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

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

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

Двухъярусные системы имеют много преимуществ по сравнению с одноярусными.

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

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


1.3.3 Трехъярусные

Трехъярусные системы сложнее и разнообразнее архитектуры клиент-сервер, все слои в них четко разделены. (Рис. 1.1)

Рис. 1.1 В трехъярусной архитектуре между презентационным слоем и слоем управления ресурсов представлен промежуточный слой системной поддержки.

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

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

Рис. 1.2 Интеграция систем различной архитектуры с использованием трехъярусного подхода.

Трехъярусные системы дополнили и развили концептуально важные понятия, выдвинутые двухъярусными системами. Несомненно, очевиден то факт, что управление ресурсами должно подчиняться четким интерфейсам, которыми должны пользоваться программы прикладной логики, находящиеся в промежуточном слое. Если двухъярусные архитектуры потребовали определения интерфейсов прикладного слоя, то трехъярусные привели к стандартизации интерфейсов слоя управления ресурсами.

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


Ограниченность модели трехъярусных систем проявилась при попытках интегрировать несколько трехъярусных систем, а также при выходе распределенных систем на уровень Интернета, что связано недостаточной стандартизацией этих систем.

1.3.4 Многоярусные

Этот вид архитектуры не сильно отличаются от трехъярусных: это обобщение трехъярусной модели с учетом важности доступа к данным через Интернет. Многоярусные архитектуры разрабатываются для двух основных применений: объединение разнородных систем и подключение к Интернету. Отдельные слои многоярусных систем сами представляют собой двух- либо трехъярусные системы.

Большинство современных систем построено по принципу многоярусности. Их создание потребовало больших усилий по интеграции других систем. В этом проявляется основной недостаток многоярусных систем – в них слишком много промежуточных слоев, часто с избыточной функциональностью, которые сложны, дороги в разработке, регулировке и поддержке. Хотя с введением в систему новых ярусов достигается повышение ее гибкости, растет функциональность, но одновременно возрастает стоимость взаимодействия между ярусами, возникают проблемы с производительностью системы.

Глава 2. Модели и технологии распределенной обработки информации

2.1 Модель RPC

Примером того, как абстракции системной поддержки могут оказаться полезными при разработке программ взаимодействия, служит понятие удаленного вызова процедуры (Remote Procedure Call, RPC). Пользуясь абстракцией RPC можно полностью отвлечься от необходимости беспокоиться о каналах связи, об ошибках, возникающих при передаче, о согласовании действий двух прикладных систем, работающих на разных ЭВМ, о разнице в форматах представления данных на разных ЭВМ. Все, что требуется при пользовании системной поддержкой RPC, это сформулировать запрос в виде обращения к процедуре с параметрами, которая скроет нижние уровни сетевого взаимодействия (Рис.2.1.).

Рис. 2.1 Удаленный вызов процедуры как программная абстракция, построенная на базе других коммуникационных слоев.