Microservices 当微服务依赖于其他微服务时，如何单独开发它？

我们正在评估向微服务的转移。每个微服务都是独立开发的自己的项目。在规划过程中，我们确定一些微服务将通过REST呼叫、发布/订阅、消息传递（即订单服务需要产品服务提供的产品信息）与其他微服务进行通信

---

如果一个微服务依赖于从另一个微服务检索数据，那么在开发过程中它如何能够独立运行？例如，当您的订单服务请求产品详细信息，但没有任何响应请求时会发生什么情况？

您可能需要的是存根rest服务。使用不属于公共api的路径创建获取预期输出的webapp。当您调用公共api时，它会发送刚刚接收到的内容

如果一个微服务依赖于从另一个微服务检索数据，那么在开发过程中它如何能够独立运行

在开发和生产期间，It应始终与其他服务暂时隔离

例如，当您的订单服务请求产品详细信息，但没有任何响应请求时会发生什么

这是一个设计缺陷暴露出来的地方：订单服务不应该向其他服务请求产品详细信息。产品详细信息应存储在订购服务将订阅的消息（事件）中。Order服务应该使用发布-订阅模式以异步方式获取此消息，并将其保存在自己的数据库中。因此，有关产品的数据将存储在两个位置

---

请考虑阅读关于微服务的更多细节。但简而言之：您的服务应该是暂时解耦的，所以当您的产品服务出现故障时，服务可以继续运行而不会中断。这是理解良好的分布式系统设计的关键

所谓公共，我指的是将成为微服务对话一部分的路径。这同样适用于Messaging的其他渠道，我想我理解。我们将在微服务旁边开发一个客户端应用程序，它可以生成假事件或响应REST请求，这样我们就可以根据需要触发事件，并调整微服务和调试的各个部分。这听起来对吗？感谢您的帮助。是的，但不仅仅是客户端，其他微服务可以智能地知道何时调用“模拟”路径发送虚拟数据。您甚至可以通过浏览器将事件的数据提供给模拟服务，以避免编写代码（至少在您准备将其作为CI的一部分、正式测试运行之前）@efekctive我认为问题在于设计以及如何使服务正确解耦，而不在于如何模拟服务。有关更多详细信息，请参阅我的答案。@illiakalli我的答案不排除上述任何一项。但是，请随时帮助海报。避免请求/响应是一个很好的观点。我们仍在为如何在这种情况下有效发展而挣扎。如果开发订阅B事件的服务A，开发人员如何测试A的功能而不使用B实例生成事件？此外，我们使用REST服务来抽象与遗留系统中非常糟糕的部分的交互。我现在意识到这将是以后的麻烦！有趣的问题，因为不可能使旧的系统事件驱动。@kenchilada测试使用pub-subscribe非常简单：您只需将测试中的测试事件发布到总线/事件存储中。您的SUT服务将“认为”它们来自系统的另一部分，即使没有使用赝品。@kenchilada，顺便说一句，旧系统可能会发出事件，而新系统将消耗这些事件。这实际上是一点一点地重构遗留系统的最简单方法。