如何将与数据库关联的一个后端服务解耦为两个独立的服务？

Question

我有一个大的 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 中直接访问 D_Big 的每个 API 调用替换为 S2 中相应 API 的 API，该 API 只执行与 S1 直接执行的数据库访问完全相同的数据库访问。例如，假设我们在 S1 中有这些 API：

• API_1 从 D_Big 中的 table1 返回列 [foo, bar, baz]

• API_2 将值 foo 写入 D_Big 中的 table2

• API_3 从 D_Big 中的 table3 返回列 *

我会把这些替换为：

• S1 中的 API_1 调用 S2 中的相应 API，该 API 从 D_Big 中的 table1 返回列 [foo, bar, baz]

• S1中的API_2调用S2中对应的API，API_2将值foo写入D_Big中的table2

• S1 中的API_3 调用S2 中对应的API，API_3 从D_Big 中的table3 返回列*

但是理想映射不是一对一的情况呢？就像您应该组合 API 时一样（例如，S1 中的一个 API 调用 S2 中的两个不同 API 以获取所需的数据，或者 S1 中的两个不同 API 调用 S2 中的相同 API 但具有不同的参数）？

如何制作一个良好的接口，将两个服务与过去的共享数据源 (D_Big) 分离？假设 S1 和 S2 都使用基于 Java/XML/Spring 的系统通过 API 调用传输数据。

Answer 1

如果时间允许，这似乎是转向 CQRS 的绝佳机会。使用 CQRS，您将拥有两个 API——一个用于写入，一个用于读取。您不会遇到多个 API 调用的问题，因为 API 代表业务理念（即用例），而不是离散实体访问。您的前端一次只能提交一个用例，因此只有一个 API 调用。在服务器端，您的端点控制器将进行尽可能多的数据库读取或写入，以实现业务理念。

CQRS 是一种出色的架构模式，可以根据需要增长。为了在这里总结，我不得​​不省略很多重要的细节。在开始重构之前了解该模式是值得的。

Answer 2

有一件事我不清楚。单个服务（例如 S2）访问的数据源是否会形成解耦架构？如果数据源本身是共享的，那么像 S1 或 S3..Sn 这样的服务是否会与 S2 而不是 D1_Big 耦合？为了实现真正的解耦，数据源之间应该解耦，这需要仔细的数据建模——微服务作为一种模式有助于拥有更多有界的上下文，这有利于解耦。

微服务与否，我认为与其让一个单独的服务 S2 公开 data 操作，不如让数据源通过一个单独的代码库进行交互，该代码库生成一个可以捆绑的库/接口/jar以及为交互服务（如 S1 等）生成的可部署组件。在 S1 中捆绑 data jar 可以通过构建过程来处理。

业务运营到数据源的映射/交互将比两者之间的服务交互更高效。该层可以处理 CRUD（简单读/写）或任何复杂的方式（例如 RDBMS 中的视图）中的数据特定需求，它认为适合并公开业务功能所需的数据，并使其与客户端无关，并且仍然作为可扩展选项。