Микросервис - Каталог и инвентаризация на разных столах

Question

В настоящее время я изучаю архитектуру микросервиса и основываюсь на том, что прочитал до сих пор. Хорошо бы разделить каталог микросервиса / базы данных и инвентаризацию, и это то, к чему я хочу обратиться.

Проблемы:

Поскольку каталог будет находиться в другой базе данных (PostgreSQL / MongoDB), сравните с инвентаризацией (PostgreSQL). Когда я хочу создать отчет о движении запасов с кодом продукта, каков наилучший способ его моделирования? Пока я отправляю идентификатор продукта в инвентарь, но не код, поскольку он может измениться.

Какой лучший способ отследить движение инвентаря? Я имею в виду эту схему:

-

InventoryTransaction
-productId
-operationDate
-action (IN/OUT)
-count

InventoryTransactionSummary <- updated daily
-productId
-prevTotal - total from the previous date
-total - prevTotal + productIn - productOut
-productIn - in stock
-productOut - sold, pullout, etc

Answer 1

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

Это не золотое правило.

Важно сначала понять бизнес-логику. Вы действительно нуждаетесь в отдельном сервисе для каждого из ваших вариантов использования?

Я не полностью понял ваш пример, но из моего опыта, вот несколько вариантов:

1. Использовать источник событий,Сохраните только необходимые данные о произошедшем событии и, прочитав его, перестройте состояние или используйте ежечасные / ежедневные снимки конечного состояния, чтобы избежать повторного вычисления состояния каждый раз. Таким образом, у вас будут ваши сервисы, как вы определили выше, и у вас будет сервис, который подключается к базе данных источника событий и воссоздает состояние в соответствии с определенной вами функциональностью. Подробнее здесь
2. Базы данных, которые вы используете для OLTP - онлайновая обработка транзакций, например, например, Postgres, не подходят для OLAP - онлайновая аналитическая обработка. Вы можете сохранить ваши данные так же, как вы показали в своем примере, но вы можете добавить триггер в свою базу данных, чтобы при каждой вставке отправлять событие в базу данных OLAP, которая может моделировать ваши данные для более качественных аналитических целей. Подробнее здесь
3. Прежде чем делать выводы с разделением служб, спросите себя, действительно ли вам нужно разделить две службы? Например, машина и колеса. Если мне всегда нужны колеса с автомобилем, зачем отделяться? Это только дает мне больше головной боли. Подробнее здесь