microservices - 在微服务架构中，一个针对公共(public)特性的服务应该是公共(public)的还是不公共(public)的

Question

问题与微服务有关，当我有多个微服务提供将被订购和计费的功能/服务时。

我正在确定采用哪种方法，

a) 每个可计费微服务有一个订单和一个计费服务，有各自的数据库。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

它将计费描述为整个架构的通用且非常重要的部分。

我们将不胜感激您的见解。

Answer 1

据我目前所见，人们更喜欢使用专门的微服务来管理订单，因为它的行为不太依赖于所订购产品的类型。每个订单都有几乎相同的工作流程:下单、等待付款、交付、取消等。

计费是一样的，行为不取决于发票上的产品种类，而是取决于它们的成本是多少，取决于付款人数据等。

关于数据，专用的订单管理或计费微服务可以拥有它需要的数据。例如，订单管理拥有订单行项目、订单状态和交货详细信息(地址、允许的交货日期/时间)；计费微服务拥有用户的计费详细信息(即地址)。

关于弹性，即使其他微服务出现故障，订单管理和计费也应该仍然有效。例如，如果珠宝产品目录已关闭且无法显示珠宝详细信息，则用户应该能够取消订单。

One thing that bothers me is that each billable feature/service has a different billing criteria / discounts.

也许每个域(可计费功能/服务)都应该有自己的定价模块，用于计算订单项的最终价格。订单管理对产品如何/为什么花费 X 美元不感兴趣；它只对最终价格感兴趣；这同样适用于计费。