关于微服务的想法：
- 微服务应该在功能上依赖于
- 微服务应该专注于在它们拥有的领域做一些有用的工作
- 微服务旨在相互通信
我发现这些想法是矛盾的。
让我给出一个假设的业务场景。
我需要一项服务来执行具有需要自动翻译的步骤的工作流。
我的商家提供自动翻译服务。有一个 RESTful API，我可以在其中发布源语言、目标语言和文本，并返回翻译。这是有用的独立服务的完美示例。它是可重复使用的，完全不知道它的消费者。
我的业务所需的工作流服务是否应利用此服务？如果是这样，则我的服务对另一个服务具有"依赖性"。
如果你把这个推理发挥到极致，世界上的每一个服务都会拥有世界上的每一个功能。
现在，我知道您认为我们可以通过摆脱 resquestion-response (REST) 并进入消息传递来打破这种依赖关系。我的服务发布翻译请求消息。翻译完成后，将发布翻译响应消息，并且我的服务使用此消息。好的，但是我的服务必须冻结工作流并在消息到达时继续。即使等待是真正的异步等待(假设工作流状态持久化并且翻译消息在一天后到达)，它仍然在"等待"中。这只是延迟的请求-响应。
就我个人而言，">独立"是一种适用于多个维度的品质。它可能不是独立于运行时角度，但可以独立于开发、部署、操作和可伸缩性角度。
例如，翻译服务可能由另一个团队独立开发、部署和运营。同时，他们可以根据获得的需求独立于您的业务工作流服务扩展翻译服务。您可以根据自己的需求扩展业务工作流服务(当然下游依赖关系在这里发挥作用，但这是另一个主题)