Мікросервіси без дублювання даних

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

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

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

Який правильний / найкращий спосіб здійснити це?

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

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

Але я б розробив систему інвентаризації так, щоб вона ніколи не зберігала нічого про користувачів, окрім ідентифікатора користувача. Це вирішує вашу проблему із поширенням змін інформації про користувача.

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

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

Мені важко уникнути дублювання даних….

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

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

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

Дійсно, так.

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

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

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

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

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

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

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

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

І ви не дублюєте дані в мікросервісах , більше ніж у реляційній базі даних (*). У реляційній базі даних ви можете зробити з'єднання , а еквівалент - об'єднати списки в коді, як описано.

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

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

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