rest - 独立（微）服务是个悖论吗？

Question

关于微服务的想法：

• 微服务应该在功能上独立
• 微服务应该专注于在他们拥有的领域中做一些有用的工作
• 微服务旨在相互通信

我觉得这些想法是矛盾的。

让我给出一个假设的业务场景。

我需要一个服务来执行一个需要自动翻译的步骤的工作流。

我的公司有自动翻译服务。有一个 RESTful API，我可以在其中发布源语言、目标语言和文本，并返回翻译。这是一个有用的独立服务的完美示例。它是可重复使用的，并且完全不知道它的消费者。

我的业务需要的工作流服务是否应该利用此服务？如果是这样，那么我的服务对另一个服务有“依赖性”。

如果你把这个推理推到极端，世界上的每一个服务都会有世界上的每一个功能。

现在，我知道您在想，我们可以通过从 resquestion-response (REST) 转移到消息传递来打破这种依赖关系。我的服务发布翻译请求消息。当翻译完成并且我的服务使用此消息时，将发布翻译响应消息。好的，但是我的服务必须冻结工作流程并在消息到达时继续。即使等待是真正的异步等待，它仍然在“等待”（比如工作流状态保持不变并且翻译消息在一天后到达）。这只是延迟的请求响应。

标签： restweb-servicesservicearchitecturemicroservices

Answer 1

对我个人而言，“独立”是一种适用于多个维度的品质。它可能不独立于运行时的角度，但它可以独立于开发、部署、操作和可扩展性的角度。

例如，翻译服务可能由另一个团队独立开发、部署、运营。同时，他们可以根据他们获得的需求，独立于您的业务工作流服务扩展翻译服务。您可以根据自己的需求扩展业务工作流服务（当然下游依赖项在这里发挥作用，但这完全是另一个话题）