Я думаю, що це може допомогти бути трохи більш теоретичним. Однією з мотивуючих ідей мікросервісів є спільне - нічого, процеси передачі повідомлень. Мікросервіс - це як актор у моделі "Актор". Це означає, що кожен процес підтримує свій власний локальний стан, і єдиний спосіб доступу одного стану в інший - це надсилання повідомлень (і навіть тоді інший процес може реагувати, наскільки це подобається на ці повідомлення). Мається на увазі те, що "кожна мікросервіс має свою базу даних" - це те, що стан процесу (тобто мікросервіс) є локальним та приватним . Значною мірою, це говорить про те, що «база даних» повинні бути співвіднесеніз мікросервісом, тобто "база даних" повинна зберігатися і виконуватися на тому ж логічному вузлі, що і мікросервіс. Різні "екземпляри" мікросервісу - це окремі процеси, і тому кожен повинен мати свою "базу даних".
Глобальна база даних або база даних, що ділиться між мікропослугами або навіть екземплярами мікросервісу, з цього погляду становитиме спільний стан. "Відповідний" спосіб вирішити це з точки зору мікросервісів - це посередницька база даних опосередкована мікросервісом "база даних". Інші мікросервіси, які хотіли дізнатися про вміст бази даних, надсилали б повідомлення в цю "мікросервіс бази даних". Зазвичай це не виключає потреби в локальному стані (тобто "базі даних" для екземпляра мікросервісу) для оригінальних мікросервісів! Зміни - те, що представляє місцева держава. Замість того, щоб зберігати "Користувач Саллі - адміністратор", він зберігатиме "Мікросервіс бази даних сказав:" Користувач Саллі - адміністратор "п'ять хвилин тому". Іншими словами, про стан інших мікросервісів.
Користь у тому, що кожна мікросервіс є самодостатнім. Це робить мікросервіс атомною одиницею відмови. Вам (здебільшого) не потрібно турбуватися про мікросервіс у якомусь частково функціональному стані. Звичайно, проблема була перенесена на мережу мікросервісів. Мікросервіс, можливо, не зможе виконати потрібну функцію через неможливість зв’язатися з іншими мікросервісами. Користь, однак, полягає в тому, що мікросервіс буде у чітко визначеному стані і цілком може запропонувати деградований або обмежений сервіс, наприклад, відпрацювавши застарілі переконання. Мінус полягає в тому, що дуже складно отримати послідовний знімок системи в цілому, і може бути досить багато (небажаних) надмірностей і дублювання.
Звичайно, пропозиція не вклеювати екземпляр Oracle у кожен контейнер Docker. По-перше, не кожному мікросервісу потрібна "база даних". Для коректної роботи деяких процесів не потрібно стійкого стану. Наприклад, мікросервіс, який перекладається між двома протоколами, не обов'язково потребує стійкого стану. Бо коли потрібен стійкий стан, слово "база даних" - це лише слово для "стійкого стану". Це може бути файл із JSON в ньому або база даних Sqlite або локально запущена копія Oracle, якщо ви хочете, або будь-який інший спосіб локальноїнаполегливо зберігати дані. Якщо "база даних" не локальна, то з точки зору чистої мікросервісу до неї слід ставитися як до окремої (мікро) служби. З цією метою ніколи не має сенсу, щоб екземпляр RDS був "базою даних" для мікросервісу. Знову ж таки, перспектива - це не "купа мікросервісів із власними базами даних RDS", а "купа мікросервісів, які спілкуються з базами даних RDS". На даний момент немає жодної різниці, зберігаються вони в одному екземплярі бази даних чи ні.
Практично архітектура мікросервісів додає величезну кількість складності. Ця складність є лише ціною серйозної боротьби з частковим збоєм. Для багатьох це надмірність, яка, можливо, не варта переваг. Ви повинні сміливо архітектуру своєї системи будь-яким способом, який видається найбільш вигідним. Є хороший шанс, що занепокоєння щодо простоти та ефективності може призвести до відхилень від чистої архітектури мікросервісів. Вартість буде додатковою зв'язкою, яка представляє власні складності, такі як невидима взаємодія між службами та обмеження вашої свободи розгортання та масштабування за вашим бажанням.