Разработка и исследование рспределенных систем

Введение

По утверждению известного специалиста в области информатики Э. Таненбаума, не существует общепринятого и в то же время строгого определения распределенной системы. Некоторые остряки утверждают, что распределенной является такая вычислительная система, в которой неисправность компьютера, о существовании которого пользователи ранее даже не подозревали, приводит к остановке всей их работы. Значительная часть распределенных вычислительных систем, к сожалению, удовлетворяют такому определению, однако формально оно относится только к системам с уникальной точкой уязвимости ( single point of failure ). [1]

Часто при определении распределенной системы во главу угла ставят разделение ее функций между несколькими компьютерами. При таком подходе распределенной является любая вычислительная система, где обработка данных разделена между двумя и более компьютерами. Основываясь на определении Э. Таненбаума, несколько более узко распределенную систему можно определить как набор соединенных каналами связи независимых компьютеров, которые с точки зрения пользователя некоторого программного обеспечения выглядят единым целым. [2]

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

1. Актуальность темы

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

2. Цель и задачи исследования, планируемые результаты

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

Основные задачи исследования:

1. Обзор существующих распределенных систем
2. Обзор возможностей реализации подобных систем на языке Ruby
3. Анализ архитектур распределенных систем
4. Разработка распределенной системы на языке Ruby

3. Распределенные системы

Распределённая система — система, для которой отношения местоположений элементов (или групп элементов) играют существенную роль с точки зрения функционирования системы, а, следовательно, и с точки зрения анализа и синтеза системы. [4]

3.1 Архитектура распредленных систем

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

Рис. 1.1. Модель взаимодействия клиент сервер

Взаимодействие в рамках модели клиент сервер может быть как синхронным, когда клиент ожидает завершения обработки своего запроса сервером, так и асинхронным, при котором клиент посылает серверу запрос и продолжает свое выполнение без ожидания ответа сервера. Модель клиента и сервера может использоваться как основа описания различных взаимодействий. Для данного курса важно взаимодействие составных частей программного обеспечения, образующего распределенную систему. [5]

Рис. 1.2. Логические уровни приложения

Рассмотрим некое типичное приложение, которое в соответствии с современными представлениями может быть разделено на следующие логические уровни (рис. 1.2): пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД), работающий с базой данных (БД). Пользователь системы взаимодействует с ней через интерфейс пользователя, база данных хранит данные, описывающие предметную область приложения, а уровень логики приложения реализует все алгоритмы, относящиеся к предметной области. [6]

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

Рис. 1.3. Двухзвенная архитектура

Архитектуру построенную по такому принципу приложений называют клиент серверной или двухзвенной. На практике подобные системы часто не относят к классу распределенных, но формально они могут считаться простейшими представителями распределенных систем. Развитием архитектуры клиент-сервер является трехзвенная архитектура, в которой интерфейс пользователя, логика приложения и доступ к данным выделены в самостоятельные составляющие системы, которые могут работать на независимых компьютерах (рис. 1.4). [1]

Рис. 1.4. Трехзвенная архитектура

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

Рис. 1.5. Распределенная система розничных продаж

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

Таким образом, в обиходе под распределенной системой часто подразумевают рост многозвенной архитектуры "в ширину", когда запросы пользователя не проходят последовательно от интерфейса пользователя до единственного сервера баз данных. В качестве другого примера распределенной системы можно привести сети прямого обмена данными между клиентами ( peer-to-peer networks ). Если предыдущий пример имел "древовидную" архитектуру, то сети прямого обмена организованы более сложным образом, рис. 1.6. Подобные системы являются в настоящий момент, вероятно, одними из крупнейших существующих распределенных систем, объединяющие миллионы компьютеров. [8]

Рис. 1.6. Система прямого обмена данными между клиентами

3.2 Требования к распределенным системам

Чтобы достигнуть цели своего существования – улучшения выполнения запросов пользователя – распределенная система должна удовлетворять некоторым необходимым требованиям. Можно сформулировать следующий набор требований, которым в наилучшем случае должна удовлетворять распределенная вычислительная система. [6]

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

Масштабируемость. Масштабируемость вычислительных систем имеет несколько аспектов. Наиболее важный из них – возможность добавления в распределенную систему новых компьютеров для увеличения производительности системы, что связано с понятием балансировки нагрузки ( load balancing ) на серверы системы. К масштабированию относятся так же вопросы эффективного распределения ресурсов сервера, обслуживающего запросы клиентов. [10]

Поддержание логической целостности данных. Запрос пользователя в распределенной системе должен либо корректно выполняться целиком, либо не выполняться вообще. Ситуация, когда часть компонент системы корректно обработали поступивший запрос, а часть – нет, является наихудшей. [11]

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

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

Эффективность. В узком смысле применительно к распределенным системам под эффективностью будет пониматься минимизация накладных расходов, связанных с распределенным характером системы. Поскольку эффективность в данном узком смысле может противоречить безопасности, открытости и надежности системы, следует отметить, что требование эффективности в данном контексте является наименее приоритетным. Например, на поддержку логической целостности данных в распределенной системе могут тратиться значительные ресурсы времени и памяти, однако система с недостоверными данными вряд ли нужна пользователям. Желательным свойством промежуточной среды является возможность организации эффективного обмена данными, если взаимодействующие программные компоненты находятся на одном компьютере. Эффективная промежуточная среда должна иметь возможность организации их взаимодействия без затрагивания стека TCP/IP. Для этого могут использоваться системные сокеты ( unix sockets ) в POSIX системах или именованные каналы ( named pipes ). [1]

Устойчивость распределенной системы связана с понятием масштабируемости, но не эквивалентна ему. Допустим, система использует набор обрабатывающих запросы серверов и один диспетчер запросов, который распределяет запросы пользователей между серверами. Такая система может считаться достаточно хорошо масштабируемой, однако диспетчер является уязвимой точкой такой системы. С другой стороны, система с единственным сервером может быть устойчива, если существует механизм его автоматической замены в случае выхода его из строя, однако она вряд ли относится к классу хорошо масштабируемых систем. На практике достаточно часто встречаются распределенные системы, не удовлетворяющие данным требованиям: например, любая система с уникальным сервером БД, реализованным в виде единственного компьютера, имеет уникальную точку сбоя. Выполнение требований устойчивости и масштабируемости обычно связано с некоторыми дополнительным расходами, что на практике может быть не всегда целесообразно. Однако используемые при построении распределенных систем технологии должны допускать принципиальную возможность создания устойчивых и высоко масштабируемых систем. [14]

Классическим примером системы, в значительной мере отвечающей всем представленным выше требованиям, является система преобразования символьных имен в сетевые IP-адреса (DNS). Система имен – организованная иерархически распределенная система, с дублированием всех функций между двумя и более серверами (рис. 1.7).

Рис. 1.7. Система DNS

Запрос пользователя на преобразование имени (например, w3c.org ) в сетевой адрес передается серверу распознавания имен поставщика услуг интернета. Сервер распознавания имен по очереди опрашивает серверы из иерархии службы имен. Опросначинается с корневых серверов, который возвращает адреса серверов, ответственных за зону домена. Затем опрашивается сервер, ответственный за зону (в данном случае – .org ), возвращающий адреса серверов, ответственных за домен второго уровня, и так далее. Серверы имен кешируют информацию о соответствии имен и адресов для уменьшения нагрузки на систему. Программное обеспечение на компьютере пользователя обычно имеет возможность соединиться с как минимум двумя различными серверами распознавания имен.

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

3.3 Промежуточная среда

С точки зрения одного из компьютеров распределенной системы, все другие входящие в нее машины являются удаленными вычислительными системами. Теоретической основой сетевого взаимодействия удаленных систем является общеизвестная модель взаимодействия открытых систем OSI/ISO, которая разделяет процесс взаимодействия двух сторон на семь уровней: физический, канальный, сетевой, транспортный, сеансовый, прикладной, представительский. [15]

Рис. 1.8. Модель взаимодействия вычислительных систем

В сетях наиболее распространенного стека протоколов TCP/IP протокол TCP является протоколом транспортного, а протокол IP – протоколом сетевого уровня. Обеспечение интерфейса к транспортному уровню в настоящее время берет на себя сетевая компонента операционной системы, предоставляя обычно основанный на сокетах интерфейс для верхних уровней. Сокеты обеспечивают примитивы низкого уровня для непосредственного обмена потоком байт между двумя процессами. Стандартного представительского или сеансового уровня в стеке протоколов TCP/IP нет, иногда к ним относят защищенные протоколы SSL/TLS. [16]

Использование протокола TCP/IP посредством сокетов предоставляет стандартный, межплатформенный, но низкоуровневый сервис для обмена данными между компонентами. Для выполнения сформулированных выше требований к распределенным системам функции сеансового и представительского уровня должна взять на себя некоторая промежуточная среда ( middleware ), называемая так же промежуточным программным обеспечением (рис. 1.9). Такая среда должна помочь создать разработчиками открытые, масштабируемые и устойчивые распределенные системы. Для достижения этой цели промежуточная среда должна обеспечить сервисы для взаимодействия компонент распределенной системы. К таким сервисам относятся:

1. обеспечение единого и независимого от операционной системы механизма использования одними программными компонентами сервисов других компонент;
2. обеспечение безопасности распределенной системы: аутентификация и авторизация всех пользователей сервисов компоненты и защита передаваемой между компонентами информации от искажения и чтения третьими сторонами;
3. обеспечение целостности данных: управление транзакциями, распределенными между удаленными компонентами системами;
4. балансировка нагрузки на серверы с программными компонентами;
5. обнаружение удаленных компонент. [17]

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

Рис. 1.9. Гетерогенная распределенная система

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

В настоящий момент нет универсально применимой промежуточной среды, хотя как будет показано в курсе, есть определенное движение в этом направлении. Основной причиной отсутствия такой среды являются отчасти противоречивые требования к распределенным системам, а также различающийся характер сетевых соединений между компонентами системы: например взаимодействие компонент внутри одного предприятия, вероятно, может быть построено иначе, чем взаимодействие компонент двух различных предприятий, не полностью доверяющих друг другу. [18]

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

4. ROR(Ruby on Rails)

RoR является бесплатным фреймворком, необходимым для разработки приложений, которые основаны на архитектуре MVC (Model-View-Controller) и базируются на Ruby. Главной целью считается упрощение разработки веб-приложений и их создание в малом количестве кода, нежели в иных фреймворках, с минимальной конфигурацией. Метапрограммирование Ruby как раз таки позволяет достичь всего этого.

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

Сам же фреймворк Ruby on Rails и его дополнительные расширения распространяются посредством такой системы, как Ruby Gems, которая стандартизирует каналы распространения и формат пакетов. Model Классы моделей Ruby on Rails основаны на Active Record библиотеках, реализующих объектно-реляционный вид данных, которые хранятся в базе. Active Record обладает:

1. Отражением ассоциаций, колонок, агрегаций
2. Наследственной иерархией
3. Автоотражением между таблицами и классами, колонками и атрибутами
4. Транзакционной поддержкой на уровне БД и на уровне представления объектов
5. Правилами валидации объектных полей
6. Способностью представлений записей в виде деревьев или списков
7. Агрегацией объектов
8. Способностью задать действия, которые производятся на разных этапах жизни объекта как в отдельном классе, так и в самой модели
9. Абстрагированием от определенной СУБД. Поддержка PostreSQL, MySQL, DB2, SQLServer, Oracle
10. Наследованием класса от класса ActiveRecord::Base, который в автоматическом режиме показывает таблицу с именем, которое соответствует имени класса, вами созданного
11. Отношением объектов, поддерживающихся при помощи макросов has_one, has_many, belong_to

View Для отображения интерфейса пользователя в Ruby on Rails существует класс, называющийся Action View, который реализует развитую систему шаблонов, так похожих на JavaScript, где языковые инструкции Ruby располагаются внутри таких тегов, как <%=%> или <%%>. Также здесь имеется функция render (отображение шаблона), использующаяся как внутри шаблона и служит для показа подшаблона, так и внутри контроллера. Controller

Взаимодействующие классы с пользователем в Ruby on Rails построены по принципу классов ActionController. Здесь определяются методы, доступные по URL через веб. Шаблон представления по умолчанию связан с каждым методом. В данном классе определяются разные вспомогательные методы, которые необходимы для управления аспектами, взаимодействующими с пользователем и генерации кода, зачастую использующегося. Например, при работе с БД для операций CRUD (Create-Remove-Update-Delete). [19-20]

5. Обзор исследований и разработок

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

5.1 Международные источники

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

Проектирование распределенных систем

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

Книга состоит из 160 страниц и содержит:

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

«Сейчас потребность в построении распределенных систем высока, а людей, которые умеют создавать их, не так много. Шаблоны для построения распределенных систем (особенно для систем управления контейнерами, таких как Kubernetes) будут полезны как начинающим, так и опытным разработчикам для быстрого создания и развертывания надежных распределенных систем.»— Брендан Бернс. [19]

Брендан Бернс — один из ведущих разработчиков корпорации Майкрософт, работает над проектом Azure и является соучредителем проекта Kubernetes.

5.2 Национальные источники

Так же тему распределенных систем не обошли и с нашей стороны к сожалению, а возможно и к счастью, в отличие от зарубежных авторов наши большее внимание уделяют реализации распределенных систем на аппаратной части. Одним из хороших примеров с которым интересно будет ознакомиться, является учебное пособие "ВВЕДЕНИЕ В РАСПРЕДЕЛЕННЫЕ ВЫЧИСЛЕНИЯ " автором данного пособия является Косяков М.С.

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

5.3 Локальные источники

В ДонНТУ весьма широко разрабатывалась и разрабатываеться тема распределенных систем, на портале магистров можно найти множество интереснейших работ по данной тематике, упомяну лишь некоторые из них:

1. Филенко М.С. Разработка механизма распределенного хранения и защиты информации
2. Стрюков С.А. Разработка моделей и программных средств для построения компьютерных информационных систем с распределенной архитектурой
3. Латорцев А.А. Разработка подсистемы моделирования распределенных компьютерных информационных систем
4. Афонов И.В. Исследование свойств распределённых систем хранения данных
5. Варич М.В. Разработка модели параллельной вычислительной системы для расчета параметров подвижного объекта
6. ...

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

Замечания

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

Выводы

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

1. Обзор существующих распределенных систем
2. Обзор возможностей реализации подобных систем на языке Ruby
3. Анализ архитектур распределенных систем

Дальнейшие исследования направлены на следующие аспекты:

1. Разработка распределенной системы на языке Ruby
2. Исследование библиотеки DRuby
3. Исследование фрейворка Rails
4. Анализ и исследование скорости работы распределенной системы с использованием различных "гемов"

Список источников

1. Чернопрудова Е, Щелоков С. Проектирование распределенных информационных систем: Курс лекций[Электронный ресурс] Режим доступа: Ссылка.
2. Митряев Э.И. Понятие распределенной информационной системы: Курс лекций[Электронный ресурс] Режим доступа: Ссылка.
3. Приходько С.А. Обзор распределенных систем.[Электронный ресурс] Режим доступа: Ссылка.
4. Распределённая система.Материал из Википедии – свободной энциклопедии [Электронный ресурс] Режим доступа:Ссылка.
5. Митряев Э.И. Модель Клиент-сервер: Курс лекций [Электронный ресурс] Режим доступа: Ссылка.
6. Горин С., Крищенко В. Поддержка разработки распределенных приложений в Microsoft .NET Framework: Лекции[Электронный ресурс] Режим доступа: Ссылка.
7. Горин С., Крищенко В. Поддержка разработки распределенных приложений: Учебный курс Москва, 2006. - 5c
8. Распределенные информационные системы: Конспект.[Электронный ресурс] Режим доступа: Ссылка.
9. Задачи и проблемы распределенной обработки данных[Электронный ресурс] Режим доступа: Ссылка.
10. Масштабируемость параллельных и распределенных систем[Электронный ресурс] Режим доступа: Ссылка.
11. Тамер Оззу М.,Валдуриз П. Распределенные и параллельные системы баз данных: Журнал Системы Управления Базами Данных # 4/1996, издательский дом «Открытые системы» [Электронный ресурс] Режим доступа: Ссылка.
12. Шнитман В.З.,Кузнецов С.Д. Аппаратно-программные платформы корпоративных информационных систем: Информационно-аналитические материалы Центра Информационных Технологий [Электронный ресурс] Режим доступа: Ссылка.
13. Косяков М.С. Введение в распределенные вычисления. – СПб: НИУ ИТМО, 2014. - 8c
14. Уфимский Государственный Авиационный Технический Университет. Общие сведения о tcp/ip: Лекции[Электронный ресурс] Режим доступа: Ссылка.
15. Митряев Э.И. Соответствие модели osi и других моделей сетевого взаимодействия:Лекции[Электронный ресурс] Режим доступа: Ссылка.
16. Ладыженский Г. Jet Infosystems системы[Электронный ресурс] Режим доступа: Ссылка.
17. ASP.NET Core MVC[Электронный ресурс] Режим доступа: Ссылка.
18. Ruby on Rails - Introduction[Электронный ресурс] Режим доступа: Ссылка.
19. Брендан Б. Проектирование распределенных систем[Электронный ресурс] Режим доступа: Ссылка.