Українська   English
ДонНТУ   Портал магистров

Реферат за темою випускної роботи

Зміст

Вступ

За твердженням відомого фахівця в галузі інформатики Е. Таненбаума, не існує загальноприйнятого і в той же час строгого визначення розподіленої системи. Деякі дотепники стверджують, що розподіленої є така обчислювальна система, в якій несправність комп'ютера, про існування якого користувачі раніше навіть не підозрювали, призводить до зупинки всієї їх роботи. Значна частина розподілених обчислювальних систем, на жаль, задовольняють таким визначенням, проте формально воно відноситься тільки до систем з унікальною точкою вразливості (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]

Стійкість. Під стійкістю розуміється можливість дублювання декількома комп'ютерами одних і тих самих функцій чи ж можливість автоматичного розподілу функцій усередині системи в разі виходу з ладу одного з комп'ютерів. В ідеальному випадку це означає повну відсутність унікальної точки збою, тобто вихід з ладу одного будь-якого комп'ютера не приводить до неможливості обслужити запит користувача.[12]

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

Ефективність. У вузькому сенсі стосовно до розподілених систем під ефективністю буде розумітися мінімізаціянакладних витрат, пов'язаних з розподіленим характером системи. Оскільки ефективність в даному вузькому сенсі може суперечити безпеки, відкритості та надійності системи, слід зазначити, що вимога ефективності в даному контексті є найменш пріоритетним. Наприклад, на підтримку логічної цілісності даних в розподіленої системі можуть витрачатися значні ресурси часу і пам'яті, проте система з недостовірними даними навряд чи потрібна користувачам. Бажаною властивістю проміжного середовища є можливість організації ефективного обміну даними, якщо взаємодіючі програмні компоненти знаходяться на одному комп'ютері. Ефективна проміжна середовище повинне мати можливість організації їх взаємодії без порушення стека TCP / IP. Для цього можуть використовуватися системні сокети (unix sockets) в POSIX системах або іменовані канали (named pipes).[13]

Стійкість розподіленої системи пов'язана з поняттям масштабованості, але не еквівалентна йому. Припустимо, система використовує набір обробних запити серверів і один диспетчер запитів, який розподіляє запити користувачів між серверами. Така система може вважатися досить добре масштабується, проте диспетчер є вразливою точкою такої системи. З іншого боку, система з єдиним сервером може бути стійка, якщо існує механізм його автоматичної заміни в разі виходу його з ладу, проте вона навряд чи відноситься до класу добре масштабованих систем. На практиці досить часто зустрічаються розподілені системи, що не відповідають даним вимогам: наприклад, будь-яка система з унікальним сервером БД, реалізованим у вигляді єдиного комп'ютера, має унікальну точку збою. Виконання вимог стійкості і масштабованості зазвичай пов'язане з деякими додатковими витратами, що на практиці може бути не завжди доцільно. Однак використовувані при побудові розподілених систем технології повинні допускати принципову можливість створення стійких і високо масштабованих систем.[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. Абстрагированием від певної СУБД. Підтримка PostgreSQL, MySQL, DB2, SQL Server, Oracle
  10. Спадкуванням класу від класу ActiveRecord :: Base, який в автоматичному режимі показує таблицю з ім'ям, яке відповідає імені класу, вами створеного
  11. Ставленням об'єктів, що підтримуються за допомогою макросів has_one, has_many, belongs_to

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

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

Зауваження

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

Висновки

На основі всього вищесказаного можна зробити висновок що тема розподілених систем вельми глибока і цікава. Так само дана тематика розкриває широкий простір для досліджень і розробок.

Список джерел

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