我有一个应用程序,其中我有另一个服务发送请求以收集从我的应用程序到该服务的请求的 END 点。然后该服务执行请求并将响应发送给另一个端点。
假设我有 END-point ( api/get_cost
),我们在该点向客户提供成本信息。我们仅从另一项服务获取成本信息。因此,在响应用户之前,我必须创建一个成本信息请求,得到响应,然后才响应用户。从架构的角度来看,如何最好地做到这一点?
我有一个应用程序,其中我有另一个服务发送请求以收集从我的应用程序到该服务的请求的 END 点。然后该服务执行请求并将响应发送给另一个端点。
假设我有 END-point ( api/get_cost
),我们在该点向客户提供成本信息。我们仅从另一项服务获取成本信息。因此,在响应用户之前,我必须创建一个成本信息请求,得到响应,然后才响应用户。从架构的角度来看,如何最好地做到这一点?
我认为有两件事你可以做。
让我们简化一下。在给定的用例中有 2 个组件。
客户(用户)U1 --(想要使用api/get_cost
)--> B1(您的后端服务器)--> C1(第 3 方 API 服务器)获取成本信息
方法一:
在这种情况下,您可以在 lib 文件夹中创建一个服务,该服务将有一个负责进行 api 调用的客户端和一个作为接口的服务,您将通过该接口公开从 B1 到 C1 进行 api 调用的方法。
因此,您将使用服务方法对 C1 进行 api 调用。
一个快乐的情况是:U1 从 B1 请求成本信息 -> B1 询问 C1-> C1 用数据响应 -> B1 用数据响应 U1
可能出错的事情:
U1 -> B1 -> C1(但 U1 的服务器已关闭)->(超时)-> 回到 B1 -> B1 向 U1 提供错误。
U1 -> B1 -> C1(C1需要很长时间才能回复)->向B1回复数据-> B1将数据返回给C1
所以,让它更可靠。
在调用 B1 -> C1 时添加超时,以便如果在特定时间未收到数据,您将向用户显示错误。
您可以在 B1 -> C1 之间添加缓存,例如:(如果用户想要获取项目 1 的数据,您可以从 C1 请求数据,然后将其缓存并将其过期时间设置为 15 分钟(取决于您))。现在下次用户在 15 分钟内请求相同的数据时,数据将从缓存中获取,而不是从 C1 中获取)。注意:这也取决于它的数据类型。如果您认为数据是动态的并且每 2 分钟更改一次,则无需添加缓存。
另一种方法,但需要更多的努力:
方法二:
使用短轮询。可以用在对获取数据有严格要求的场景,无论是否需要4秒2秒。
您可以触发从 B1 到 C1 通信的后台作业,并使用 uuid 或请求 id 将响应返回给 U1,并且也可以在后台作业中转发它。像这样在 redis 中维护作业的状态:{request id: { uuid: 123, status: (started, failed, successful), data: {}}}
在后台作业中,在获取响应时,使用数据更新 redis 的请求 ID。
还创建一个 api 来检查您收到的请求 uuid 的状态,并定期轮询 api,直到您收到失败或成功)。您还可以设置时间限制,以便如果状态保持“已启动”,系统不会在 2 分钟后轮询 api。
我知道这比预期的要多一点:3。此外,在软件架构中,没有好坏之分。只有权衡。