配置是否应该被分割成不同的微服务？

Question

作为基于微服务的系统设计的一部分，我很难从域所有权的角度来决定系统配置的位置。

例如，让我们假设我正在设计一个“存储系统”，为了简单起见，我想讨论以下领域，这些领域现在有一个微服务用于：

1. 订单
2. 库存

现在，我有一个全局设置UI菜单，通过这个菜单，我们正在管理配置。例如，2种配置：

1. 命令--“X天后移除未经批准的订单”
2. 库存-“为关键部件自动订货”

管理配置的最佳位置是什么？

1. 一种管理系统配置和订单的微服务，库存微服务将从中读取以应用它们的逻辑。将向用户公开该服务的一组“设置”API。
2. 配置应该分别在订单和库存微服务中进行管理，UI应该调用这些微服务的相关API。

这里有什么更好的方法？在“配置”中，应该将其视为属于自己的领域吗？或者配置应该驻留在每个服务中？

Answer 1

我倾向于让UI调用相关的API，允许用户酌情查看和更改配置。

最大的原因是管理配置的新微服务可能会破坏微服务的关键特性之一，即它们是独立部署的。您可以通过在配置服务之外拥有默认值来使它们在技术上独立，但是现在需要部署至少两个服务才能完全实现更改规则的能力。

配置服务的使用似乎也扩展了围绕域上下文组织服务的想法，因为针对多个域上下文的可配置规则将存在于一个服务中。

经常需要调用多个服务的UI元素。根据我的经验，UI屏幕通常需要收集和显示来自多个服务的数据。让前端元素扩展到服务以获取配置信息，就像让UI扩展到多个服务以获取订单和库存业务数据一样合理。