如何处理微服务中的表连接

Question

我是微服务架构的新手，我有一个场景如下Database1 - tbl_users (userid | user_name)Users Api - returns all users in the table tbl_usersDatabase2 - tbl_orders (Orderid | order_name | user_id (FK))Orders Api - returns all orders in the table tbl_orders在整体方法中，我会加入订单 API 并显示已下订单的用户，但在微服务方法中，当我必须在一个视图中显示用户和订单时，我该如何处理这种情况订单API？考虑到我对此很陌生

Answer 1

这种情况通常由位于 UI 关注点和专用服务之间的组合服务处理。此组合服务将响应来自 UI 的查询，聚合来自各种服务的数据以构建完整的视图模型，然后将其发送回 UI。

该服务可以采用多种形式，可以是客户端组合，也可以是服务器端组合。客户端组合的一个示例是 SPA，其中一个组件将从多个 API 获取，将数据投影到有用的东西中并呈现它，而服务器端示例可以是提供视图的控制器。我在这里松散地使用了“服务”这个词，但这个想法很笼统。

换个角度来看，删除托管 API 的所有概念，甚至删除数据库知识。如果必须在代码中集成两个不同的库，组合函数会是什么样子？它会调用一件事，做一些事情，调用第二件事，做更多的事情，返回结果。

托管 API 等只是增加了实现细节和复杂性，但原理保持不变。

您对必须协调对不同服务的多个调用的性能影响提出了一些担忧，这当然是有效的。在处理 API 调用而不是在数据库级别加入时，不仅性能，而且瞬时错误处理和事务完整性都变得更加复杂。

要问自己的一些问题：
1. 我的数据必须是最新的吗？您能否接受用户的缓存版本，并且您是否希望在您的应用程序中维护该缓存并使该缓存失效？
2. 是否有 API 的读取优化版本已经为您完成了一些数据转换，并在它们的末端维护了一个积极的缓存？
3. 围绕组件的边界是否正确绘制，或者我应该以不同的方式合并或分割服务，以便彼此相关的数据足够接近，从而延迟不会成为瓶颈？
4. 是否有不同类型的数据存储策略可以应用于那些经常被查询的组件，以便它们开始广播数据更改，然后使您能够构建自己的读取优化数据存储（想想事件溯源、发布订阅？ ，那种事）

Answer 2

您可以查看这篇文章，其中给出了一些示例并进行了详细解释。

“这种激进的方法给我们带来了一个令人担忧的问题：

使用旧方法，简单的 SQL 连接将为我们带来客户和交易信息。现在，我们需要调用两个 SQL 以获得相同的结果。新方法是否较慢，因为我们需要进行两次 SQL 调用来收集相同的信息？答案是：是的。

但是，将这些实体转化为服务的好处是：

• Deal 表可以位于不同的数据库（或模式）中，而不会在横向扩展开始时影响单个数据库。

• 一旦每个表都与其他任何东西无关，那么每个服务的维护就很容易完成。

• 您可以（如果在您的项目中有意义）使用不同的持久性技术（例如 NoSQL）。

保持事物松散耦合和高凝聚力并不像许多人争论的那样简单。整个想法是在我们的问题域内设置边界，并确保相关行为在一个地方，并尽可能松散地与其他边界进行通信。”