我正在运行一个分布式系统，其中多个服务需要向外部第三方资源发出 API 请求。但是，这个第 3 方 API 有 API 限制（每小时 n 个请求，m 个并发请求），我们需要遵守这些限制（注意：如果一小时内达到 n 个请求，则 API 会响应错误，并且秒数重试之前等待）。
如果没有并发请求要求，我们显然可以只查看标头并等待 API 限制结束。但是，如何确保2个微服务不超过并发请求限制呢？我的想法是：
创建一个向第三方 API 发送请求的集中式服务。微服务将请求提交到集中式服务，该服务处理 API 限制。缺点是 API 请求包含大量数据包和大量响应，需要通过集中式服务进行路由
创建一个轻量级、集中式的锁，微服务调用该锁来获取使用 API 的权限。集中式服务将确保一次仅发送 m 个并发请求，并且如果该小时已达到 n 个请求，则永远不会分发锁。我倾向于这个解决方案，但它可能很繁琐吗？
我想知道是否有一些开箱即用的基础设施，例如用于出站呼叫的网关，所有对此第 3 方 API 的请求都将通过该网关进行路由。这是一个随机的想法，我不确定这样的基础设施是否存在
很想听听人们的想法
在 3rd 方 API 之上设置一些东西有什么附加价值？如果服务发出太多请求，它们无论如何都会收到错误，无论是直接来自第 3 方 API 还是来自您的系统，并且它们仍然必须重试请求。
如果您想要吸收请求峰值而不达到第 3 方 API 的限制，那么您可能需要设置一个消息总线来对请求进行排队，并设置一个代理以第 3 方 API 的速率处理消息。然后要小心，正确处理边缘情况：在某些情况下，您可能必须忽略或丢弃一些消息，因为第 3 方 API 无法处理所有接收到的排队到消息总线中的请求。