我是微服务架构的新手，我有一个场景如下
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查看？考虑到我是新手
最佳答案
此类情况通常由位于 UI 关注点和专用服务之间的组合服务处理。此组合服务将响应来自 UI 的查询，聚合来自各种服务的数据以构建完整的 View 模型，然后将其发送回 UI。
该服务可以采用多种形式，可以是客户端组合，也可以是服务器端组合。客户端组合的一个例子是一个 SPA，其中一个组件将从多个 API 获取，将数据转换到有用的东西中并呈现它，而服务器端的例子可以是服务于 View 的 Controller 。我在这里松散地使用了术语“服务”，但这个想法很笼统。
换个角度来看，删除托管 API 的所有概念，甚至删除数据库的知识。如果您必须在代码中集成两个不同的库，组合函数会是什么样子？它会调用一件事，做一些事情，调用第二件事，再做一些事情，返回结果。
托管 API 等只是增加了实现细节和复杂性，但原理保持不变。
您对必须协调对不同服务的多个调用对性能的影响提出了一些担忧，这当然是有道理的。在处理 API 调用而不是在数据库级别加入时，不仅性能，而且 transient 错误处理和事务完整性都变得更加复杂。
问自己一些问题:
1. 我的数据必须是最新的吗？您能否接受用户的缓存版本，是否希望在您的应用程序中维护该缓存并使其失效？
2. 是否有读取优化版本的 API 已经为您完成了一些数据转换，并在其端维护了一个积极的缓存？
3. 我围绕我的组件绘制的边界是否正确，或者我是否应该以不同的方式合并或分割服务，以便彼此相关的数据足够接近，延迟不会成为瓶颈？
4. 是否有不同类型的数据存储策略可应用于那些经常查询的组件，以便它们开始广播数据更改，从而使您能够构建自己的读取优化数据存储(想想事件源、pub-sub , 那种事)
关于c# - 如何处理微服务中的表连接，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51171448/