Мікросервіси та зберігання даних

Я розглядаю можливість перенесення монолітного API REST на архітектуру мікросервісу, і я трохи заплутався щодо зберігання даних. Як я бачу, деякими перевагами мікросервісів були б:

• Горизонтально масштабований - я можу запускати кілька зайвих копій мікросервісу, щоб впоратися з завантаженням та / або сервером, що йде вниз.
• Мало пов'язаний - я можу змінювати внутрішні реалізації мікросервісів, не змінюючи інших, і можу самостійно їх розгортати та змінювати тощо.

Моя проблема - зі зберіганням даних. Як я бачу, є кілька варіантів:

1. Єдина послуга Бази даних, якою поділяються всі мікросервіси - це, здавалося б, повністю усуне будь-яку користь від втрати зв'язку.
2. Місцевий екземпляр бази даних на кожній мікросервісі - я не бачу способу горизонтального масштабування цього, тому не думаю, що це було б варіантом.
3. Кожна мікросервіс має власну службу баз даних - це здається найбільш перспективним, оскільки вона зберігає переваги нещільного з’єднання та горизонтального масштабування (використання надмірних копій бази даних та / або різкості в декількох)

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

Це, відверто кажучи, здається трохи смішним. 16-20 серверів для запуску простого API, маючи на увазі, що реалістичний проект, ймовірно, матиме більше 4-5 послуг? Чи є якась фундаментальна концепція, яка мені не вистачає, що пояснить це?

Деякі речі, які можуть допомогти під час відповіді:

• Я єдиний розробник цього проекту, і буду в осяжному майбутньому.
• Я використовую Node.js та MongoDB, але мене зацікавили б мовно-агностичні відповіді - відповідь може бути навіть у тому, що я просто використовую неправильні технології!

З трьох ваших варіантів найпоширеніший перший (єдина спільна база даних) і третій ("служба бази даних").

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

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

Однак я б запропонував проміжне рішення.

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

Однак як соло-розробник я б оскаржив усе поняття мікросервісів у цей час - Мартін Фаулер пише про Monolith First та Microservice Premium , Саймон Браун розповідає про модульні моноліти , а DHH - про Величний Моноліт. Я не впевнений, наскільки добре організований ваш моноліт, але рефактор і організуйте його. Визначте компоненти та зробіть чисті проміжки між ними, щоб легко витягти шматочки в сервіс. Те саме стосується вашої структури бази даних. Зосередьтеся на хорошій, чистій архітектурі на основі компонентів, яка може підтримувати рефакторинг на послуги. Мікросервіси додають багато накладних витрат для одного розробника для створення та підтримки в операціях. Однак, як тільки у вас є необхідність масштабувати частину системи, використовуйте свої системи моніторингу та звітності для виявлення вузьких місць, вилучення в службу та масштабування за необхідності.

Кожна мікросервіс має власну службу баз даних - це здається найбільш перспективним, оскільки вона зберігає переваги нещільного з’єднання та горизонтального масштабування (використання надмірних копій бази даних та / або різкості в декількох)

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

[...] два фактичні екземпляри мікросервісу на мікросервіс (у разі відмови сервера та для розгортання без простою) та два екземпляри служби бази даних на одну мікросервіс (у разі відмови сервера тощо ...).

Ви маєте рацію щодо кількості мікро-послуг, що працюють, якщо ви хочете мати баланс навантаження. Якщо ви плануєте мати 4 мікро-сервіси, вам потрібно підготувати принаймні 2 екземпляри кожної мікро-служби (загалом 8), як ви вже пояснювали.

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

Це, відверто кажучи, здається трохи смішним. 16-20 серверів для запуску простого API, маючи на увазі, що реалістичний проект, ймовірно, матиме більше 4-5 послуг? Чи є якась фундаментальна концепція, яка мені не вистачає, що пояснить це?

Для простого API цей номер не відповідає. Зверніть увагу, якщо ви не потрапляєте в одну з пасток "Першої мікросервіси" .

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

Дуже грубо кажучи в архітектурному плані, мікросервіс - це термін, який застосовується, скажімо, на логічному рівні. Мікросервіси логічно відокремлені один від одного. З цього погляду мікросервіси повинні володіти кожним і забезпечувати власне сховище, яке має бути відокремлено від зберігання інших мікросервісів. Для мікросервісів ця незалежність зберігання є ключовою для їхньої мети модульності та вільної зв'язку.

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

Отже, коли ми говоримо про окремі мікросервіси, ми на логічному рівні говоримо про API та окремі обов'язки та окремі цикли розробки / розгортання. А коли ми говоримо про горизонтальне масштабування, ми на фізичному рівні говоримо про реалізацію (єдиної) мікросервіси та її розкладання на компоненти без громадянства та стану.

При впровадженні декількох мікросервісів у нас є вибір для повторного використання технологій баз даних для компонентів, що належать до стану:

• окрема база даних на мікросервіс
• спільна база даних з:
  • окрема / приватна схема для мікросервісу
  • окремі / приватні таблиці на мікросервіс

Більше дивіться тут .

Єдина послуга Бази даних, якою поділяються всі мікросервіси - це, здавалося б, повністю усуне будь-яку користь від втрати зв'язку.

Погоджено, якщо ви маєте на увазі обмін рядками та стовпцями таблиць, це насправді не буде мікросервісами.

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

Як правило, написано неабияку кількість про мікропослуги та наполегливість, дивіться також тут .

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

Якщо MS - це незалежний (розгортається) компонент, що вирішує одну найпростішу задачу в умовах без громадянства, ЯКІ БД потрібні? Якщо для вирішення більш складної задачі, яка потребує вирішення більше ніж найпростіших підзадач (MS?), Це все-таки МС? У SOA його називають службою оркестрування. Він реалізує "процес" та координує виклик MS, таким чином, він повинен зберігати свій стан (всі оркестри / організатори / композитори / тощо. Є державними) та потребує персонального сховища даних: ніхто більше не може гартувати стан оркестратора.

Однак ми говоримо не про базу даних, а про доступ до бази даних MS / Service, і це зовсім інша справа. МС може знадобитися певних даних, зібраних у компанії (не в додатку, в якому вона працює), і вона не може запитувати іншу MS через свій API / інтерфейс для даних. Це найпоширеніший і реалістичний сценарій. І інша MS з того самого або іншого додатка може потребувати цих даних або навіть змінювати їх. Так, вони змагаються за дані, як це було завжди до появи MS.

Чому ми розбиваємо «двері», які добре відомі та відкриті? Яка різниця в цьому відношенні між ЧСС та звичайним об'єктом, що постійно зберігається? Навіщо нам потрібна індивідуальна база даних для MS, якщо вона так чи інакше (з метою гнучкості та сумісності) залучає свою службу доступу до даних (DAS)? Не забувайте, що DAS захищає MS з діловим завданням від усвідомлення фізичної підключеності до бази даних. Цю розв'язку та гнучкість MS повинні зберігати, щоб вільно брати участь у декількох додатках без прив’язки до бази даних.