导读 深思熟虑的设计还必须考虑到 API 的性能,如果 API 不能响应越来越多的请求,不能满足不断变化的业务需求,不能按预期运行,良好的设计就毫无意义。

深思熟虑的设计还必须考虑到 API 的性能,如果 API 不能响应越来越多的请求,不能满足不断变化的业务需求,不能按预期运行,良好的设计就毫无意义。

那什么是 API 的性能?

与任何性能一样,API 性能在很大程度上取决于 API 如何响应它收到的不同类型的请求。

比如:我们有一个客户端应用程序,显示客户的当前订单。应用程序从 API 获取订单详细信息。但现在,客户表示,他们想查看所有订单。因此,我们构建了一个“我的订单”页面,用于显示客户的所有订单。这意味着,我们的 API 将返回比以前更多的数据,比以前承受更大的负载。

如何确保我们的 API 能够返回所有数据而不会出现延迟、服务器端错误和过多请求等问题?这里有一些性能提升的最佳实践:

1、缩小和限制有效负载大小

传输数据量大的时候,必然会导致 API 性能下降,而最直接的办法就是降低 API 传输的负载(payload),我们可以使用 GZip 压缩来缩小有效载荷的大小,可以在 Web API 上使用 Deflate compression。或者,我们可以将 Accept-Encoding 标题更新为 gzip。

2、启用缓存

缓存是提高 API 性能的最简单方法之一。如果我们的请求相同的 API,那么该响应的缓存版本有助于避免额外的服务调用或数据库查询。

在使用缓存时,您需要选择合适的缓存淘汰算法,在发生新数据更新时,缓存也要及时更新。

3、提供足够的网络带宽

即使是设计最强大的 API,缓慢的网络也会降低性能。不可靠的网络可能会导致停机,解决这个也相对简单,多花钱投资于适当的网络基础设施,这样我们才能保持理想的性能水平。

此外,如果您有大量后台进程,请在单独的线程上运行这些进程,以避免阻止请求。还可以使用镜像和 CDN在全球不同地区更快地服务请求。

4、限速和防止恶意攻击

API 可能会受到 DDoS 攻击,该攻击可能是恶意和故意的,也可能是工程师调用API在某些本地应用程序的循环中执行时故意的。可以通过测量交易并监控每个 IP 地址或每个SSO/JWT令牌的每秒调用次数,对恶意请求进行屏蔽来避免这种情况。

这种速率限制方法有助于减少对 API 的过度请求,并主动监控和识别可能的恶意活动。

5、尝试使用 PATCH

工程师们普遍认为,PUT 和 PATCH 操作会产生相同的结果。他们在更新资源方面相似,但他们各自执行更新的方式不同:PUT 操作通过向整个资源发送更新来更新资源。PATCH 操作仅对需要更新的资源应用部分更新。因此 PATCH 调用产生较小的负载,并大规模提高性能。

不过,即使 PATCH 调用可以限制请求大小,也应该注意它不是幂等的。PATCH 可以通过一系列多个调用产生不同的结果。因此,应该仔细和故意地考虑您的应用程序是否使用 PATCH 请求,并确保在需要时它们可以幂等地实现。如果没有,请使用 PUT 请求。

6、启用日志记录、监控和警报

如果你应该从这篇文章中学到一件事,那就是这个!日志记录、监控和警报是 API 最重要的组成部分,没有之一。

拥有日志、监控和警报有助于工程师在发生问题之前对其进行诊断和补救。许多API(基于Express/Node、Java、Go)都有预定义的接口来评估以下内容:

/health 
 
/metrics

如果没有启用日志记录,并且存在潜在问题,将无法跟踪来源,或特定请求中出现问题的地点。如果没有启用监控,将无法从分析角度知道一些问题或错误的发生频率。这将不利于做出合理的解决方案。而且,如果没有启用警报,将不知道是否有问题,直到客户(或更糟糕的是客户)报告它。这就比较严重了!

7、启用分页

数据量大时,分页是个很好的策略,不过分页也不是银弹,数据量大时依然会非常慢。一个有效的策略是最多显示前 100 页,几乎没有人会翻到 100 页之后。

最后的话

前后端分离已是常态,对于后端开发来说,最重要的就是设计一个强大的 API,针对 APi 的性能进行适当优化和增强,它可以非常强大,为企业和客户提供出色的体验。作为负责任的工程师,我们有责任决定如何以高性能的方式构建我们的 API,这可以帮助我们实现和超越我们的目标。

原文来自:

本文地址://gulass.cn/improve-api-performance.html编辑:J+1,审核员:逄增宝

Linux大全:

Linux系统大全:

红帽认证RHCE考试心得: