项目架构：仅用于数据库的服务

Question

我只是想知道这种项目架构的方法有多好：

1）你有N个服务做X事。但是有一个限制 - 他们没有自己的数据库，他们无法直接访问任何数据库。

2）为此，我有一个DB服务，可以访问数据库并对其采取任何行动。

所以worklow是这样的：如果任何服务需要来自数据库的东西，它会向数据库服务询问记录。

这种架构有多好？我遇到了严重的瓶颈吗？

Answer 1

不要将整个数据库放在单个服务和单一界面之后，而是根据由高级业务规则和数据模型（例如用户帐户数据服务，订单）驱动的接口，考虑为数据集的不同部分提供单独的服务数据服务，审计日志数据服务）。这样，您可以根据需要以不同方式模拟/扩展/部署这些独立部分，并在以后需要时更轻松地更改后端存储（例如，从不同数据库检索归档订单）。此外，由于服务管理的数据属于特定类型，因此可以针对每个服务单独做出某些决策（例如，缓存策略 - 可以缓存配置类型数据，可能不缓存活动订单数据）。

最初，您可以在单个服务中实现所有这些接口，然后再将其分开，但这种方法的关键是将接口抽象化并隔离干净。

Answer 2

这是一个非常典型的架构 - 根据抽象编写服务的数据访问代码是个好主意，这样您就可以使用模拟的数据版本进行单元测试。

至少，在一个地方合并数据访问代码是个好主意，这样您就可以轻松地对其进行更改。