Тема 3. Типові архітектури розподіленого пз.
Архітектура Клієнт-сервер.
Моделі-варіації архітектури "клієнт-сервер".
Архітектура p2p (Peer to Peer)
Отже, як говорилося раніше, нині накопичений значний успішний досвід в розробці розподілених застосувань, який дозволяє говорити про наявність типової архітектури, деякі з яких будуть розглянуті в цій лекції.
Архітектура Клієнт-сервер
Перший тип – архітектура "клієнт-сервер" (мал. 3.1). Це нині найбільш поширена архітектура, в якій виконана, мабуть, більшість працюючих інформаційних систем. Існує навіть думка, що майже уся інша архітектура може бути представлена як велика або менша варіація цією, базовою.
У традиційному розумінні система, виконана в архітектурі "клієнт-сервер", є сукупністю взаємодіючих компонент двох типів – клієнтів і серверів. Звичайним також являється рознесення цих компонент по вузлах двох типів – відповідно до вузлів-клієнтів і вузлів-серверів. Клієнти звертаються до серверів із запитами, сервери їх обробляють і повертають результат. Клієнт, взагалі кажучи, може поводитися із запитами до декількох серверів. Сервери також можуть поводитися із запитами один до одного. Таким чином, типовий протокол для одного факту взаємодії може бути представлений у вигляді двох обмінів – запит на сервер і відповідь сервера.
Мал. 3.1. Архітектура "клієнт-сервер"
Клас додатків, виконаних в архітектурі "клієнт-сервер", що найчастіше зустрічається, – різні застосування, працюючі з базами даних. У такому разі сервером виступає СУБД, що забезпечує виконання запитів клієнта, який, у свою чергу, реалізує інтерфейс користувача.
Моделі-варіації архітектури "клієнт-сервер".
Розглянуті далі моделі систем, по суті, є варіаціями архітектури "клієнт-сервер".
Модель сервісу (один сервіс – багато серверів)
Модель сервісу (мал. 3.2) є реалізацією ситуації, при якій одну послугу реалізує не один, а декілька серверів, що представляються клієнтові як єдине ціле. Строго кажучи, запропонована модель є чистим клієнт-сервером, у якого сервер має складну структуру (не монолітний).
Мал. 2.2. Модель сервісу
Цей варіант особливо хороший для критичних сервісів, для яких недопустиме призупинення обслуговування. Оскільки сервіс реалізується відразу декількома серверами, зупинка одного з них не являється критической1). Для припинення обслуговування клієнтів потрібна зупинка усіх серверів системи. Крім того, така схема дозволяє реалізувати різні стратегії балансування навантаження між серверами системи.
Таким чином, може бути істотно збільшена як продуктивність системи, так і її стійкість до збоїв. Проте разом з плюсами у запропонованої моделі є і мінуси: найбільший – складніша реалізація в порівнянні з базовою архітектурою. Насправді, оскільки усі сервери забезпечують один і той же сервіс, виникають проблеми або з реплікацією оброблюваних даних (підтримка на усіх серверах системи актуальної копії даних), або з підтримкою цілісності розподілених даних.
Технологія підключення через proxy
Прикладом системи, побудованої в такій архітектурі, є звична система з браузеру, proxy-сервера і веб-сервера.
Відмінністю від раніше розглянутих моделей є те, що клієнт з'єднується не з сервером, а з деяким проміжним компонентом(мал. 3.3).
Мал. 3.3. Технологія підключення через proxy
Цей посередник, у свою чергу, від імені клієнта передає запит серверу. При цьому посередник може сам вирішувати, на який з серверів послати запит (можливі стратегії балансування навантаження). Крім того, він може підтримувати кеш останніх запитів, що задаються, і при черговому запиті користувача повернути йому відповідь, не звертаючись до серверу2).
Слід зазначити, що при неправильній побудові посередник може стати вузьким місцем усієї системи.
Як вже говорилося раніше, цей підхід особливо часто застосовують при роботі в Internet.
Сервер ініціює з'єднання
У класичній архітектурі "клієнт-сервер" ініціатором діалогу завжди виступає клієнт. Можна, проте, представити і іншу ситуацію – діалог ініціює сервер, "проштовхуючи" інформацію на клієнта. Роль клієнта у такому разі зводиться до реакції (перегляду) на повідомлення сервера. Типовим прикладом є робота "по підписці". Уявимо собі, що сервер отримує якісь події із зовнішнього джерела. Події мають тип. Клієнт, зацікавлений в отриманні події певного типу, повідомляє про свою зацікавленість сервер. Сервер, отримавши чергову подію, передає його усім зацікавленим в нім клієнтам. Приведений алгоритм є спрощеним описом роботи дуже часто використовуваної служби подій (подібна служба є практично в усіх сучасних middleware ).
Мобільні агенти
Ідея даної моделі (мал. 3.4) полягає в тому, що частенько, як це не парадоксально, клієнт сам в змозі виконати те завдання, рішення якого він запросив у сервера, більше того, дані, необхідні для вирішення цього завдання, розташовуються на клієнтові. У такому разі для розвантаження сервера (і дуже часто – для зниження мережевого трофіку) доцільно вирішувати цю задачу на клієнтові. Але як це зробити, якщо у клієнта немає відповідного програмного модуля, що містить необхідну функціональність? Відповідь така – цей модуль треба клієнтові відправити. Клієнт, отримавши модуль (цей модуль називається мобільним агентом), може виконати його локально, вирішивши таким чином завдання. В якості прикладу можна розглянути взаємодію браузеру і веб-сервера, що повертає сторінку, яка містить аплет.
Аплет також передається клієнтові і виконується у браузері (тобто на клієнтові), виконуючи якісь значимі для користувача дії. Основна проблема для такого підходу полягає в складності реалізації механізму передачі і виконання мобільних агентів, а також контролю безпеки. Проте, сучасні засоби middleware (Java, наприклад) такі можливості мають.
Тонкий клієнт
Впродовж декількох останніх років спостерігається постійне збільшення кількості вживаних портативних пристроїв – стільникових телефонів, PDA і так далі. Виникає природне бажання використовувати такі пристрої як засоби для роботи з інформаційними системами – чом би, наприклад, не зайти на wap -сайт туристичного агентства і не замовити путівку прямо із стільникового телефону? Оскільки у більшості сучасних телефонів вбудований wap-браузер, в цьому немає нічого неможливого.
Мал. 3.4. Мобільні агенти
Проте інтерфейс, що надається браузерами, дуже обмежений. З іншого боку, через обмежену потужність мобільних пристроїв в них доки не вдається розміщувати додатки із складною бізнес-логікою.
Мал. 3.5. Тонкий клієнт
Розв'язати цю проблему можна, використовуючи технологію "тонкого клієнта" (мал. 3.5). Суть цієї технології полягає в тому, що клієнт виконує дуже обмежене по функціоналу завдання (дуже часто – тільки прийом введення з клавіатури і інших пристроїв і обробка команд малювання). Схема роботи подібних систем в простому випадку наступна. Клієнтська програма передає усе введення користувача (натиснення клавіш, рух миші і так далі) по мережі серверу. Сервер розбирає і обробляє це введення і передає клієнтові готові екрани, які той просто отображает4). Цей принцип використовується в системах типу X – Windows вже дуже давно. Таким чином, сервер фактично бере на себе не лише завдання управління даними, але і взагалі усі завдання за логікою клієнтського інтерфейсу.