在微服务体系结构中，用于公共功能的服务应该是通用的或不常见的。

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

从我到目前为止看到的情况来看，人们更喜欢为订单管理提供专门的微服务，因为它的行为并不很大程度上取决于所订购的产品类型。每个订单几乎都有相同的工作流程:放置、等待付款、交付、取消等。

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

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

关于复原力，即使其他微服务下降，订单管理和计费仍应有效。例如，如果珠宝产品目录被关闭，并且它不能显示珠宝的详细信息，用户应该能够取消他的订单。

困扰我的一件事是，每个收费功能/服务都有不同的计费标准/折扣。

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