当一个微服务依赖于其他微服务时，如何独立开发它？答案

【问题标题】：How do you develop a microservice in isolation when it depends on other microservices?当一个微服务依赖于其他微服务时，如何独立开发它？
【发布时间】：2017-05-28 05:40:11
【问题描述】：

我们正在评估向微服务的转变。每个微服务都是自己独立开发的项目。在规划期间，我们已经确定一些微服务将通过 REST 调用、发布/订阅、消息传递与其他微服务进行通信（即订单服务需要来自产品服务的产品信息）。

如果一个微服务依赖于从另一个微服务中获取数据，那么在开发过程中如何隔离运行呢？例如，当您的订单服务请求产品详细信息但没有任何内容可以回答该请求时会发生什么？

【问题讨论】：

mbtest.org

标签： microservices

【解决方案1】：

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

【讨论】：

公开是指将成为微服务对话一部分的路径。这同样适用于其他消息传递渠道
我想我明白了。我们将在微服务旁边开发一个客户端应用程序，该应用程序可以生成虚假事件或响应 REST 请求，以便我们可以根据需要触发事件并灵活调整微服务的各个部分并进行调试。这听起来正确吗？感谢您的有用回答。
是的，但不是客户端，只有其他微服务可以智能地知道何时调用了“模拟”路径来发送虚拟数据。您甚至可以通过浏览器将事件的数据提供给模拟服务，以避免必须对其进行编码（至少在您准备好使其成为 CI 的一部分之前，正式测试运行）
@efekctive 我认为问题在于设计以及如何使服务正确解耦，而不在于如何模拟服务。详情请参阅我的回答。
@IlliakaillI 我的回答不排除上述任何一项。但请随时帮助发帖者。

【解决方案2】：

如果一个微服务依赖于从另一个微服务中获取数据，那么它在开发过程中如何隔离运行？

在开发和生产过程中，它也应该始终与其他服务暂时隔离。

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

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

请考虑阅读this series of articles 了解有关微服务的更多详细信息。但简而言之：你的服务应该在时间上解耦，所以当你的产品服务宕机时——订单服务可以继续运行而不会中断。一般来说，这是理解良好分布式系统设计的关键。

【讨论】：

关于避免请求/响应的要点。我们仍在苦苦思索如何在这种情况下有效地发展。如果开发服务 A 订阅 B 的事件，开发者如何测试 A 的功能而不需要建立 B 的实例来产生事件？
此外，我们正在使用 REST 服务来抽象出与遗留系统中非常糟糕的部分的交互。我现在意识到这以后会很麻烦！有趣的问题，因为不可能使旧系统事件驱动。
@kenchilada 使用 pub-subscribe 进行测试非常简单：您只需将测试中的测试事件发布到总线/事件存储中。即使没有使用假货，您的 SUT 服务也会“认为”它们来自系统的其他部分。
@kenchilada 顺便说一句，可以让旧系统发出事件，而新系统将消耗这些事件。一点一点重构遗留系统其实是最简单的方法。