C# 如何在微服务中处理表联接

我不熟悉微服务体系结构，我有一个场景如下

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

---

在单片方法中，我将在orders api中进行连接，并显示已下订单的用户，但在microservice方法中，当我必须从orders api在一个视图中显示用户和订单时，我如何处理这种情况？考虑到我是新手，此类情况通常由位于UI关注点和专用服务之间的组合服务来处理。此组合服务将响应来自UI的查询，聚合来自各种服务的数据以构建完整视图模型，然后将其发送回UI

此服务可以采取各种形式，可以是客户端组合，也可以是服务器端组合。客户端组合的一个示例是SPA，其中组件将从多个API中提取数据，将数据投影到有用的东西中并进行渲染，而服务器端示例可以是为视图提供服务的控制器。我在这里使用了“服务”一词，但其含义相当笼统

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

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

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

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

您可以查看其中给出的一些示例并详细解释

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

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

然而，将这些实体转变为服务的好处是：

• 交易表可以位于不同的数据库（或模式）中，而不需要 扩展开始时影响单个数据库
• 维护 一旦每个表都不相关，每个服务都将很容易完成 还有别的吗
• 您可以（如果在您的项目中有意义的话）使用不同的 持久性技术（如NoSQL）

松散地保存东西 夫妻关系和高内聚性并不像许多人争论的那么简单 其思想是在我们的问题领域内设定边界，并确保 相关行为发生在一个地方，并与另一个地方进行沟通 边界尽可能宽松。”

---

这是一种误解，认为“微”意味着一切都必须分解到尽可能低的水平，即使这样做并不能方便地实现任务。这可能会导致效率极低的设计，即假装数据库不存在，无法处理连接。“收集此用户/这些用户及其订单的组合数据”对于一项服务来说已经足够“微”。假设用户和订单之间没有关系，实际上不会使用户的微服务和订单独立。谢谢@ JeroenMostert，但请考虑它是一个预订应用程序，我在MaService中有状态、国家、位置等表。正如上面所述，我在另一个数据库中有订单，我必须将这些表连接到订单，如果我将订单表移动到包含国家、州、位置、用户等的数据库中，是否明智，这样就删除了微服务的概念，或者您对此有何看法？这里“没有规则”你不能有一个只提供订单数据的微服务，一个提供用户数据的微服务，另一个提供两者结合的数据的微服务。但在大多数系统中，这并不是一个优势，因为对系统的任何实际更改都可能意味着所有这些服务都必须同步更新，而允许独立更新服务正是微服务首先存在的原因之一。请注意将微服务的预期用途与其实现分开。我在回答中详细阐述了这一点，但我完全同意@jeroenmoster。有一种可怕的趋势，就是通过HTTP微服务调用公开的数据库。再加上人们对“巨石”的恐惧，解决方案设计有时会变成一场噩梦。代码中鼓励并强制实施的具有清晰边界的精心设计的巨石可能是一件美妙的事情。感谢@Yannick的回复，我在考虑性能，因为如果我有大约4，5个服务，我想加入订单服务（即州、国家、城市等）。o