Architecture 微服务数据检索

你好 我读了一些关于微服务体系结构的书，但我仍然有疑问。。其中之一是关于当您需要检索与其他实体连接的某些实体的数据时的情况。。。 例如：我们有订单和用户微服务，例如，每个订单都有一些关于用户的信息，客户希望检索用户订单 因此，我认为有三种方法可以实现这一目标：

客户端应用程序向orders microserve发出请求，之后发出请求n 请求用户microservice检索订单中的用户信息

客户端应用程序向订单微服务发出请求，订单微服务向用户微服务发出请求

Orders microservice db存储有关用户的必要信息

对于第一种情况-客户端应用程序从两个来源（订单和用户）一起构建和聚合数据非常复杂

对于第二种情况-如果我们有两个以上的微服务，那么总请求时间将增加

第三种情况与数据一致性问题有关（用户更改了数据，但订单服务数据库尚未更新）

哪种情况最常用

还有一个小问题#2——对于微服务和web api应用程序，每个微服务只包含一个或两个控制器

要回答这三个问题，完全取决于 微服务架构

第一个案例->根据这个案例，您的客户必须通过呼叫不同的微服务做出统一的响应。这是客户端的开销，这是一种糟糕的体系结构方法

第二种情况与第一种情况相比，这是一种很好的方法。如果您有独立的数据库/表（没有任何直接关系），那么这将是一个很好的方法。您只需在相应的表中存储orderId/userId的引用即可获得这些详细信息。您的总请求时间将分组，但您的用户模块将独立于订单模块工作。通过这种方法，您将实现松耦合

第三种情况->如果每个微服务没有不同的数据库，那么这将是最好的方法，因为它将减少对数据库以及其他微服务的调用数量。通过为每个所需模型实现服务方法，您可以直接获得详细信息

哪种情况最常用

答案。 我不认为任何人使用第一种方法是因为它不是好的实践。如果您有用于不同微服务的不同数据库，那么第二种情况就是您的答案。如果您只有一个数据库，那么也可以使用第三种情况。但您的服务层代码将在不同的微服务上复制

对于微服务和web api应用程序，每个微服务只包含一个或两个控制器

每个微服务中的控制器数量没有标准。它将取决于微服务的规模和该微服务所履行的职责