ana*_*sky 5 architecture microservices
美好的一天，我读了一些关于微服务架构的书，但我仍然有问题。其中之一是关于您需要检索有关某些实体的数据时的情况，这些实体与其他实体有关...例如：我们有订单和用户微服务，例如，每个订单都有一些关于用户的信息，客户想要检索用户订单，所以我看到了三种方法来实现这一点：
对于第一种情况- 客户端应用程序从两个来源（订单和用户）构建和聚合数据是很复杂的
对于第二种情况- 如果我们有两个以上的微服务，那么总请求时间将会增加
对于第三种情况与数据一致性问题有关（用户更改了数据，但订单服务数据库尚未更新）
哪种情况最常用？
和小问题 #2 - 在微服务和 web api 应用程序的情况下 - 每个微服务只包含一个或两个控制器？
要回答您的所有三种情况，这完全取决于微服务架构。
第一种情况-> 根据这种情况，您的客户端必须通过调用不同的微服务来做出综合响应。这是客户端的开销，这是糟糕的架构方法。
第二种情况-> 与第一种情况相比，这是一个很好的方法。如果您有独立的数据库/表（没有任何直接关系）那么这将是一个很好的方法。只是您必须在各自的表中存储 orderId/userId 的引用才能获取这些详细信息。您的总请求时间将分组，但您的用户模块将独立于订单模块运行。通过这种方法，您将实现松耦合。
第三种情况-> 如果每个微服务没有不同的数据库，那么这将是最好的方法，因为它将减少对数据库以及其他微服务的调用次数。您可以通过为每个所需模型实现服务方法来获取直接的详细信息。
哪种情况最常用？
答。 我认为没有人使用第一种方法，因为它不是好的做法。如果您对不同的微服务有不同的数据库，那么第二种情况就是您的答案。如果您有单个数据库，那么您也可以继续使用第三种情况。但是您的服务层代码将在不同的微服务上重复。
对于微服务和 Web API 应用程序 - 每个微服务仅包含一个或两个控制器？
每个微服务中控制器的数量没有标准。这将取决于微服务的大小以及该微服务所执行的职责。