Якщо архітектурі мікросервісу потрібна окрема база даних на мікросервіс, це занадто дорого і некеровано. Навіщо нам це навіть потрібно?

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

Навіщо нам це навіть потрібно?

Ви цього не робите.

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

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

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

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

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

Подорож до мікропослуг - це саме таке: подорож . Це буде різним для кожної компанії. Не існує жорстких і швидких правил, лише компроміси.

Найважча частина про мікросервіси: ваші дані

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

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

Справа в тому, що окрема база даних не підлягає обговоренню. Або я абсолютно не прав?

Це сказало, що ви також помиляєтесь.

Коли ви працюєте в хмарі, бази даних коштують дешево. Безкоштовно зазвичай! Звичайно, сервер коштує грошей, але ми не говоримо про окремий сервер за мікросервіс (принаймні, не спочатку). Єдиний сервер з купою (логічних) баз даних добре, якщо ви старанно уникаєте запитів міжбазових баз даних (які вводять залежності, які шкодять "незалежно розгортатися та масштабуватися"). Пекло, перехресні запити БД неможливі в деяких службах хмарних баз даних, як Azure SQL. Вам навіть не потрібно бути там старанними ...

І я навіть бачив мікросервіси, де вони спільно використовували базу даних, але кожна служба отримала свою схему. Знову ж таки, ви повинні бути ретельними щодо уникнення запитів, які перетинають межі даних.

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

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

Навіщо нам це навіть потрібно?

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

Подивіться на Amazon AWS або Twilio. Чи знаєте ви, чи реалізовані їхні служби в Java чи Ruby? Чи використовують вони Oracle або PostgreSQL чи Cassandra чи MongoDB? Скільки машин вони використовують? Вам це навіть байдуже; Іншими словами, чи впливають на те, як ви користуєтесь цими послугами, технологічний вибір? ... І що ще важливіше, якщо ви переходите до іншої бази даних, чи потрібно було б вам відповідно змінити клієнтську програму?

Тепер, що станеться, якщо дві служби використовують одну і ту ж базу даних? Ось крихітна частина питань, які можуть виникнути:

• Команда, що розробляє службу 1, хоче перейти з SQL Server 2012 на SQL Server 2016. Однак команда 2 покладається на застарілу функцію, яку було видалено в SQL Server 2016.

• Сервіс 1 - це величезний успіх. Розміщення бази даних на двох машинах (майстер і відмовка) вже не є варіантом. Але масштабування кластера на декількох машинах вимагає таких стратегій, як загострення. Тим часом команда 2 задоволена нинішньою шкалою, і не бачить причин переходити до чогось іншого.

• Сервіс 1 повинен перейти до UTF-8 як кодування за замовчуванням. Сервіс 2, однак, із задоволенням використовує код Code Page 1252 Windows Latin 1.

• Сервіс 1 вирішує додати користувача з певним іменем. Однак цей користувач вже існує, створений кілька місяців тому другою командою.

• Для обслуговування 1 потрібно багато різних функцій. Сервіс 2 є критично важливим компонентом і потребує мінімізації можливостей бази даних, щоб зменшити ризик атак.

• Для обслуговування 1 потрібно 15 ТБ дискового простору; швидкість не важлива, тому звичайні жорсткі диски ідеально чудові. Для сервісу 2 потрібно максимум 50 Гб, але доступ до нього потрібно якомога швидше, тобто дані повинні зберігатися на SSD.

• ...

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

це занадто [...] некеровано.

Тоді ти робиш це неправильно. Я думаю, ви розгортаєте вручну .

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

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

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

це занадто дорого

Визначте вартість.

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

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

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

Залежно від того, що ви вважаєте "дорогим".

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

Усі ці служби також можуть спільно використовувати один екземпляр / сервер бази даних та мати лише окремі схеми на одну службу.

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

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

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