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

Question

我是微服务架构的新手，我有一个场景如下

Database1 - tbl_users (userid | user_name)

Users Api - returns all users in the table tbl_users

Database2 - tbl_orders (Orderid | order_name | user_id (FK))

Orders Api - returns all orders in the table tbl_orders

在整体方法中，我会在订单 api 中加入并显示已下订单的用户，但在微服务方法中，当我必须从一个视图中显示用户和订单时，我该如何处理这种情况订单api？考虑到我是新手

标签： c#.net-coreasp.net-core-webapi

Answer 1

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

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

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

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

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

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