是否有“服务注入”的软件工程概念/模式？

Question

我正在实现一个服务，该服务需要调用另一个以我不知道的方式计算结果的服务。

假设我有以下情况： 我的代码中有一些地方，调用一个 HTTP 请求到一个定义的端点，另一个服务返回一个定义的结果。现在，我不能指定如何计算结果，但是我可以定义我期望的结果输出数据类型。我想强调这一点，否则我只会在我的服务中实现计算逻辑。

然后我会向用户描述它：

您需要提供一个 HTTP 服务，使用这个确切的端点，接收这些确切的参数，提供这个确切的结果类型，但是如何计算结果是您的工作。我只需要你的服务的 URL。

之后我的服务的用户会将他们的 HTTP 服务的 URL 配置到我的服务中，这样我就可以向{url}/defined-endpoint 发出 HTTP 请求。

我想不出另一个名字，只能用“服务注入”来描述这个概念，因为它类似于依赖注入，只是在代码中你不提供对象实例，而是提供一个被调用的服务通过http。

我的问题是：这个概念是否有模式或替代方案可以更优雅地解决将计算外包给另一个服务的一般问题？

Answer 1

您正在定义您的服务与其他服务之间的接口方式的合同。这意味着只要双方尊重合同，整合和沟通就会成功。不确定“服务注入”是否是一个很好的术语。您没有在自己的服务中注入某些东西，您只是将计算委托给另一个服务，但您不会将服务的逻辑注入您自己的服务中。这很好，因为这样您就可以很好地分离关注点和松散耦合。只要遵守合同，两种服务都可以根据需要以任何方式进行更改，并且集成仍然有效。

这个概念是否有模式或替代方案可以更优雅地解决将计算外包给另一个服务的一般问题？

这就是微服务生态系统中的工作方式。您有多个公开 API 的服务，这些 API 相互通信以提供整体更高阶的功能。