Що таке архітектура N-Tier?

Останнім часом я бачив досить багато посад для розробників, які містять речення, яке виглядає приблизно так: "Повинен мати досвід роботи з архітектурою N-Tier" або "Потрібно вміти розробляти додатки N-Tier".

Це змушує мене запитати, що таке архітектура N-Tier? Як можна отримати досвід з цим?

Вікіпедія :

В інженерії програмного забезпечення багаторівнева архітектура (її часто називають n-ярусною архітектурою) - це архітектура клієнт-сервер, в якій, презентація, обробка додатків та управління даними логічно є окремими процесами. Наприклад, програма, яка використовує проміжне програмне забезпечення для обслуговування запитів даних між користувачем та базою даних, використовує багаторівневу архітектуру. Найбільш поширене використання "багаторівневої архітектури" стосується трирівневої архітектури.

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

Редагувати : Одним із наслідків є те, що рівень презентації та логічний рівень (іноді його називають бізнес-логічним шаром) потребують перетину меж машини "через провід", іноді через ненадійну, повільну та / або небезпечну мережу. Це дуже відрізняється від простого настільного додатка, коли дані живуть на тій же машині, що і файли або веб-додаток, де ви можете безпосередньо потрапляти в базу даних.

Для програмування n-ярусів потрібно упакувати дані в якусь транспортабельну форму під назвою "набір даних" і перенести їх по дроту. Клас DataSet або протокол веб-служб .NET, наприклад SOAP, є мало таких спроб перелітати об'єкти по дроту.

Він заснований на тому, як ви відокремлюєте рівень презентації від основної логіки бізнесу та доступу до даних ( Вікіпедія )

• 3-рівень - презентаційний рівень + рівень компонента + рівень доступу до даних.
• N-рівень - це коли додаткові шари додаються понад ці, як правило, для додаткової модульності, настроюваності або сумісності з іншими системами.

Це модна мова, яка стосується таких речей, як звичайна веб-архітектура, наприклад, Javascript - ASP.Net - Middleware - шар баз даних. Кожна з цих речей є «ярусом».

N-ярусні додатки даних - це додатки даних, які розділені на кілька ярусів. Також називаються "розподіленими додатками" та "багаторівневими програмами", n-ярусні програми розділяють обробку на дискретні яруси, які розподіляються між клієнтом і сервером. Коли ви розробляєте додатки, які отримують доступ до даних, у вас має бути чіткий поділ між різними рівнями, що складають додаток.

Типова n-ярусна програма включає рівень презентації, середній рівень та рівень даних. Найпростіший спосіб розділити різні рівні в n-ярусному додатку - це створити дискретні проекти для кожного рівня, які ви хочете включити у свою заявку. Наприклад, рівень презентації може бути додатком Windows Forms, тоді як логіка доступу до даних може бути бібліотекою класів, розміщеною в середньому ярусі. Крім того, рівень презентації може спілкуватися з логікою доступу до даних у середньому рівні через службу, таку як служба. Розділення компонентів програми на окремі рівні підвищує ремонтопридатність та масштабованість програми. Це робиться шляхом спрощення прийняття нових технологій, які можна застосувати до одного рівня без необхідності переробляти все рішення. В додаток,

Взято з веб- сайту Microsoft .

Якщо я розумію питання, то мені здається, що запитуючий справді задає питання «Добре, тому 3-х рівневий добре зрозумілий, але, здається, існує сукупність ажіотажу, плутанини та невизначеності щодо того, що таке 4-рівень, чи узагальнюють, N-ярусні архітектури означають. Отже ... що таке визначення N-ярусу, яке широко розуміється і узгоджене? "

Це насправді досить глибоке питання, і щоб пояснити чому, мені потрібно зайти трохи глибше. Ведміть мене.

Класична трирівнева архітектура: база даних, "бізнес-логіка" та презентація - це хороший спосіб пояснити, як дотримуватися принципу розділення проблем. Тобто, якщо я хочу змінити те, як "бізнес" хоче обслуговувати клієнтів, мені не доведеться переглядати всю систему, щоб зрозуміти, як це зробити, і, зокрема, рішення питань бізнесу не повинні розкидатися. вольово-невольно через код.

Зараз ця модель добре служила десятиліттями, і це класична модель «клієнт-сервер». Швидкий перехід до хмарних пропозицій, коли веб-браузери - це інтерфейс користувача для широкого та фізично розподіленого набору користувачів, і зазвичай доводиться додавати служби розповсюдження контенту, які не є частиною класичної 3-ярусної архітектури (і якими потрібно керувати самостійно).

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

Тепер перегляньте інші описи прикладів архітектури N-ярусів з цією концепцією, і ви почнете розуміти проблему. Інші перспективи включають підходи, що базуються на постачальниках (наприклад, NGINX), збалансовані на вміст балансові навантаження, ізоляція даних та служби безпеки (наприклад, IBM Datapower), які можуть або не можуть додавати значення даній архітектурі, розгортанню та використанню випадків використання.

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

N-ярусні додатки даних - це додатки даних, які розділені на кілька ярусів. Також називаються "розподіленими додатками" та "багаторівневими програмами", n-ярусні програми розділяють обробку на дискретні яруси, які розподіляються між клієнтом і сервером. Коли ви розробляєте додатки, які отримують доступ до даних, у вас має бути чіткий поділ між різними рівнями, що складають додаток.

І так далі в http://msdn.microsoft.com/en-us/library/bb384398.aspx

При побудові звичайного MCV (трирівневої архітектури) можна вирішити реалізувати MCV двоярусною інтерфейсом, таким чином, що насправді можна замінити певний рівень, не змінюючи навіть одного рядка коду.

Ми часто бачимо переваги цього , наприклад, у сценаріях, коли ви хочете мати можливість використовувати більше однієї бази даних (у такому випадку у вас є подвійний інтерфейс між рівнями управління та рівнями даних).

Коли ви розмістите його на шарі View (презентація), тоді ви можете (утримуйте !!) замінити інтерфейс USER іншою машиною, тим самим автоматизуючи РЕАЛЬНІ введення (!!!) - і ви зможете тим самим запустити виснажливі тести на зручність використання тисяч раз, без того, щоб жоден користувач потребував натискання та повторного натискання та повторного натискання одних і тих же речей знову і знову.

Деякі описують таку трирівневу архітектуру з 1 або 2 подвійними інтерфейсами як 4-х рівневу або 5-рівневу архітектуру, неявно маючи на увазі подвійні інтерфейси.

Інші випадки включають (але не обмежуються ними) той факт, що ви - у випадку напівповністю або повністю відтворених систем баз даних практично зможете вважати одну з баз даних "головним", і, таким чином, ви мали б рівень що складається з ведучого та іншого, що містить підлеглу базу даних.

Приклад для мобільних пристроїв

Отже, багаторівневий - або N-рівень - дійсно має декілька інтерпретацій, тоді як я, безумовно, дотримуватимуться 3-х рівневих + додаткових ярусів, що складаються з тонких інтерфейсних дисків, закріплених між собою, щоб увімкнути зазначені підміни ярусів, і з точки зору тестуючи (особливо використовується на мобільних пристроях), тепер ви можете запускати тести користувачів на реальному програмному забезпеченні, імітуючи користувачі, що прослуховують способами, за допомогою яких логіка управління не може відрізняти від реального користування. Це майже головне значення для імітації реальних тестів користувачів , оскільки ви можете записувати всі входи від користувачів OTA, а потім повторно використовувати той самий вхід під час регресійних тестів.

Коли ми говоримо про рівні ярусів, ми загалом говоримо про фізичні процеси (що мають різний простір пам'яті).

Таким чином, у випадку, якщо шари програми будуть розгорнуті в різних процесах, ці різні процеси будуть різними рівнями.

Наприклад, у трирівневій програмі діловий рівень спілкується з Mainframes (окремим процесом) та спілкується зі службою звітування (окремий процес), тоді ця програма буде 5-ти рівневою.

Отже, родова назва n-ярусна.

з https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

N-ярусна архітектура в основному розділяє шини програми на логічні шини та фізичні рівні, а їх поділяють на підрозділи.

Шари - це спосіб розділити обов'язки та управляти залежностями. Кожен шар несе певну відповідальність. Вищий рівень може використовувати сервіси на нижньому, але не навпаки.

Яруси фізично розділені, працюють на окремих машинах. Рівень може безпосередньо дзвонити на інший рівень або використовувати асинхронні повідомлення (черга повідомлень). Хоча кожен шар може розміщуватися у власному ярусі, цього не потрібно. На одному ярусі може розміщуватися кілька шарів. Фізичне розділення ярусів покращує масштабованість та стійкість, але також додає затримки від додаткової мережевої комунікації.

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

Додаток N-рівня може мати архітектуру закритого шару або архітектуру відкритого шару:

In a closed layer architecture, a layer can only call the next layer immediately down.
In an open layer architecture, a layer can call any of the layers below it.

Закрита архітектура шарів обмежує залежності між шарами. Однак це може створити непотрібний мережевий трафік, якщо один шар просто передає запити наступному шару.

N-ярусна програма - це програма, в якій задіяно більше трьох компонентів. Що це за компоненти?

• Кеш
• Черги на повідомлення для асинхронної поведінки
• Навантаження балансирів
• Пошукові сервери для пошуку за допомогою великої кількості даних
• Компоненти, що беруть участь в обробці великої кількості даних
• Компоненти, що працюють з різнорідними технологіями, широко відомими як веб-сервіси тощо.

Всі соціальні додатки, такі як Instagram, Facebook, широкомасштабні галузеві послуги, такі як Uber, Airbnb, онлайн-масові багатокористувацькі ігри, такі як Pokemon Go, програми з фантазійними функціями - це n-ярусні програми.

Мартін Фаулер наочно демонструє:

Шарування - одна з найпоширеніших методик, яку розробники програмного забезпечення використовують для розбиття складної програмної системи. Ви бачите це в архітектурах машин, де шари спускаються з мови програмування з викликами операційної системи в драйвери пристроїв і набори інструкцій процесора, а також в логічні ворота всередині мікросхем. Мережа має FTP шаруватий поверх TCP, який знаходиться поверх IP, який знаходиться поверх Ethernet.

Розмірковуючи систему з точки зору шарів, ви уявляєте основні підсистеми в програмному забезпеченні, розташованому в якійсь формі тортів шарів, де кожен шар спирається на нижній шар. У цій схемі вищий шар використовує різні сервіси, визначені нижчим, але нижній шар не знає про вищий. Крім того, кожен шар зазвичай приховує свої нижні шари від верхніх шарів, тому рівень 4 використовує послуги рівня 3, який використовує послуги шару 2, але шар 4 не знає про рівень 2. (Не всі архітектурні шари непрозорі, як це , але більшість, а точніше, більшість з них є переважно непрозорими.)

Розбиття системи на шари має ряд важливих переваг.

• Ви можете зрозуміти один шар як цілісне ціле, не знаючи багато про інші шари. Ви можете зрозуміти, як створити FTP-послугу поверх TCP, не знаючи деталей того, як працює Ethernet.

• Ви можете замінити шари альтернативними реалізаціями тих же базових служб. Послуга FTP може працювати без змін по ethernet, PPP або тому, що використовує кабельна компанія.

• Ви мінімізуєте залежності між шарами. Якщо кабельна компанія змінить свою фізичну систему передачі за умови, що вони змушують IP працювати, нам не доведеться змінювати нашу послугу FTP.

• Шари роблять хороші місця для стандартизації. TCP і IP - це стандарти, оскільки вони визначають, як повинні працювати їхні шари.

• Після створення шару, ви можете використовувати його для багатьох сервісів вищого рівня. Таким чином, TCP / IP використовується FTP, telnet, SSH та HTTP. В іншому випадку всі ці протоколи вищого рівня повинні були написати власні протоколи нижчого рівня. З бібліотеки Кайла Джеффрі Пассареллі

Накладення шарів - важлива техніка, але є і мінуси.

• Шари добре капсулюють деякі, але не всі речі. В результаті інколи ви отримуєте каскадні зміни. Класичний приклад цього у багатошаровому корпоративному додатку - додавання поля, яке потрібно відображати в інтерфейсі користувача, повинно бути в базі даних, і, таким чином, його потрібно додавати до кожного шару між ними.

• Додаткові шари можуть пошкодити продуктивність На кожному шарі речі, як правило, потребують перетворення з одного представлення в інше. Однак інкапсуляція основної функції часто дає ефективніші ефекти, які більш ніж компенсують. Шар, який контролює транзакції, можна оптимізувати, а потім зробить все швидше. Але найважча частина шаруватої архітектури - це вирішити, які шари мати і якою повинна бути відповідальність кожного шару.