[[438012]]

深思熟慮的設(shè)計(jì)還必須考慮到 API 的性能，如果 API 不能響應(yīng)越來越多的請(qǐng)求，不能滿足不斷變化的業(yè)務(wù)需求，不能按預(yù)期運(yùn)行，良好的設(shè)計(jì)就毫無意義。

那什么是 API 的性能?

與任何性能一樣，API 性能在很大程度上取決于 API 如何響應(yīng)它收到的不同類型的請(qǐng)求。

比如：我們有一個(gè)客戶端應(yīng)用程序，顯示客戶的當(dāng)前訂單。應(yīng)用程序從 API 獲取訂單詳細(xì)信息。但現(xiàn)在，客戶表示，他們想查看所有訂單。因此，我們構(gòu)建了一個(gè)“我的訂單”頁面，用于顯示客戶的所有訂單。這意味著，我們的 API 將返回比以前更多的數(shù)據(jù)，比以前承受更大的負(fù)載。

如何確保我們的 API 能夠返回所有數(shù)據(jù)而不會(huì)出現(xiàn)延遲、服務(wù)器端錯(cuò)誤和過多請(qǐng)求等問題?這里有一些性能提升的最佳實(shí)踐：

1、縮小和限制有效負(fù)載大小

傳輸數(shù)據(jù)量大的時(shí)候，必然會(huì)導(dǎo)致 API 性能下降，而最直接的辦法就是降低 API 傳輸?shù)呢?fù)載(payload)，我們可以使用 GZip 壓縮來縮小有效載荷的大小，可以在 Web API 上使用 Deflate compression?；蛘撸覀兛梢詫?Accept-Encoding 標(biāo)題更新為 gzip。

2、啟用緩存

緩存是提高 API 性能的最簡(jiǎn)單方法之一。如果我們的請(qǐng)求相同的 API，那么該響應(yīng)的緩存版本有助于避免額外的服務(wù)調(diào)用或數(shù)據(jù)庫查詢。

在使用緩存時(shí)，您需要選擇合適的緩存淘汰算法，在發(fā)生新數(shù)據(jù)更新時(shí)，緩存也要及時(shí)更新。

3、提供足夠的網(wǎng)絡(luò)帶寬

即使是設(shè)計(jì)最強(qiáng)大的 API，緩慢的網(wǎng)絡(luò)也會(huì)降低性能。不可靠的網(wǎng)絡(luò)可能會(huì)導(dǎo)致停機(jī)，解決這個(gè)也相對(duì)簡(jiǎn)單，多花錢投資于適當(dāng)?shù)木W(wǎng)絡(luò)基礎(chǔ)設(shè)施，這樣我們才能保持理想的性能水平。

此外，如果您有大量后臺(tái)進(jìn)程，請(qǐng)?jiān)趩为?dú)的線程上運(yùn)行這些進(jìn)程，以避免阻止請(qǐng)求。還可以使用鏡像和 CDN在全球不同地區(qū)更快地服務(wù)請(qǐng)求。

4、限速和防止惡意攻擊

API 可能會(huì)受到 DDoS 攻擊，該攻擊可能是惡意和故意的，也可能是工程師調(diào)用API在某些本地應(yīng)用程序的循環(huán)中執(zhí)行時(shí)故意的?？梢酝ㄟ^測(cè)量交易并監(jiān)控每個(gè) IP 地址或每個(gè)SSO/JWT令牌的每秒調(diào)用次數(shù)，對(duì)惡意請(qǐng)求進(jìn)行屏蔽來避免這種情況。

這種速率限制方法有助于減少對(duì) API 的過度請(qǐng)求，并主動(dòng)監(jiān)控和識(shí)別可能的惡意活動(dòng)。

5、嘗試使用 PATCH

工程師們普遍認(rèn)為，PUT 和 PATCH 操作會(huì)產(chǎn)生相同的結(jié)果。他們?cè)诟沦Y源方面相似，但他們各自執(zhí)行更新的方式不同：PUT 操作通過向整個(gè)資源發(fā)送更新來更新資源。PATCH 操作僅對(duì)需要更新的資源應(yīng)用部分更新。因此 PATCH 調(diào)用產(chǎn)生較小的負(fù)載，并大規(guī)模提高性能。

不過，即使 PATCH 調(diào)用可以限制請(qǐng)求大小，也應(yīng)該注意它不是冪等的。PATCH 可以通過一系列多個(gè)調(diào)用產(chǎn)生不同的結(jié)果。因此，應(yīng)該仔細(xì)和故意地考慮您的應(yīng)用程序是否使用 PATCH 請(qǐng)求，并確保在需要時(shí)它們可以冪等地實(shí)現(xiàn)。如果沒有，請(qǐng)使用 PUT 請(qǐng)求。

6、啟用日志記錄、監(jiān)控和警報(bào)

如果你應(yīng)該從這篇文章中學(xué)到一件事，那就是這個(gè)!日志記錄、監(jiān)控和警報(bào)是 API 最重要的組成部分，沒有之一。

擁有日志、監(jiān)控和警報(bào)有助于工程師在發(fā)生問題之前對(duì)其進(jìn)行診斷和補(bǔ)救。許多API(基于Express/Node、Java、Go)都有預(yù)定義的接口來評(píng)估以下內(nèi)容：

/health 
 
/metrics 

如果沒有啟用日志記錄，并且存在潛在問題，將無法跟蹤來源，或特定請(qǐng)求中出現(xiàn)問題的地點(diǎn)。如果沒有啟用監(jiān)控，將無法從分析角度知道一些問題或錯(cuò)誤的發(fā)生頻率。這將不利于做出合理的解決方案。而且，如果沒有啟用警報(bào)，將不知道是否有問題，直到客戶(或更糟糕的是客戶)報(bào)告它。這就比較嚴(yán)重了!

7、啟用分頁

數(shù)據(jù)量大時(shí)，分頁是個(gè)很好的策略，不過分頁也不是銀彈，數(shù)據(jù)量大時(shí)依然會(huì)非常慢。一個(gè)有效的策略是最多顯示前 100 頁，幾乎沒有人會(huì)翻到 100 頁之后。

最后的話 

前后端分離已是常態(tài)，對(duì)于后端開發(fā)來說，最重要的就是設(shè)計(jì)一個(gè)強(qiáng)大的 API，針對(duì) APi 的性能進(jìn)行適當(dāng)優(yōu)化和增強(qiáng)，它可以非常強(qiáng)大，為企業(yè)和客戶提供出色的體驗(yàn)。作為負(fù)責(zé)任的工程師，我們有責(zé)任決定如何以高性能的方式構(gòu)建我們的 API，這可以幫助我們實(shí)現(xiàn)和超越我們的目標(biāo)。

本文轉(zhuǎn)載自微信公眾號(hào)「Python七號(hào)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Python七號(hào)公眾號(hào)。