Architecture 在委托持久性逻辑的情况下，如何建模微服务之间的通信

我想问一下以下情况

假设我们有两个应用程序或微服务：

应用程序A位于大型数据存储之上，通过REST公开数据，它是典型的Spring Boot应用程序，需要管理权限、进行一些转换和映射等，并且它能够封装必要的低级数据api，这相当复杂

第二个应用程序B的职责是实现特定领域的核心业务逻辑。此应用程序也有其持久层，即它自己的本地数据存储。然而，它也严重依赖于应用程序A，因为应用程序A集中了对大数据存储的访问

据我所知，我会声明应用程序A和B是独立的应用程序/服务，各自专门用于其任务。 然而，如果有人认为A-B关系实际上是应用程序B的持久层，即与其本地持久性逻辑以及相同的模块，那么它是否会产生任何不同或不必要的后果。这可以被认为是实现Dao或存储库接口，其中一些REST实现在数据层/模块中的后台调用应用程序A

在我看来，我更愿意将其视为一个典型的集成案例，我不会将自己的数据存储的本地持久性逻辑与应用程序B提供的委托数据API混合。我将其视为另一个常规服务，而不是位于B数据层的应用程序B的远程子模块

我希望上面的描述足够容易理解。目前，我想知道，这里的偏好是否意味着真正的、不想要的后果，或者只是个人品味的问题

---

非常感谢您的评论

这有点基于观点，因为没有正确和错误的解决方法。但是，架构问题通常都是这样，所以我来试一试

对于你的场景我有三条路径：

如果应用程序A是一个存储所有或大部分服务数据的单一存储库，则可能需要将其拆分，以便在每个服务边界的域内移动持久性。 如果App B是一个与App非常密切相关的数据的特殊情况，并且两种服务都提供不重叠的所需特征，考虑将App B直接连接到数据库，并将这两种服务置于代表特定域的外观后面。 如果应用程序B所做的只是为应用程序A中的数据提供一个接口，那么很可能您的服务边界画错了，这两者可以/应该结合起来。 使用应用程序B作为应用程序A中数据的接口，在客户端和数据持久性之间的链中添加额外的HTTP API调用，这将是保持性能的一大挑战，也是我要避免的。如果经过仔细评估，确定当前边界是最好的，您可能会寻找一种更快或更同步的方式与应用程序a中的大型数据存储进行通信，比如gRPC或类似的东西

让多个服务共享一个持久性层通常也是不可取的，但如果真的有多个不同的业务域在本质上相同的数据集上运行，这并非闻所未闻。这可能有意义的一个例子是存储/管理地址的服务和使用相同数据存储的单独服务，该数据存储使用外部API验证地址

服务边界应该代表业务域边界，以及那些很少但并非永远不会出现的边界！包括单个大型数据存储。因此，集中精力确保应用程序A和应用程序B根据其业务功能适当独立，您的答案可能会变得更清楚