0

我有一个大的 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 调用传输数据。

4

2 回答 2

0

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

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

于 2018-06-10T15:13:22.700 回答
0

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

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

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

于 2018-06-12T08:19:20.570 回答