Question

我有2个名为User和Order的微服务API。由于这些都是微服务，因此它们都具有单独的 DbContext和不同的不相关实体。我得到的要求之一是列出Orders的{{1}}的名称。

简化的实体如下：

User

现在，我只能想到一种有效的方法，但是仍然有缺点

检索订单并将所有UserId发送到User微服务，方法如下：

public class User
{
   public Guid UserId {get;set;}
   public string Name  {get;set;}
   //Notice no ORM relations added for Order
}

public class Order
{
   public Guid OrderId {get;set;}
   public Guid UserId {get;set}
   //Notice no ORM relations user added. ONLY UserId is returned since this is a microservice and another domain
}

使用我的方法，这似乎不切实际，因为有一天以后，要求可能会更改，并且可能还会需要用户性别或任何其他信息。然后，我将不得不针对特定要求编写许多方法，或者每次都更改我的代码。另外，每次检索public ICollection<Tuple<Guid,string> GetUserNames(ICollection<Guid> userIds) { //go to the database with ORM and get userId and username as a list }的 ALL 信息也不可行，因为这会消耗大量网络流量。

是否有这样的最佳实践来更好地处理共享实体？还是您认为这种方法仍然足够好？

谢谢。

Answer 1

基于明确的关注点，我将提出以下建议之一。绝对要让用户服务只负责对用户的任何查询，而订单服务要负责有关订单的查询。现在您可以：

在发送有关使用用户ID（而不是名称）的订单的查询之前，请客户端先查询用户名的用户ID。这可能是最简单的解决方案，但会使您的客户在业务逻辑上加重。
使Order服务依赖于User服务。因此，订单服务通过用户名获取有关订单的查询，然后订单服务在内部获取订单之前先询问用户服务哪些用户ID是用户ID。
引入第三个业务服务，该服务负责复杂的域查询，并将其分解为对您的专业服务的请求。例如。将原始查询发送到此服务，然后该服务向用户服务查询名称中的ID，并使用这些ID从订单服务中按ID查询订单。有时，架构师会选择在自定义API网关中包含此类逻辑，然后将其用作聚合器。

请注意，我上面在所有三种按名称检索用户ID的解决方案中所描述的调用都可能包含更多信息，并且更像是通用的用户搜索API，该API还允许按用户状态，年龄等进行搜索。

因此，有很多选择，并且取决于您对域的其他要求和体系结构，一个可能比另一个更好。

如何使用实体框架最好地处理微服务中的共享实体？

1 个答案: