Мікропослуги проти монолітної архітектури [закрито]

Я трохи читав про мікросервіси, і я трохи заінтригований, здається, це цікава концепція. Але мені цікаво, які переваги та недоліки використання мікросервісів перед монолітною архітектурою, і навпаки.

Коли мікросервіси підходять краще, а куди краще йти з монолітною архітектурою.

Поки я відносно новачок у світі мікросервісів, я постараюся відповісти на ваше запитання якомога повніше.

Коли ви використовуєте архітектуру мікропослуг, у вас збільшиться роз'єднання та розділення проблем. Оскільки ви буквально розділяєте свою заявку.

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

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

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

Однак для додатків, які не призначені стати занадто великими для управління в майбутньому. Краще тримати його при монолітній архітектурі. Оскільки архітектура мікропослуг пов'язана із серйозними труднощами. Я заявив, що простіше розгорнути мікросервіси, але це справедливо лише у порівнянні з великими монолітами. Використовуючи мікросервіси, ви додаєте складності в розподілі послуг на різні сервери в різних місцях, і вам потрібно знайти спосіб керувати всім цим. Створення мікросервісів допоможе вам у довгостроковій перспективі, якщо ваша програма стане великою, але для менших програм просто простіше залишатися монолітними.

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

Переваги

• Можливість розгортання : більша спритність розгортання нових версій служби завдяки коротшим циклам побудови + тестування + розгортання Крім того, гнучкість використання конфігурацій безпеки, реплікації, стійкості та моніторингу, що стосуються конкретної послуги.
• Надійність : несправність мікросервісу впливає лише на цю мікросервіс та її споживачів, тоді як у монолітній моделі сервісна несправність може зруйнувати весь моноліт.
• Доступність : розгортання нової версії мікросервісу вимагає незначних простоїв, тоді як розгортання нової версії служби в моноліті вимагає, як правило, повільнішого перезапуску всього моноліту.
• Масштабованість : кожну мікросервіс можна масштабувати незалежно за допомогою пулів, кластерів, сіток. Характеристики розгортання роблять мікросервіси чудовим поєднанням еластичності хмари.
• Модифікація : більша гнучкість використання нових фреймворків, бібліотек, джерел даних та інших ресурсів. Крім того, мікросервіси є вільно з'єднаними, модульні компоненти доступні лише за їхніми контрактами, і, отже, менш схильні перетворюватися на великий клубок бруду.
• Управління : зусилля з розробки додатків розподілено на групи, які менші та працюють більш самостійно.
• Автономність дизайну : команда має свободу застосовувати різні технології, фреймворки та шаблони для проектування та реалізації кожної мікросервіси, а також може змінювати та передислокувати кожну мікросервіс самостійно

Виклики

• Можливість розгортання : набагато більше одиниць розгортання, тому є більш складні завдання, сценарії, області передачі та конфігураційні файли для нагляду за розгортанням. (З цієї причини безперервна доставка та DevOps дуже бажані для проектів мікросервісу.)
• Ефективність : службам, швидше за все, потрібно обмінюватися даними через мережу, тоді як послуги в рамках моноліту можуть отримати вигоду від місцевих дзвінків. (З цієї причини дизайн повинен уникати "балакучих" мікропослуг.)
• Модифікація : зміни в контракті, швидше за все, вплинуть на споживачів, розміщених в інших місцях, тоді як у монолітній моделі споживачі, швидше за все, знаходяться в межах моноліту і будуть розгорнуті за допомогою послуги. Крім того, механізми поліпшення автономності, такі як можлива послідовність та асинхронні дзвінки, додають мікросервісам складності.
• Тестованість : інтеграційні тести важче налаштувати та запустити, оскільки вони можуть охоплювати різні мікросервіси в різних середовищах виконання.
• Управління : зусилля з управління операціями зростають, оскільки є більше компонентів середовища виконання, файлів журналів та взаємодії точка-точка, які слід контролювати.
• Використання пам’яті : у кожному наборі мікросервісів часто реплікується кілька класів і бібліотек, і загальний обсяг пам'яті збільшується.
• Автономність виконання : у моноліті розміщена загальна бізнес-логіка. З мікросервісами логіка поширюється на мікросервіси. Отже, за інших рівних умов, швидше за все, мікросервіс буде взаємодіяти з іншими мікросервісами через мережу - ця взаємодія зменшує автономність. Якщо взаємодія між мікросервісами передбачає зміну даних, потреба в транзакційному кордоні ще більше порушує автономність. Хороша новина полягає в тому, що, щоб уникнути проблем автономності виконання, ми можемо застосовувати такі методи, як можлива узгодженість, керована подіями архітектура, CQRS, кеш (реплікація даних) та вирівнювання мікросервісів із контекстами, обмеженими DDD. Ці методи не властиві мікропослугам, але їх пропонував практично кожен автор, якого я читав.

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

@Luxo є на місці. Я просто хотів би запропонувати невелику варіацію та навести організаційну перспективу цього. Мікросервіси не тільки дозволяють розв’язати програми, але це також може допомогти на організаційному рівні. Наприклад, організація могла б розділитися на кілька команд, де кожна з них може розвиватися на наборі мікропослуг, які команда може надати.

Наприклад, у великих магазинах, таких як Amazon, у вас може бути команда персоналізації, команда електронної комерції, команда інфраструктурних служб тощо. Якщо ви хочете зайнятися мікросервісами, Amazon - це дуже хороший приклад. Джефф Безос призначив командам зв’язок із службами іншої команди, якщо їм потрібен доступ до спільних функціональних можливостей. Дивіться тут короткий опис.

Крім того, інженери з Etsy та Netflix також мали невеликі дебати ще в часи мікропослуг проти моноліту в Twitter. Дебати є дещо менш технічними, але також можуть запропонувати кілька розумінь.