允许服务之间的通信？

Question

我们正在开展多项服务，例如PersonService，InsuranceService和PaycheckService。要通过API访问这些服务，需要一个控制器。

在某些情况下，PaycheckService需要有关Person的信息。 目前，我们正在使用Controller和Service之间的图层：

• 从PersonService获取信息
• 从PaycheckService获取信息
• 合并并返回结果。

目前正在发挥作用，但随着更多服务的创建，服务之间的依赖性也会增加。这会在'层'之间产生更多逻辑（魔术？）。

我一直在阅读Fowler关于依赖注入和服务定位器的主题，这可能很有用。 （我们确实在这里和那里使用Unity for IoC和DI来实现共享功能）

问题是让服务消费其他服务的好策略是什么？

（消息传递，注入，REST，...）

Answer 1

您的服务应该是自主的。他们不应该互相沟通。你认为每个服务都是一个完全独立的产品，可以在其他项目中使用，或者它可以为不同的目的服务于其他公司。

如果ServiceY需要来自ServiceX的一些数据，ServiceY应该将该数据作为输入，它不会连接其他服务来获取数据。

您可以在服务前放置一个门面（或外墙）来编排您的服务。这个外观实际上是您的应用程序的高级业务，其中包括首先从ServiceY获取数据的工作流，而不是将数据提供给ServiceX并从X等获取结果。

如果您的服务不是Web服务，而只是应用程序业务层中的组件，那么它们应该是自治的，不应该互相使用，而Controller可以是您构建服务组件的外观。

Answer 2

您可以创建一个单独的组件，负责根据其提供的合同来促进服务的位置。

这样一种服务只需要知道它想要使用的合约和服务定位器。

定位器可以是任何东西，从从网络共享读取配置列表的类到从耐用存储读取配置或使用WS-Discovery跟踪服务的中央服务。

此外，您可能希望创建/设计一组共享数据协定，指定服务之间交换的类型/消息。这样，您可以减轻在服务中使用的类型之间进行转换的负担。

修改

您已添加到您的问题中：

  

（消息传递，注入，REST，...）

     

要求：快速，松散耦合

说实话，我确实认为这种添加不是很有用，因为这些不是策略，而是可以帮助实现设计的模式和工具。

此外，这些要求并不是很有用，因为我们不知道你认为什么是快速的，也没有松散耦合的特征对你来说最重要。

如果您正在寻找具体的指导，请尝试使问题更具体，或者尝试构建一些内容并询问您遇到的问题。