我有一个很大的MySQL数据库D_Big，其中包含大量数据。我还有一个服务，S1，具有从该数据库读取或写入的API。例如，一个API可能会从数据库中获取一些内容。另一个可能会向数据库写一行。等等
我还有一个小的辅助数据库D_Small，S1（只有S1）正在读写。我想单独保留小型辅助数据库，但我想改变从大型MySQL数据库D_Big访问数据的方式。
我想这样做，以便访问大型MySQL数据库的唯一方法是通过API调用第二个服务S2，它也可以访问大型数据库。当S1想要D_big中的数据时，它必须调用S2中的API，这将返回D_Big中的数据。因此，我想删除S1对D_Big的直接依赖。
有什么好办法可以做到这一点？什么是一些提示/建议？最简单的方法似乎是将S1中的每个单独的API调用替换为直接使用API访问D_Big到S2中的相应API，该API仅执行S1将直接执行的完全相同的数据库访问。例如，假设我们在S1中有这些API：
我只想用以下内容替换：
但是理想的映射不是一对一的情况呢？就像你应该组合API一样（例如，S1中的一个API调用S2中的两个不同的API来获取它需要的数据，或者S1中的两个不同的API在S2中调用相同的API但具有不同的参数）？
如何建立一个良好的接口，将两个服务与以前的共享数据源（D_Big）解耦？假设S1和S2都使用基于Java / XML / Spring的系统通过API调用传输数据。
如果时间允许，这似乎是转向CQRS的绝佳机会。使用CQRS，您将拥有两个API - 一个用于写入，另一个用于读取。您没有多个API调用的问题，因为API代表业务创意（即用例），而不是离散的实体访问。您的前端应该一次只提交一个用例，因此只有一个API调用。在服务器端，您的端点控制器将进行所需的数据库读取或写入，以实现业务创意。
CQRS是一种优秀的架构模式，可以根据需要增长。我必须省略很多重要的细节才能在这里总结一下。在开始重构之前，了解模式是值得的。
有一件事我不清楚。单个服务（比如说S2）访问的数据源是否会构成一个解耦的体系结构？如果数据源本身是共享的，那么S1或S3..Sn等服务是否会与S2而不是D1_Big耦合？为了实现真正的解耦，数据源应该在它们之间进行解耦，这需要仔细的数据建模 - 作为模式的微服务有助于产生更有限的上下文，这对于解耦是有益的。
微服务与否，我认为不是单独的服务S2暴露数据操作，而是让数据源通过一个单独的代码库进行交互，生成一个库/接口/ jar，它可以与为其生成的deploy-able捆绑在一起。 S1等交互服务可以通过构建过程处理S1中数据jar的捆绑。
业务操作到数据源映射/交互将比两者之间的服务交互更高效。该层可以处理CRUD（简单READ / WRITE）中的数据特定需求或其认为合适的任何复杂方式（例如RDBMS中的视图），并公开业务功能所需的数据并使其与客户端无关，并仍然作为可扩展选项。