假设我们有四种微服务：用户，商店，订阅和产品。
用户向其商店发送添加产品的请求，我们需要满足以下条件才能添加产品：
在检查了规则之后，我们可以在我们的产品微服务中为其商店创建产品。
我有两个选择：
什么是最好的解决方案，还有更好的选择吗？
答案 0 :(得分：1)
什么是最好的解决方案，还有更好的选择吗？
要回顾的重要一件事是您的服务范围是否实际上符合您的需求。您要计算的数据分散在许多服务中的事实是一个不好的信号。
如果您的服务要真正实现自治，那么我们希望设计即使所有服务都不能同时运行，也可以使一切正常运行。有了这样的约束，我们再也不会在两个服务之间进行同步调用了。取而代之的是，我们将通过某种不会在服务关闭时丢失消息的传输方式来回传递消息（数据库，消息存储库或消息队列，或者与是否需要域逻辑进程正在运行）。
实际上，我们安排需要执行计算的服务将收集带有（可能是过时的）必要数据副本的消息。换句话说，从其他服务获取的数据是data on the outside。
外部数据的重要思想之一？数据未未锁定。您真的不想尝试同时锁定不同服务拥有的数据。
此外，您应该假定对用户的响应将是异步的。我们可能会立即确认来自用户的消息，但这只是承认我们已将请求复制到服务可以找到它的地方。
答案 1 :(得分：0)
在我对微服务的理解中-它们将是独立的，并因其性质而松散耦合-因此最好将它们这样对待-假设它们根本不了解彼此的上下文。但是，这些过程似乎非常密切相关，以至于几乎可以保证一个过程的输出是另一个过程的输入。
用户-听起来类似于身份/身份验证，可以将其视为其他服务的前提条件-如果不是为了进行身份验证，而是为了所需的上下文。
除此之外-这听起来像是一个问题-流程在何处编排？在客户端（您的选项1）？还是在另一个代表客户调用微服务的“中央”服务中（您的选项2）？
https://dzone.com/articles/microservices-using-saga-pattern建议事件消息传递还可以用于避免由中央服务来协调流程-但是每个微服务都需要订阅其他事件并知道何时执行自己的流程。
对我来说-如果您的服务是真正独立的（例如由不同的供应商，不同的代码库等管理），那么我会在客户端进行协调。
如果该用户的用户界面只是众多（可以创建产品的多个应用程序）之一，那么我将在诸如Enterprise Service Bus之类的系统中创建“中央”编排服务。这使得精心设计的流程可重复使用。
如果您完全控制所有这些微服务，并且它们属于同一解决方案堆栈，那么我将在产品微服务中构建必要的规则检查，并使其成为一项事务。您仍然可以使用POST / PUT命令执行此RESTfuly。
这将是一个很好的图表-如果您认为有帮助，可以乐于起草。
开放您（和其他人）的想法。
克里斯