Архитектуры и технологии реализации распределённых систем

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБР МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра Автоматизированных Систем Управления

Реферат

Архитектуры и технологии реализации распределённых систем

Выполнил студент группы АСМ-20

Ивашкин Тимофей Петрович

Принял к. т. н., доцент Астапчук Виктор Андреевич

Новосибирск 2021 г.

Введение

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

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

· Распределенная система может быть продемонстрирована клиент-серверной архитектурой, которая формирует основу для многоуровневых архитектур; альтернативами являются архитектура брокера, такая как CORBA, и сервис-ориентированная архитектура (SOA).

· Существует несколько технологических структур для поддержки распределенных архитектур, включая .NET, J2EE, CORBA, .NET Web-сервисы, AXIS Java Web-сервисы и сервисы GlobusGrid.

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

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

Преимущества

· Совместное использование ресурсов - совместное использование аппаратных и программных ресурсов.

· Открытость - Гибкость использования аппаратного и программного обеспечения разных производителей.

· Параллельная обработка - параллельная обработка для повышения производительности.

· Масштабируемость - увеличение пропускной способности за счет добавления новых ресурсов.

· Отказоустойчивость - способность продолжать работу после возникновения неисправности.

Недостатки

· Сложность - они более сложны, чем централизованные системы.

· Безопасность - более подвержена внешним атакам.

· Управляемость - для управления системой требуется больше усилий.

· Непредсказуемость - непредсказуемые ответы в зависимости от организации системы и загрузки сети.

Далее, стоит рассмотреть некоторые традиционные архитектуры распределённых систем: принцип их работы, преимущества и недостатки.

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

Изначально, существовали только локальные сети. Файлы передавались по этим сетям. Архитектура была одноранговой - все компьютеры равны. После, появилась идея хранения общедоступных файлов на выделенном компьютере - файл-сервере.

Рис. 1 - Модель файл-сервера.

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

Плюсы:

1. Многопользовательский режим работы с данными;

2. Удобство централизованного управления доступом;

3. Низкая стоимость разработки;

Минусы:

1. Низкая производительность;

2. Низкая надежность;

3. Слабые возможности расширения;

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

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

Архитектура клиент-сервер является наиболее распространенной архитектурой распределенной системы, которая разбивает систему на две основные подсистемы или логические процессы -

· Клиент - это первый процесс, который отправляет запрос второму процессу, то есть серверу.

· Сервер - это второй процесс, который получает запрос, выполняет его и отправляет ответ клиенту.

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



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

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

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

Основные особенности:

Клиентская программа работает с данными через запросы к серверному ПО.

Базовые функции приложения разделены между клиентом и сервером.

Плюсы:

Полная поддержка многопользовательской работы

Гарантия целостности данных

Минусы:

Бизнес логика приложений осталась в клиентском ПО. При любом изменении алгоритмов, надо обновлять пользовательское ПО на каждом клиенте.

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

Слабая защита данных от взлома, в особенности от недобросовестных пользователей системы.

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

Необходимость использовать мощные ПК на клиентских местах.

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

Рис. 3 - Модель сервера СУБД на клиент-серверной архитектуре.

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

Переходная к трёхслойной архитектуре

Использование хранимых процедур и вычисление данных на стороне сервера сокращают трафик, увеличивают безопасность. Клиент все равно реализует часть бизнес логики.

Как видно, такая организация системы весьма напоминает организацию первых унитарных систем с той лишь разницей, что на пользовательском месте стоит не терминал (с пресловутым зеленым экраном), а персональный компьютер, обеспечивающий ГИП, например, в последнее время в качестве клиентских программ часто применяют стандартные www-браузеры. Конечно, такой возврат к почти унитарным системам произошел уже на ином технологическом уровне. Обязательным стало использование СУБД со всеми их преимуществами. Программы для серверной части пишут, в основном, на специализированных языках, пользуясь механизмом хранимых процедур сервера БД. Таким образом, на уровне логической организации, ИС в архитектуре клиент-сервер с тонким клиентом расщепляется на три слоя - слой данных, слой бизнес-функций (хранимые процедуры) и слой представления. К сожалению, обычно, в такой схеме построения ИС не удается написать всю бизнес-логику приложения на не предназначенных для этого встроенных языках СУБД. Поэтому, очень часто часть бизнес функций реализуется в клиентской части систем, которая от этого неотвратимо "толстеет".

Отчасти поэтому, отчасти потому, что физически такие ИС состоят из двух компонентов, эту архитектуру часто называют 2.5-слойный клиент-сервер.

В отличие от 2-х слойной архитектуры 2.5-слойная архитектура обычно не требует наличия высокоскоростных каналов связи между клиентской и серверной частями системы, так как по сети передаются уже готовые результаты вычислений - почти все вычисления производятся на серверной стороне. Существенно улучшается также и защита информации - пользователям даются права на доступ к функциям системы, а не на доступ к ее данным и т.д. Однако вместе с преимуществами унитарного подхода архитектура 2.5 перенимает и все его недостатки, как-то: ограниченную масштабируемость, зависимость от программной платформы, ограниченное использование сетевых вычислительных ресурсов. Кроме того, программы для серверной части системы пишутся на встроенных в СУБД языках описания хранимых процедур, предназначенных для валидации данных и построения несложных отчетов, а вовсе не для написания ИС масштаба предприятия. Все это снижает быстродействие системы, повышает трудоемкость создания с модификации ИС и самым негативным образом сказывается на стоимости аппаратных средств, необходимых для ее функционирования.

Многоуровневая архитектура (n-уровневая архитектура)

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



Рис. 4 -Модель многоуровневой архитектуры РС.

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

Уровень представления

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

Уровень приложения (бизнес-логика, уровень логики или средний уровень)

Уровень приложения координирует ПО, обрабатывает команды, принимает логические решения, оценивает и выполняет вычисления. Он контролирует функциональность приложения, выполняя детальную обработку. Он также перемещает и обрабатывает данные между остальными слоями.

Уровень данных

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

Рис. 5 - Схема трёхуровневой архитектуры.

Преимущества

· Улучшает возможность повторного использования и масштабируемости - по мере увеличения требований могут быть добавлены дополнительные серверы.

· Обеспечивает многопоточную поддержку, а также уменьшает сетевой трафик.

· Обеспечивает ремонтопригодность и гибкость

Недостатки

· Неудовлетворительная тестируемость из-за отсутствия инструментов.

· Более высокая надежность и доступность сервера.

BAS

BrokerArchitecturalStyle - это архитектура промежуточного программного обеспечения, используемая в распределенных вычислениях для координации и обеспечения связи между зарегистрированными серверами и клиентами. Здесь обмен объектами происходит через систему промежуточного ПО, называемую посредником запросов объектов (программная шина).

· Клиент и сервер не взаимодействуют друг с другом напрямую. Клиент и сервер имеют прямое подключение к своему прокси, который взаимодействует с посредником-брокером.

· Сервер предоставляет сервисы, регистрируя и публикуя свои интерфейсы с брокером, и клиенты могут запрашивать сервисы у брокера статически или динамически при поиске.

· CORBA (Common Object RequestBrokerArchitecture) является хорошим примером реализации архитектуры брокера.

Компоненты BAS

Маклер

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

· Он отвечает за обработку запросов на обслуживание, поиск соответствующего сервера, передачу запросов и отправку ответов клиентам.

· Он сохраняет регистрационную информацию серверов, включая их функциональные возможности и услуги, а также информацию о местоположении.

· Он предоставляет API-интерфейсы для запросов клиентов, серверы для ответа, регистрации или отмены регистрации серверных компонентов, передачи сообщений и определения местоположения серверов.

Заглушки

Заглушки генерируются во время статической компиляции и затем развертываются на стороне клиента, после чего используются в качестве прокси для клиента. Клиентский прокси действует как посредник между клиентом и брокером и обеспечивает дополнительную прозрачность между ними и клиентом; удаленный объект выглядит как локальный.

Прокси скрывает IPC (межпроцессное взаимодействие) на уровне протокола и выполняет маршалинг значений параметров и демаршализацию результатов с сервера.

Скелет

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

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

Мост

Мост может соединять две разные сети на основе разных протоколов связи. Он является посредником различных брокеров, включая DCOM, .NET remote и Java CORBA.

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



Рис. 6 - Модель BAS.

Технологии реализации РС

DCOM

Distributed Component Object Model (DCOM) - программная архитектура, разработанная компанией Microsoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одной из машин может использовать DCOM для передачи сообщения (его называют удаленным вызовом процедуры) к компоненту на другой машине. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленного компонента.

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

Для решения этой задачи компания Microsoft создала распределенную компонентную объектную модель Distributed Component Object Model (DCOM), которая встраивается в операционные системы Windows NT 4.0 и Windows 98 и выше.

Можно перечислить следующие достоинства и недостатки DCOM:

Достоинства

1. Независимость от языка

2. Динамический/статический вызов

3. Динамическое нахождение объектов

4. Масштабируемость

5. Открытый стандарт (контроль со стороны TOG)

6. Множественность Windows-программистов

Недостатки

1. Сложность реализации

2. Зависимость от платформы

3. Нет именования через URL

4. Нет проверки безопасности на уровне выполнении ActiveX компонент

5. Отсутствие альтернативных разработчиков.

DCOM является лишь частным решением проблемы распределенных объектных систем. Он хорошо подходит для Microsoft-ориентированных сред. Как только в системе возникает необходимость работать с архитектурой, отличной от Windows, DCOM перестает быть оптимальным решением проблемы. Конечно, вскоре это положение может измениться, так как Microsoft стремится перенести DCOM и на другие платформы. Например, фирмой Software AG уже выпущена версия DCOM для Solaris UNIX и планируется выпуск версий и для других версий UNIX. Но все-таки, на сегодняшний день, DCOM хорош лишь в качестве решения для систем, ориентированных исключительно на продукты Microsoft. Большие нарекания вызывает также отсутствие безопасности при исполнении ActiveX компонент, что может привести к неприятным последствиям.

CORBA

В конце 1980-х и начале 1990-х годов многие ведущие фирмы-разработчики были заняты поиском технологий, которые принесли бы ощутимую пользу на все более изменчивом рынке компьютерных разработок. В качестве такой технологии была определена область распределенных компьютерных систем. Необходимо было разработать единообразную архитектуру, которая позволяла бы осуществлять повторное использование и интеграцию кода, что было особенно важно для разработчиков. Цена за повторное использование кода и интеграцию кода была высока, но никто из разработчиков в одиночку не мог воплотить в реальность мечту о широко используемом, языково-независимом стандарте, включающем в себя поддержку сложных многосвязных приложений. Поэтому в мае 1989 была сформирована OMG (Object Managment Group). Как уже отмечалось, сегодня OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft).

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

CORBA специфицирует инфраструктуру взаимодействия компонент (объектов) на представительском уровне и уровне приложений модели OSI. Она позволяет рассматривать все приложения в распределенной системе как объекты. Причем объекты могут одновременно играть роль и клиента, и сервера: роль клиента, если объект является инициатором вызова метода у другого объекта; роль сервера, если другой объект вызывает на нем какой-нибудь метод. Объекты-серверы обычно называют "реализацией объектов". Практика показывает, что большинство объектов одновременно исполняют роль и клиентов, и серверов, попеременно вызывая методы на других объектах и отвечая на вызове извне. Используя CORBA, тем самым, имеется возможность строить гораздо более гибкие системы, чем системы клиент-сервер, основанные на двухуровневой и трехуровневой архитектуре.

DynamicInvocationInterface (DII): позволяет клиенту находить сервера и вызывать их методы во время работы системы.

IDL Stubs: определяет, каким образом клиент производит вызов сервера.

ORB Interface: общие как для клиента, так и для сервера сервисы.

IDL Skeleton: обеспечивает статические интерфейсы для объектов определенного типа.

DynamicSkeletonInterface: общие интерфейсы для объектов, независимо от их типа, которые не были определены в IDL .

Skeleton Object Adapter: осуществляет коммуникационное взаимодействие между объектом и ORB.

Вот небольшой список достоинств использования технологии CORBA.

1. Платформенная независимость.

2. Языковая независимость.

3. Динамические вызовы.

4. Динамическое обнаружение объектов

EJB

Enterprise JavaBeans (также часто употребляется в виде аббревиатуры EJB) -- спецификация технологии написания и поддержки серверных компонентов, содержащих бизнес-логику. EJB является частью Java EE. Эта технология обычно применяется, когда бизнес-логика требует, как минимум, один из следующих сервисов, а часто все из них:

* поддержка сохранности данных (persistence); данные должны быть в сохранности даже после остановки программы, чаще всего достигается с помощью использования базы данных;

* поддержка распределённых транзакций;

* поддержка конкурентного изменения данных и многопоточность;

* поддержка событий;

* поддержка именования и каталогов (JNDI);

* безопасность и ограничение доступа к данным;

* поддержка автоматизированной установки на сервер приложений;

* удалённый доступ.

Каждая EJB компонента является набором Java классов со строго регламентированными правилами именования методов (верно для EJB 2.0, в EJB 3.0 за счет использования аннотаций выбор имен -- свободный). Бывают компоненты трех основных типов:

* объектные (EntityBean), перенесены в спецификацию Java Persistence API;

* сессионные (SessionBeans), которые бывают:

* без состояния (stateless);

* с поддержкой текущего состояния сессии (stateful);

* один объект на все приложение (singleton), начиная с версии 3.1; * управляемые сообщениями (MessageDrivenBeans) -- их логика является реакцией на события в системе.

Основная идея, лежавшая в разработке технологии Enterprise JavaBeans - создать такую инфраструктуру для компонент, чтобы они могли бы легко “вставляться” (plug in) и удаляться из серверов, тем самым увеличивая или снижая функциональность сервера.

Технология Enterprise JavaBeans похожа на технологию JavaBeans в том смысле, что она использует ту же самую идею (а именно, создание новой компоненты из уже существующих, готовых и настраиваемых компонент, аналогиично RAD-системам), но во всем остальном Enterprise JavaBeans - совершенно иная технология.

Принципиальные отличия от JavaBeans:

* Технология Enterprise JavaBeans описывается не спецификацией JavaBeans Component Specification, а совсем другим документом - Enterprise JavaBeans Specification.

* Если JavaBeans имеют дело лишь с клиентскими компонентами (как правило, это GUI-компоненты, или компоненты, с ними связанные), то EJB описывает каким образом внутри EJB-системы взаимодействуют между собой клиенты и серверы, как EJB-системы взаимодействуют с другими системами и какова роль различных компонент этой системы.

Источники

архитектура распределенная файл клиент сервер

1. CLAIM.Образование - вузовские учебные курсы[Электронный ресурс] / URL:http://it-claim.ru/Education/Course/ISDevelopment/Lecture_3.pdf, свободный. Дата обращения: 31.01.2021

2. It-brain - библиотека гайдов. Архитектура и дизайн программного обеспечения /URL: https://ru.it-brain.online/tutorial/software_architecture_design/distributed_architecture/, свободный. Дата обращения: 01.02.2021

3. Технологии программирования (часть 3) Доцент кафедры прикладной электродинамики и компьютерного моделирования, к.ф.-м.н. Губский Д.С. The PhysicsDepartment, SouthernFederalUniversity, Russia

Размещено на Allbest.ru

...