Перехід від монолітної архітектури до мікросервісів
Хоча багато сучасних виробничих систем використовують багатошарові монолітні архітектури, вони часто не підходять для складних хмарних систем. Основною причиною впровадження хмарних технологій є потреба в гнучкості та швидкості, щоб йти в ногу з інноваціями та конкурентами. Однак багато компаній виявляють, що просте перенесення своїх застарілих монолітних систем у хмару не відповідає їхнім зростаючим потребам. Ці монолітні системи обмежують їх здатність повною мірою використовувати переваги хмари. У цій статті розглядаються проблеми монолітів, чому для оптимального використання хмари потрібна інша архітектура та наводиться реальний приклад міграції монолітної системи до більш придатної архітектури, орієнтованої на хмари.
Чому моноліти — не оптимальна архітектура для хмари
Протягом останніх років у більшості з нас є 3 основні причини, чому ми зацікавлені в переході до хмари, і це без певного порядку:
- Економія витрат
- Краща гнучкість у керуванні обчислювальною інфраструктурою
- Збільшення швидкості випуску оновлень систем
Основною мотивацією для компаній, що переходять до хмари, є збільшення швидкості. Оскільки програмне забезпечення стає дедалі важливішим для бізнесу, компанії прагнуть виділитися через цифрову трансформацію. Це вимагає здатності швидко адаптуватися та вносити зміни в системи на основі інсайтів від клієнтів, отриманих із даних та датчиків. Неможливість швидко змінювати та задовольняти потреби клієнтів робить компанії вразливими до конкурентів. Однак монолітні системи обмежують цю гнучкість, ускладнюючи модифікацію, масштабування та оновлення систем.
Що таке моноліт?
Монолітна програма — це єдиний, уніфікований блок для розгортання, наприклад, один файл WAR у Java або веб-додаток у .NET. Зазвичай вона складається з трьох основних компонентів: бази даних з кількома таблицями, клієнтського інтерфейсу (HTML та JavaScript) та серверної програми, яка обробляє HTTP-запити, виконує логіку домену, взаємодіє з базою даних і генерує HTML-відповіді. Моноліти створюються за допомогою об'єктно-орієнтованих принципів, зазвичай довгоживучі та критичні для бізнесу. Через свою складність вони мають глибокі ієрархії класів та численні взаємозалежності.
Ізоляція помилок не можлива
Як було зазначено вище, моноліти мають багато взаємозалежностей та великий обсяг. Тому функціональність зазвичай охоплює багато частин системи, що неминуче призводить до непередбачених побічних ефектів. За визначенням, моноліти будуються та розгортаються як єдиний блок; між різними частинами системи немає фізичного поділу. Тому неможливо гарантувати, що новий реліз вплине тільки на ті частини, на які він орієнтований. Навіть при повному регресійному тестуванні неможливо гарантувати ізоляцію змін — непередбачені побічні ефекти завжди можливі.
Складно належним чином масштабувати
Масштабування окремих частин монолітної програми є складним і ресурсоємним. Для масштабування зазвичай потрібно розгортати кілька інстансів всієї програми, що призводить до збільшення використання пам'яті та обчислювальних ресурсів. Наприклад, якщо потрібно збільшити пропускну здатність підсистеми замовлень, слід розгорнути додаткові інстанси всієї програми або збільшити потужність віртуальної машини, що може не вирішити проблему. Такий підхід також може погіршити проблеми, такі як блокування бази даних. В кінцевому підсумку, масштабування монолітних програм потребує значних ресурсів, що суперечить принципам гнучкості та ефективності.
Розгортання є обтяжливим і займає багато часу
Монолітна архітектура, хоча й є поширеною, стає вузьким місцем у великих і складних системах. Зі збільшенням системи цикли розробки та тестування QA подовжуються, що уповільнює процес. Крім того, навіть незначні зміни в одному компоненті чи додавання нової функціональності потребують перебудови, повного регресійного тестування та повторного розгортання всієї програми.
Цей процес займає багато часу та вимагає значної координації серед членів команди, що додатково гальмує цикли випуску та ускладнює часті оновлення.
І останнє, але не менш важливе
Однією з основних недоліків монолітної архітектури є її довгострокова прив'язаність до конкретного технологічного стеку. Оскільки шари в моноліті тісно зв'язані і розроблені з використанням однієї технології для забезпечення сумісності, кожне оновлення системи ще більше укорінює цю технологію. У міру росту коду стає все складніше для розробників змінювати чи експериментувати з новими технологіями, що обмежує можливості впровадження інновацій. Така відсутність гнучкості може стримувати конкурентоспроможність, особливо в умовах швидко змінюваного технологічного ландшафту, де здатність впроваджувати нові технології є критично важливою для збереження конкурентних переваг.
Архітектура, оптимізована для хмари
Хмарні додатки пропонують гнучкість, стійкість та масштабованість, але просте перенесення в хмару не гарантує цих переваг. Щоб повною мірою використати потенціал хмари, організації повинні переглянути свою архітектуру додатків, оскільки традиційні дизайни часто не відповідають вимогам. Архітектура мікросервісів, яка акцентує увагу на модульності, слабко зв'язаних сервісах та обмежених контекстах, стала основним підходом для максимального використання переваг хмари.
На відміну від старої архітектури орієнтованої на сервіси (SOA), мікросервіси розбивають додатки на маленькі, незалежні сервіси з вузько визначеними API, що знижує зв'язність системи. Це сприяє швидшій розробці, легшому масштабуванню та дозволяє командам працювати автономно над різними модулями, що прискорює вихід на ринок. Кожен мікросервіс працює зі своєю бізнес-логікою та сховищем даних, що підвищує безпеку, ізоляцію помилок та час безвідмовної роботи, оскільки збої в одному сервісі не впливають на інші.
Мікросервіси також пропонують гнучкість у виборі незалежних рівнів даних і технологій, що ще більше покращує масштабованість. Такий децентралізований підхід дозволяє легше тестувати, оновлювати та масштабувати систему, а якщо сервіс стає занадто великим, його можна розділити на менші сервіси для збереження гнучкості та автономії.
Нижче надано діаграму, яка наочно демонструє відмінності між двома архітектурами:
Прийняття архітектури мікросервісів дозволяє кожному сервісу розроблятися з використанням найбільш підходящої мови програмування та технологічного стеку, відповідно до його специфічних вимог. Немає вимоги до того, щоб усі мікросервіси використовували однакову технологію, якщо вони взаємодіють через загальний легкий протокол (наприклад, HTTP або повідомлення) і використовують стандартний формат даних, такий як JSON. Ця гнучкість допомагає командам обирати найкращі інструменти для своїх потреб, вирішуючи проблеми з набором талантів, які виникають при використанні монолітних систем, та дозволяючи працювати з технологіями, з якими вони найбільш комфортно працюють.
Підхід до переходу від моноліту до мікросервісів
При переході від монолітної системи до хмарно-оптимізованої архітектури мікросервісів важливо підходити до міграції обережно, розглядаючи це як будь-яке рефакторування або модернізацію додатку. Переписування за принципом «Big Bang», де вся система будується з нуля за допомогою мікросервісів, не є рекомендованим через високий рівень ризику та складність. Такий підхід рідко є здійсненним на практиці, оскільки він вимагає значного попереднього планування та розуміння всієї системи, що може бути затратним за часом та коштами.
Замість цього переважною стратегією є поступове, інкрементальне рефакторування монолітної системи. З часом монолітний додаток розбивається на мікросервіси, зменшуючи його обсяг до того, як він або зникне, або стане просто ще одним мікросервісом.
Ключовим є фокусування на тих областях, які найкраще підходять вашій команді, не намагаючись розпадати все одразу.
Попередження
Хоча архітектура мікросервісів має такі переваги, як незалежне розгортання, чітко визначені межі підсистем і різноманіття технологій, вона також вводить значну складність. Виклики, такі як управління незалежними моделями даних, забезпечення надійної комунікації, обробка зрідженої консистентності та вирішення операційних складнощів, роблять її складнішою за традиційні монолітні системи. Розробка та масштабування розподілених сервісів вимагають ретельного розгляду та відповідних інструментів. Якщо система має стабільний набір функцій і відомі навантаження (наприклад, внутрішня система звітності про витрати), її просте перенесення в хмару може бути кращим вибором, що все одно дасть багато переваг без додаткової складності мікросервісів.
Досить слів, давайте зробимо це реальним!
Ми візьмемо за приклад вебсайт електронної комерції під назвою eShop (для прикладу), щоб продемонструвати наш процес міграції. Як видно з ілюстрації нижче, всі різні компоненти та функції, необхідні для системи, правильно поділені та розподілені. Це чудове відображення багатьох систем, що працюють в продукції сьогодні, і стане хорошим прикладом для нашої міграційної подорожі.
Архітектура системи високого рівня
Точка відліку
У більшості вебдодатків зазвичай є три різні шари, які можуть або не можуть бути розгорнуті в різних фізичних рівнях:
- Шар презентації — Компоненти, що обробляють запити браузерів (або HTTP) і реалізують HTML-інтерфейс.
- Шар бізнес-логіки (BLL) — Компоненти, що є ядром додатку та реалізують бізнес-правила.
- Шар доступу до даних (DAL) — Компоненти, що здійснюють доступ до інфраструктурних компонентів, таких як бази даних і брокери повідомлень.
Якщо система спроектована належним чином, зазвичай є чітке розділення між шаром презентації та шаром бізнес-логіки. eShop підпадає під цю категорію. Вона має добре продуманий Шар Бізнес-Логіки з чітко визначеними інтерфейсами, які можна використовувати для вбудовуваних реалізацій. З поточною реалізацією, Шар Бізнес-Логіки eShop виконує внутрішні виклики до свого Oracle-базованого Шару Доступу до Даних для взаємодії з базою даних. Завдяки своїй вбудовуваній природі, ми можемо безшовно замінити існуючу реалізацію на віддалені виклики до сервісної реалізації, поки ми збережемо підписи методів виклику.
Розподіл моноліту таким чином дозволяє вам розробляти, розгортати та масштабувати вебсайт незалежно від сервісів. Зокрема, це дозволяє розробникам шару презентації та тестувальникам QA швидко ітеративно працювати над інтерфейсом і легко проводити A/B-тестування, перевіряючи правильність нових сервісів.
Як визначити межі для мікросервісів?
Тепер, коли ми визначили безшовний та легкий спосіб «вбудувати» наші реалізації сервісів у існуючу кодову базу, нам потрібно звернути увагу на визначення обсягу або меж сервісів, які ми будемо розробляти.
Проектування на основі домену (Domain-Driven Design, DDD) — це методологія, яка фокусується на моделюванні програмного забезпечення на основі реальних бізнес-кейсів. Вона передбачає розбиття бізнес-домену на менші, керовані частини, або за бізнес-функцією, або за процесом, для кращого розуміння та вирішення складнощів за допомогою технологій. DDD сприяє використанню специфічної для бізнесу термінології (так званої «всезрозумілої мови») для опису проблем системи, що полегшує узгодження дизайну системи між бізнесом та IT-стейкхолдерами.
У DDD концепція «обмежених контекстів» є ключовою. Обмежений контекст визначає конкретний домен, інкапсулюючи такі елементи, як моделі домену, моделі даних та сервіси додатка, і вказує, як він інтегрується з іншими контекстами.
Ця ідея добре узгоджується з мікросервісами, оскільки обидва підходи зосереджуються на автономії, чітких інтерфейсах та реалізації бізнес-функціональностей. Тому DDD є цінним інструментом для ідентифікації та проектування мікросервісів.
А як щодо eShop?
Використання архітектури мікросервісів стає зручнішим, коли домен добре розуміється, і eShop є канонічним вебсайтом електронної комерції, що легко підпадає під цей підхід. Його основні бізнес-функціональності наступні:
- замовлення
- каталог товарів та інвентар
- керування профілем користувача
Як і очікувалось, ці функціональності чудово співпадають із тим, як був спроектований eShop. З урахуванням цього, використовуючи описану вище техніку, ми просто повинні створити еквівалентний набір реалізацій мікросервісів, які будуть ідентичними оригінальним методам, за підписами методів, і таким чином досягнемо мети розбиття моноліту!
eShop з архітектурою мікросервісів
Висновок
Архітектура мікросервісів з'явилася як рішення для обмежень традиційних монолітних архітектур додатків. Монолітні системи, незалежно від того, наскільки добре вони спроектовані, в кінцевому підсумку стикаються з труднощами при масштабуванні через проблеми з великими базами даних, роздутих кодових базах або неможливість швидко додавати нові функціональності. Мікросервіси вирішують ці проблеми шляхом розподілу, зосереджуючи увагу на гнучкості та замінюваності, а не на повторному використанні. На відміну від монолітів, мікросервіси є стійкими, оскільки вони обмежують технічний борг та дозволяють швидко адаптуватися до змінюваних бізнес-потреб, додаючи нові мікросервіси, а не змінюючи існуючі.
Перекладено з: Taking the Cloud-Native Approach with Microservices