Архітектурний шаблон - це узагальнене рішення поширеної проблеми в архітектурі програмного забезпечення в заданому контексті.
Шаблон - це вирішення завдання в певному контексті.
Часто розробники не до кінця розуміють різницю між архітектурними шаблонами, а іноді взагалі мало що про них знають.
Що ж, давайте розбиратися!
-
Багаторівнева архітектура
-
Канали і фільтри
-
Клієнт - сервер
-
Модель - представлення - контролер
-
Керована подіями архітектура
-
Архітектура на основі мікросервісів
Багаторівнева архітектура
Найпоширеніший архітектурний шаблон - багаторівнева архітектура (або «n-рівнева»). Вона добре відома більшості архітекторів, проєктувальників і розробників. Обмежень за кількістю і типом рівнів ніяких немає, проте в більшості випадків така архітектура складається з чотирьох рівнів: представлення даних, бізнес-логіка, зберігання даних і база даних.
Контекст
У будь-яких складних системах необхідно забезпечувати незалежну розробку і розвиток окремих частин. Тому розробникам системи треба зрозумілий і добре задокументований поділ завдань, щоб модулі системи можна було розробляти і підтримувати незалежним чином.
Завдання
Програмне забезпечення необхідно розділити так, щоб модулі можна було розробляти і розвивати окремо - з мінімальною взаємодією між частинами, забезпечуючи переносимість, модифікацію і повторне використання.
Рішення
Щоб домогтися такого поділу, при використанні багаторівневого шаблону, програмне забезпечення поділяється на сутності, звані рівнями. Кожен рівень - група модулів, що надають взаємопов'язаний набір сервісів. Їх застосування має бути односпрямованим. Рівні повністю поділяють ПО, причому кожна частина доступна через публічний інтерфейс.
-
Перша ідея полягає в тому, що у кожного з рівнів є певні роль і відповідальність. Наприклад, рівень представлення даних відповідає за обробку всього призначеного для користувача інтерфейсу. Такий поділ завдань в багаторівневій архітектурі спрощує формування ефективних ролей і відповідальності.
-
Друга ідея полягає в тому, що шаблон багаторівневої архітектури є технічне поділ - на відміну від поділу по доменах: тобто, це групи компонентів, а не домени.
-
І, нарешті, третя ідея: кожен рівень позначається як закритий або відкритий. Запит, переміщаючись з рівня на рівень і минаючи закритий рівень, повинен обов'язково пройти через нього - пропустити закритий рівень не можна.
Недоліки
Наявність рівнів знижує продуктивність. Цей шаблон не підходить для високопродуктивних застосунків: проходити кілька рівнів архітектури для виконання бізнес-запиту - це неефективно.
Крім того, додавання рівнів збільшує повну вартість і ускладнює систему.
Застосування
Використовувати цей підхід слід для невеликих, простих застосунків і веб-сайтів. Також цей шаблон добре підходить, якщо бюджет і час обмежені.
Багаторівневий шаблон
Контекст
При розподіленому розгортанні часто необхідно розділити інфраструктуру системи на окремі підмножини.
Завдання
Як розділити систему на ряд незалежних в обчислювальному відношенні виконавчих структур - груп програмного і апаратного забезпечення, об'єднаних яким-небудь засобом зв'язку?
Рішення
Виконавчі структури багатьох систем організовані як набір логічних груп компонентів. Кожна група називається ярусом.
Недоліки
Значні повна вартість і складність.
Застосування
Використовується в розподілених системах.
Канали і фільтри
Один з шаблонів які часто використовувуються в архітектурі ПО - шаблон каналів і фільтрів.
Контекст
Часто в системах необхідно перетворювати потоки дискретних елементів даних від введення до виводу. На практиці багато типів перетворень повторюються неодноразово, тому бажано зробити з них незалежні компоненти які можна повторно використовувати.
Завдання
Такі системи необхідно розділяти на повторно використовувані слабо пов'язані компоненти з простими узагальненими механізмами взаємодії - таким чином їх можна буде зручно поєднувати один з одним. Слабо пов'язані компоненти з узагальненою взаємодією легко використовувати повторно. А оскільки вони незалежні, їх виконання можна запускати паралельно.
Рішення
У цій архітектурі фільтри пов'язані між собою комунікаційними каналами. Перша ідея полягає в тому, що кожен з каналів з міркувань продуктивності має тип «точка - точка» і є односпрямованим: приймає вхідні дані від одного джерела і направляє вихідні дані в приймач.
У такому підході виділяють фільтри чотирьох видів:
-
генератор (
source
) - відправна точка процесу; -
перетворювач (
map
) - виконує перетворення деяких або всіх даних; -
випробувач (
reduce
) - перевіряє один або кілька критеріїв; -
споживач (
sink
) - кінцева точка.
Недоліки
Чи не найкращий вибір для інтерактивних систем, оскільки така архітектура орієнтована на перетворення даних.
Надмірне використання синтаксичного аналізу і синтезу знижує продуктивність і ускладнює написання самих фільтрів.
Застосування
Архітектура каналів і фільтрів застосовується в найрізноманітніших застосунках, особливо при вирішенні завдань, що забезпечують просту односторонню обробку - наприклад, інструменти EDI (електронний обмін даними), ETL (витяг, перетворення і завантаження).
Приклад - компілятори: послідовно розташовані фільтри виконують лексичний, синтаксичний, семантичний аналіз і створення коду.
Клієнт - сервер
Контекст
Є загальні ресурси та сервіси, до яких потрібно забезпечити доступ великої кількості розподілених клієнтів, і при цьому необхідно контролювати доступ або якість обслуговування.
Завдання
Керуючи набором загальних ресурсів і сервісів, можна забезпечити модифікацію і повторне використання, для чого загальні сервіси виносяться окремо, щоб їх можна було змінювати в одному місці або в невеликій кількості місць. Потрібно поліпшити масштабованість і доступність до використання за рахунок централізованого управління цими ресурсами і сервісами при одночасному розподілі самих ресурсів між декількома фізичними серверами.
Рішення
У підході «клієнт - сервер» компоненти і сполучні елементи мають певну поведінку.
-
Компоненти, звані «клієнтами», відправляють запити компоненту, званому «сервер», і чекають відповіді.
-
Компонент «сервер» отримує запит від клієнта і відправляє йому відповідь.
Недоліки
Сервер може бути вузьким місцем щодо продуктивності, а також єдиною точкою відмови.
Змінювати прийняте рішення про розміщення функціональних можливостей (на клієнті або на сервері) після створення системи - це зазвичай складно і дорого.
Застосування
Підхід «клієнт - сервер» можна застосовувати в моделюванні частини системи, що має багато компонентів, які відправляють запити (це «клієнти») іншого компонента (це «сервер»), який забезпечує роботу сервісів, - наприклад, онлайн-застосунки (електронна пошта, обмін документами і банківська справа).
Модель - представлення - контролер
Контекст
Зазвичай в інтерактивному застосунку частіше за інших змінюється призначений для користувача інтерфейс. Користувачам потрібно бачити дані в різному поданні - наприклад, як лінійчату або кругову діаграму, - і обидва подання повинні відображати поточний стан даних.
Завдання
Як можна відокремити функціональність призначеного для користувача інтерфейсу від функціональності програми і при цьому забезпечити швидкий відгук на дії користувача і зміни в базових даних програми?
Як створювати, підтримувати і координувати кілька подань призначеного для користувача інтерфейсу при зміні базових даних програми?
Рішення
Шаблон «модель - представлення - контролер» (MVC) розділяє функціональність програми на компоненти трьох видів:
-
Модель - містить дані програми.
-
Представлення - відображає деяку частину базових даних і взаємодіє з користувачем.
-
Контролер - діє як посередник між моделлю і представленням і управляє повідомленнями про зміну стану.
Недоліки
Для простих користувальницьких інтерфейсів така складність може бути надмірною.
Абстракції «модель», «уявлення» і «контролер» можуть не дуже добре підходити в разі деяких наборів інструментів для розробки користувальницького інтерфейсу.
Застосування
Архітектурний шаблон MVC зазвичай використовується в мобільних і веб-застосунках при розробці користувальницьких інтерфейсів.
Керована подіями архітектура
Контекст
Необхідно надати обчислювальні та інформаційні ресурси для обробки незалежних асинхронних подій, що формуються застосунком, з можливістю масштабування в міру потреби.
Завдання
Створити розподілені системи, які можуть обслуговувати асинхронні повідомлення, пов'язані з подією, і масштабироваться в широкому діапазоні величини і складності.
Рішення
Розгорнути незалежні процеси або обробники для роботи з подіями. Прибуваючі події ставляться в чергу. Планувальник витягує події з черги і передає їх до відповідного обробник подій згідно з політикою планування.
Недоліки
Можливі проблемні області - продуктивність і відновлення після помилок.
Застосування
Застосунок для електронної комерції який використовує цей підхід і може працювати наступним чином:
-
Сервіс «Замовлення» створює Замовлення в стані очікування і публікує подію «Створено Замовлення»
OrderCreated
. -
Сервіс «Покупці» отримує подію і намагається зарезервувати кредит для цього замовлення. Потім він публікує подію «Кредит зарезервовано»
CreditReserved
або «Перевищено Ліміт Кредиту»CreditLimitExceeded
. -
Сервіс «Замовлення» отримує цю подію від сервісу «Покупці» і змінює стан замовлення на «Затверджено» або «Скасовано».
Архітектура на основі мікросервісов
Контекст
Розгортання серверних корпоративних застосунків, що підтримують різні браузери і рідні мобільні клієнти. Застосунок обробляє клієнтські запити, реалізуючи бізнес-логіку, звертаючись до бази даних, обмінюючись повідомленнями з іншими системами і повертаючи відповіді. Застосунок може надавати API для реалізації третіми сторонами.
Завдання
При необхідності оптимального використання розподілених ресурсів (наприклад, в хмарних середовищах) монолітні застосунки можуть виявитися занадто великими і складними для ефективної підтримки та розгортання.
Рішення
Створення застосунків у вигляді наборів сервісів: кожен сервіс розгортається і масштабується незалежно і має власний «кордон», який обслуговується за допомогою API. Різні сервіси можуть писатися на різних мовах програмування, управляти власними базами даних і розроблятися різними командами.
Недоліки
Системи повинні бути спроєктовані так, щоб витримувати збої в роботі сервісів, а це вимагає ретельнішого моніторингу систем. Додаткові витрати ресурсів на організацію роботи сервісів і взаємодії подій.
Крім того, буде потрібно більше пам'яті.
Застосування
Архітектура мікросервісов застосовна в багатьох випадках, особливо коли використовується великий конвеєр даних. Наприклад, мікросервісна архітектура - відмінний вибір для системи звітності про продажі в роздрібних магазинах компанії. Кожен крок у процесі підготовки даних буде оброблятися мікросервісом: збір, очищення, нормалізація, збагачення, агрегація даних, звітність і т. д.
Не так все і складно, правда?
Джерело: levelup.gitconnected.com
Ще немає коментарів