Мікросервіси та реплікація даних

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

Наприклад, у мене є 2 додатки - скажімо, додаток Sales та додаток Ticketing. Припустимо, що обидва ці програми побудовані як власні мікросервіси. Однак обидва ці програми, якщо вони розгорнуті (якщо припустити, що вони розгорнуті окремо, наприклад, продаж продає MongoDB, а для продажу квитків використовується MariaDB), потрібно мати доступ до тих самих екземплярів основних даних, як облікові записи, продукти. Це означатиме, що для даного суб'єкта основних даних буде створено додаток власника (наприклад, для облікових записів, це може бути додаток продажів) та зацікавлена ​​сторона (наприклад, додаток для продажу квитків повинен мати інформацію про облікові записи).

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

Також навіть у Рахунках може бути основна частина, яка є спільною як для продажів, так і для продажу квитків (наприклад, назва рахунку, адреса тощо). Однак деякі аспекти Рахунку можуть бути ТОЛЬКО актуальними для Продажів, а інші ТОЛЬКО актуальними для продажу квитків.

Будь-які думки / найкращі практики / думки стосовно будь-якого з вищезазначених варіантів?

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

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

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

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

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

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

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

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

Повідомлення часто публікувалися з достатньою кількістю супровідних даних для їх обробки.

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

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

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

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

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

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

потрібно мати доступ до тих самих екземплярів основних даних, наприклад, Облікові записи, Продукти

Не те ж саме. Кожна мікро-служба повинна робити власне відображення для облікових записів, продуктів тощо. Ми припускаємо, що кожна мікро-послуга матиме різний спосіб роботи з організаціями.

У дизайні, керованому доменом, це звичайне явище, коли кожен обмежений контекст (в одній програмі!) Може відображати ту саму сутність по-різному.

Якщо вам потрібна додаткова інформація, я рекомендую книгу « Побудова мікросервісів: Проектування дрібнозернистих систем»

Чи розглядали ви концепцію запису скелетів на основі майстерного набору?

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