В архитектуре микросервисов служба для общих функций должна быть общей или нет - PullRequest
0 голосов
/ 03 декабря 2018

Этот вопрос связан с микросервисами, когда у меня есть несколько микросервисов, предлагающих функции / услуги, которые будут заказаны и подлежат оплате.

Я не знаю, какой подход выбрать,

а) Заказ и биллинговая услуга для каждого оплачиваемого микросервиса с их собственными соответствующими базами данных.b) Общая служба управления заказами и биллинга для всех микросервисов.

Меня беспокоит то, что у каждой оплачиваемой функции / услуги есть свои критерии / скидки биллинга.

При рассмотрении некоторых архитектурhttps://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2018/02/Microservice-Architecture-Of-UBER-Microservice-Architecture-Edureka-768x762.png

в блоге: https://dzone.com/articles/microservice-architecture-learn-build-and-deploy-a

В нем описывается биллинг как общий и очень ориентированный на всю архитектуру.

Ваше понимание будетвысоко ценится.

1 Ответ

0 голосов
/ 03 декабря 2018

Из того, что я видел до сих пор, люди предпочитают иметь выделенный микросервис для управления заказами, потому что его поведение не сильно зависит от типа продукта, который заказывается.Каждый заказ имеет почти одинаковый рабочий процесс: размещен, ожидает оплаты, доставлен, отменен и т. Д.

Биллинг одинаковый, поведение зависит не от того, какие продукты указаны в счете, а от того, сколькоони стоят, по данным плательщика и т. д.

Что касается данных, выделенная микросервисная служба управления заказами или биллинга может владеть необходимыми данными.Например, управление Заказом владеет позициями строки заказа, статусом заказа и деталями доставки (адрес, разрешенные дни / часы доставки);микросервису биллинга принадлежит платежная информация пользователя (т. е. адрес).

Что касается устойчивости, управление заказами и биллинг должны работать, даже если другие микросервисы не работают.Например, если каталог Ювелирного продукта не работает и на нем не отображаются детали ювелирных изделий, пользователь должен иметь возможность отменить свой заказ.

Одна вещь, которая беспокоит меня, заключается в том, что каждая оплачиваемая функция / услуга имеетразличные критерии выставления счетов / скидки.

Возможно, каждый домен (оплачиваемая функция / услуга) должен иметь свой собственный модуль Ценообразование , который используется для расчета окончательной цены позиции.Руководство Заказа не заинтересовано в том, как / почему продукт стоит X USD;его интересует только окончательная цена;то же самое относится к Биллингу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...