原标题：如何在以API为中心的架构中克服挑战

大多数API对每个月的请求数和速率限制施加使用限制，例如每分钟最多50个请求。系统的许多部分都可以使用第三方API。处理订阅限制要求系统跟踪所有API调用，并在很快达到限制时发出警报。

通常，增加限制需要人的参与，并且需要提前发出警报。部署的系统必须能够持久跟踪API使用数据，以在服务重新启动或失败时保留数据。此外，如果同一个API被多个应用程序使用，那么收集这些数据并做出决策需要仔细设计。

速率限制更为复杂。如果交给开发人员，他们总会添加睡眠语句，这将在短期内解决问题；然而，从长远来看，当时间改变时，这会导致复杂的问题。更好的方法是使用限制速率的并发数据结构。即使如此，如果多个应用程序使用相同的API，控制速率也会更加复杂。

一种选择是为每个API分配一部分速率，但这样做的缺点是会浪费一些带宽，因为当一些API等待容量时，其他API可能处于空闲状态。最实用的解决方案是通过能够处理所有限制的传出代理发送所有呼叫。

使用外部API的应用程序几乎总是会遇到这个挑战。即使是内部API，如果被许多应用程序使用，也会面临同样的挑战。如果一个API仅由一个应用程序使用，那么将其作为API就没有什么意义了。尝试提供一个处理订阅和速率限制的通用解决方案可能是一个好主意。

克服高延迟和尾部延迟

给定一系列服务调用，尾部延迟是少数需要花费最多时间才能完成的服务调用。如果尾部延迟很高，一些请求将花费太长时间或超时。如果API调用发生在互联网上，尾部延迟会变得更糟。当我们构建结合多个服务的应用程序时，每个服务都会增加延迟。当组合多个服务时，超时的风险会显著增加。

尾部延迟是一个被广泛讨论的话题，我们不再重复。如果你计划在高负载条件下运行API，那么探索和学习这一领域是一个好主意。

但是，为什么这是一个问题？如果我们公开的API不提供服务级别协议（SLA）保证（例如在700毫秒内达到第99百分位），那么使用我们API的下游应用就不可能提供任何保证。除非每个人都能坚持合理的保证，否则整个API经济将崩溃。较新的API规范，如澳大利亚开放银行规范，将延迟限制定义为规范的一部分。

有几种可能的解决方案。如果用例允许，最好的选择是使任务异步。如果你正在调用多个服务，这不可避免地需要太长时间，通常最好通过承诺在准备好时提供结果来设定正确的期望，而不是强迫最终用户等待请求。

当服务调用没有副作用（如搜索）时，还有第二个选项：延迟对冲，即当等待时间超过第80个百分位时，我们启动第二个调用，并在其中一个调用返回时进行响应。这有助于控制长尾。

第三种选择是尝试在执行服务调用时不等待响应，并并行启动尽可能多的服务调用，从而尽可能多地并行完成工作。这并不总是可能的，因为某些服务调用可能取决于早期服务调用的结果。然而，并行调用多个服务并收集结果并组合它们的编码要比一个接一个地执行它们复杂得多。

当需要及时响应时，你将受到依赖API的支配。除非缓存是可能的，否则应用程序的工作速度不能超过其任何依赖服务。当负载增加时，如果依赖端点不能在保持SLA内的响应时间的同时进行扩展，我们将经历更高的延迟。如果依赖的API可以保持在SLA内，我们可以通过为更高级别的服务支付更多费用或购买多个订阅来获得更多容量。如果这是可能的，保持在延迟内就成为了容量规划问题，我们必须保持足够的容量来管理潜在延迟问题的风险。

另一个选项是为同一个功能提供多个API选项。例如，如果你想发送短信或电子邮件，有多种选项。然而，许多其他服务的情况却不同。随着API经济的成熟，许多API可能会有多种竞争选择。当多个选项可用时，应用程序可以向响应更快的API发送更多流量，从而提供更多业务。

如果我们的API有一个客户端，那么事情很简单。我们可以让客户端在系统允许的范围内使用API。然而，如果支持多个客户，我们需要尽量减少一个客户拖慢其他客户的可能性。这也是为什么其他API会有速率限制的原因。我们还应该在API的SLA中定义速率限制。当客户端发送太多请求太快时，我们应该使用状态代码（如HTTP状态代码503）拒绝它们的请求。这样做会告知客户机必须减速。这个过程被称为背压，在这里，我们向上游客户端传达服务过载，消息最终将分发给最终用户。

如果过载而没有任何单个用户发送请求太快，我们需要扩大规模。如果不能扩大规模，我们仍然需要拒绝一些请求。需要注意的是，在这种情况下，拒绝请求会使我们的系统不可用，而在前面的情况下，如果一个客户正在检查其SLA，则拒绝请求不会算作不可用时间。

冷启动时间（容器启动的时间）和服务请求是其他延迟源。一个简单的解决方案是保持副本始终运行；这对于高流量API是可接受的。然而，如果你有许多低流量API，这可能会很昂贵。在这种情况下，你可以猜测流量并在之前预热容器（使用启发式、AI或两者）。另一个选项是优化服务器的启动时间，以允许快速启动。

延迟、规模和高可用性密切相关。即使是经过良好调整的系统，也需要进行扩展，以使系统在可接受的延迟内运行。如果API由于负载而需要拒绝有效请求，那么从用户的角度来看，API将不可用。

跨多个API管理事务

如果你可以从一个运行时（如JVM）运行所有代码，我们可以将其作为一个事务提交。例如，前微服务时代的单体应用程序可以直接使用数据库处理大多数事务。然而，当我们在多个服务（因此是多个运行时）之间破坏逻辑时，如果不做额外的工作，我们就无法在多个业务调用之间承载单个数据库事务。

一种解决方案是对应用服务器提供的特定于语言的事务实现（如Java事务）进行编程。另一种是使用Web服务原子事务（如果您的平台支持）。另一种则是使用支持事务的工作流系统（如Ode或Camunda）。你还可以使用队列，并通过事务管理器（如Atomikos）将数据库事务和队列系统事务合并为单个事务。

最后，对于基于API的架构，故障排除可能更为复杂。重要的是要有足够的跟踪和日志，以帮助你发现错误是发生在系统一侧还是第三方API一侧。此外，我们需要可以共享的清晰数据，以防需要第三方API的帮助来隔离和解决问题。返回搜狐，查看更多

责任编辑：