Question

上下文

我有两个微服务：

管理用户的用户（crud操作）
管理结算信息的结算，并引用用户

实际上，对我来说（告诉我是否错了）最好使用hateoas将用户信息存储到计费数据中。那么我们可以通过API的响应中的超链接“遍历它”吗？

我们可以获得类似的东西：

billing:{
// some informations
   _links:{
     owner:"http://80.80.80.80:7000/users/123456789"
   }
}

问题

我该怎么做才能创建新的结算？实际上，当有人在微服务上发布新的账单时，他也会向用户发送信息。这是否意味着我需要在我的结算服务和用户服务中拥有UserEntity？因此，计费服务将能够编组请求，这意味着两个服务之间的代码重复？或者我应该做些什么？
然后，这是前端（API消费者）的角色，以获得2个请求（一个用于计费，一个用于与计费相关的用户）来获取资源？或者BillingService应该在响应前面之前获得用户？
我在一篇文章中看到，在处理微服务时，使用amqp / bus是一件好事，知道是否存在资源，或检查它是否存在。现在我们需要一个服务容器/注册表来动态发现其他服务。在我的情况下，我使用Zookeeper。但是我该如何告诉Zookeeper“通过hateoas链接向我提供与资源相关的服务的位置：http://80.80.80.80:7000/users/123456789”？我在hateoas架构中遗漏了一些重要信息吗？

Answer 1

如何创建新结算？事实上，当有人发帖时微服务上的新计费，他也发送给用户。这是不是意味着我需要在我的结算服务和我的用户中拥有UserEntity 服务？因此，结算服务将能够对请求进行编组，意思是两个服务之间的代码重复？或者我应该这样做别的什么？

计费服务所需的用户与用户服务中的用户不同。通常，用户的身份是消费者发布新帐单所需的全部内容。如果计费服务需要用户的更多信息，则可以从用户服务查询。这里可能存在一些代码重复，但代码在每个服务中扮演不同的角色，这意味着它们可以在不中断彼此的情况下进化。有些问题可以在此处进一步解释：Bounded contexts sharing a same aggregate，Handling duplication of domain logic using DDD and CQRS

然后，这是前端（API使用者）的作用2 请求（一个用于计费，一个用于与用户相关的用户）结算）获得资源？或者BillingService应该得到用户在回应前线之前？

我认为它为API使用者导航链接带来了最大的灵活性。如果消费者对所有者细节不感兴趣怎么办？

我在一篇文章中看到，使用amqp / bus是件好事在处理微服务时，要知道是否存在资源，或者检查它是否存在。现在我们需要一个服务容器/注册表动态发现其他服务。在我的情况下，我使用Zookeeper。但我怎么能告诉Zookeeper＆＃34;给我服务的位置与hateoas链接的资源相关： http://80.80.80.80:7000/users/123456789＆＃34; ？我错过了一个重要的事情我的hateoas架构中的信息？

不太明白这个。如果消费者的链接类似于＆＃34; http://80.80.80.80:7000/users/123456789＆＃34;已经可以直接访问资源了。为什么要问动物园管理员？我认为zookeeper帮助计费服务为所有者组装URI。例如，计费服务告诉zookeeper＆＃34;给我与用户资源相关的服务的位置＆＃34;。

Answer 2

另一种解决方案是将所有必要信息存储在两个服务中。例如，如果您需要计费中的用户数据，那么只需将所有数据存储在账单数据存储中。您将通过队列（订阅/发布）执行的两个服务之间的同步。这有利有弊，但最终你最终会有一个同步 http呼叫，如果你想收到特定账单的数据。

在微服务中添加项目，参考另一项

2 个答案: