我正在实现一个服务，该服务需要调用另一个服务，该服务以我不知道的方式计算结果。
假设我有以下场景: 我的代码中有一些地方，调用 HTTP 请求到定义的端点，另一个服务返回定义的结果。现在，我不能指定如何计算结果，但我可以定义我期望的结果输出数据类型。我想强调这一点，否则我只会在我的服务中实现计算逻辑。
然后我会向用户描述它:
You need to provide an HTTP service, with this exact endpoint, receiving these exact parameters, delivering this exact result type, but how you calculate the result is your job. I just need the URL of your service.
之后，我的服务的用户将他们的 HTTP 服务的 URL 配置到我的服务中，以便我可以向 {url}/defined-endpoint 发出 HTTP 请求。
除了“服务注入(inject)”之外，我想不出另一个名字来描述这个概念，因为它与依赖注入(inject)很相似，只是在代码中你不提供对象实例，而是提供一个被调用的服务通过http。
我的问题是:这个概念是否有一种模式或替代方案可以更优雅地解决将计算外包给其他服务的一般问题？
最佳答案
您正在定义您的服务与其他服务之间的接口(interface)方式的契约。这意味着只要双方尊重契约(Contract)，整合和沟通就会成功。不确定“服务注入(inject)”是否是一个很好的术语。您没有在自己的服务中注入(inject)某些内容，您只是将计算委托(delegate)给另一个服务，但您没有将服务的逻辑注入(inject)到您自己的服务中。这很好，因为这样你就可以很好地分离关注点和松散耦合。只要遵守契约(Contract)，这两项服务都可以根据需要以任何方式进行更改，并且集成仍然有效。
Is there a pattern for this concept or an alternative that more elegantly solves the general problem of outsourcing a calculation to another service?
这就是微服务生态系统中的运作方式。您有多个公开 API 的服务，这些 API 相互通信以提供整体更高阶的功能。
关于http - "service injection"是否有软件工程概念/模式？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69390771/