项目架构，在核心和服务之间传输数据

Question

对不起我的英语。有一个具有单体架构的大型 Java 项目（spring、hibernatne 等）。让我们将其命名为核心。添加新功能是一项艰巨的工作，因此决定从核心中创建新功能，然后通过 http（REST api）链接它们。现在有核心和很多“服务”围绕着它，但是核心和服务只有一个DB。服务之间不传输任何数据。他们像恶魔一样工作，或者核心向他们提出请求。当核心调用任何服务时，会发生以下情况：服务获取请求，直接对数据库进行sql查询，对接收到的数据执行自己的逻辑并将结果返回给核心。我认为使用公共数据库是一种不好的做法，所以我想关闭对数据库的任何服务的直接完全访问。

我有两个想法：

1. 对于修改，我想使用事件（创建、更新、删除）和一个 boker（ActiveMQ、RabbitMQ）

2. 对于阅读，我有 3 个选项之一：

   2.1。在核心端为每个选择查询创建内部 API（这不是一个好的选择，因为我们不想经常重新编译核心）

   2.2。让服务直接从数据库中读取数据

   2.3。将 sql 查询打包到“服务”端的某个对象中并将其发送到核心，那里的查询将被解包并执行，结果将作为 JSON 数组发送回客户端。同样在核心方面，我将检查它是否只是“选择”查询。

我想问你一个问题：

1. 这样分开阅读和修改是不是一个不错的选择？
2. 您能推荐我哪些阅读方式？
3. 如果我选择 2.3 选项进行阅读，你能推荐什么框架？我已经开始关注 JOOQ，但它可能根本不适合它

谢谢

Answer 1

这样做的正确方法是让服务独立工作，每个服务都有自己的数据库和队列，但您也可以使用外部提供者，这可能是您当前的数据库。

使用事件在源数据库中进行数据更改是错误的，因为事件是已经发生的动作。事件就像触发器一样，即使你可以持久化它们携带的数据，你也应该只在你的服务中保持数据冗余，即：运输服务需要知道一个客户地址，所以它甚至会保留它自己的该地址的副本虽然地址存储在客户端服务中。

现在回到你的问题：

1. 您可以将阅读和写作分开，但不能按照您描述的方式进行
2. 选项 2.2 更正确。
3. 为了阅读，使用 JDBC 或像 Dapper 这样的精简架构