Мікропослуги: як обробляти відносини із зовнішніми ключами

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

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

Приклад: Я розробляю функцію доставки (мікросервіс 1) для продуктів, а певні товари доставляються лише до певних місць, як зазначено в таблиці товарів, доступних лише для мікросервісів продуктів (mircoservice 2).

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

Можна використовувати спільну базу даних для декількох мікросервісів. Ви можете знайти схеми управління даними мікросервісів за цим посиланням: http://microservices.io/patterns/data/database-per-service.html . До речі, це дуже корисний блог для архітектури мікропослуг.

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

У вашому прикладі служба доставки може дублювати місця доставки та інформацію про товар. Служба продуктів керує продуктами та місцями. Потім необхідні дані копіюються в базу даних служби доставки з асинхронними повідомленнями (наприклад, ви можете використовувати rabbit mq або apache kafka). Служба доставки не змінює дані про товар та місцезнаходження, але використовує дані, коли виконує свою роботу. Якщо частина даних про товар, яка використовується службою доставки, часто змінюється, дублювання даних за допомогою асинхронних повідомлень буде дуже дорогим. У цьому випадку вам слід здійснювати API-дзвінки між Продуктом та Службою доставки. Служба доставки просить Службу продуктів перевірити, чи можна доставити товар у певне місце чи ні. Служба доставки запитує послугу «Продукти» з ідентифікатором (ім’я, ідентифікатор тощо) товару та місцезнаходження. Ці ідентифікатори можна взяти у кінцевого користувача або спільно використовувати їх між мікросервісами. Оскільки бази даних мікросервісів тут різні, ми не можемо визначити зовнішні ключі між даними цих мікросервісів.

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

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

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

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

Подивіться на доповідь Уді Дахан у NDC Осло, щоб отримати докладнішу інформацію

Сподіваюся, це допомагає

перше рішення: Склад API

 Implement a query by defining an API Composer, which invoking the
 services that own the data and performs an in-memory join of the
 results

друге рішення: CQRS

Define a view database, which is a read-only replica that is designed to support that 
query. The application keeps the replica up to data by subscribing to Domain events 
published by the service that own the data.

Оновлення цієї відповіді до 2020 року полягає у використанні інструменту зміни даних, як Debezium. Debezium контролюватиме таблиці вашої бази даних на наявність змін та передаватиме їх у Kafka / Pulsar (інші канали), а ваші абоненти зможуть потім фіксувати зміни та синхронізувати їх.