Граница микросервисов для нового экспорта - как разделить?

Question

У меня есть данная микросервисная архитектура со следующими доменами.Каждый домен имеет ровно одну базу данных.

• хранилище S
• продающий I

S содержит набор предметов (книг, журналов), которые можно продать,Кроме того, налог на добавленную стоимость поддерживается здесь.Так S содержит сервис s1 для CRUD по пунктам и CRUD по налогам.Кроме того, у него есть служба потребления jms s2.

Домен I обрабатывает все о продажах (счета, условия доставки, ...)

Пока у меня есть микро-сервис i1, который обрабатывает CRUD длясчета (создать счет, список счетов и т. д.).

Я планирую иметь еще один микро-сервис i2, который представляет собой экспорт CSV-файла, содержащего только специальную информацию, которая необходима правительственному чиновнику.

Я не уверен, следует ли поместить новую функцию в i1 или вновый микро сервис i2.

Конечно, экспорт всегда может привести к сбою и уничтожению приложения.При интеграции в i1 весь домен I может дать сбой.С другой стороны, у меня есть другое приложение для развертывания ...

У вас есть немного опыта, чтобы сделать разрыв между службами?

Answer 1

Микросервисы разработаны в основном в ограниченном контексте (DDD). ограниченный контекст может иметь даже более одного микросервиса. Это все о том, чтобы дать и взять, и нет правильного ответа. По моему мнению, до тех пор, пока сервисы независимы и они не мешают друг другу, это должен быть путь. в вашем случае я бы сказал пойти на дополнительную услугу, которая является услугой экспорта. как вы упомянули, это может повлиять на существующее приложение, если оно будет развернуто в существующем приложении.

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