【51CTO.com快譯】在軟件產(chǎn)品開發(fā)的生命周期中，不同的團(tuán)隊(duì)需要關(guān)注不同的API指標(biāo)。無論是API產(chǎn)品經(jīng)理、還是開發(fā)工程師，他們?cè)谶M(jìn)行API分析研究與報(bào)告時(shí)，都會(huì)自然而然地從自身的職能特點(diǎn)去考察各種關(guān)鍵性的API指標(biāo)。下面讓我們從團(tuán)隊(duì)角色出發(fā)，一起討論那些需要關(guān)注的十三項(xiàng)API性能指標(biāo)。

首先我們來看看一個(gè)典型的軟件企業(yè)團(tuán)隊(duì)都有哪些不同的職能角色。

基礎(chǔ)架構(gòu)與開發(fā)運(yùn)營

通過正確地分配有限的資源，確保服務(wù)器能夠正常地運(yùn)轉(zhuǎn)，以供多個(gè)工程團(tuán)隊(duì)使用。

應(yīng)用工程與平臺(tái)

API開發(fā)人員負(fù)責(zé)根據(jù)業(yè)務(wù)邏輯，向API添加新的功能，并解決應(yīng)用程序中的問題。他們交付的產(chǎn)品包括：API即服務(wù)(API as a Service)，與合作伙伴的插件和集成，以及其他豐富的API。

產(chǎn)品管理

API產(chǎn)品經(jīng)理負(fù)責(zé)通過API功能的路線圖，確保構(gòu)建出正確的API節(jié)點(diǎn);并通過工程的時(shí)間和人員條件的約束，來平衡(內(nèi)部或外部)用戶的需求。

業(yè)務(wù)與增長

這是一個(gè)由市場營銷和銷售人員組成的，面向市場的團(tuán)隊(duì)。他們并不會(huì)專注API節(jié)點(diǎn)，而是會(huì)緊跟客戶的興趣點(diǎn)，以確保他們能夠使用到已開發(fā)出的API，并從中發(fā)現(xiàn)新的銷售機(jī)會(huì)。

基礎(chǔ)架構(gòu)API指標(biāo)

此類指標(biāo)主要是應(yīng)用性能監(jiān)視(Application Performance Monitoring，APM)工具(如：Datadog之類的基礎(chǔ)架構(gòu)監(jiān)視公司的產(chǎn)品)所獲取。它們主要關(guān)注如下方面：

1、正常運(yùn)行時(shí)間(uptime)

正常運(yùn)行時(shí)間是衡量服務(wù)可用性的一項(xiàng)最基本的指標(biāo)，我們有時(shí)也稱為“黃金標(biāo)準(zhǔn)”。許多企業(yè)都會(huì)在服務(wù)水平協(xié)議(SLA)中提及，或重點(diǎn)標(biāo)注出各種與服務(wù)相關(guān)的“正常運(yùn)行時(shí)間”標(biāo)準(zhǔn)。如下圖所示，我們?cè)谀承┬g(shù)語表中常見的“三個(gè)九”或“四個(gè)九”等，就是用來衡量某個(gè)服務(wù)系統(tǒng)每年的正常運(yùn)行時(shí)間、與宕機(jī)時(shí)間之間的關(guān)系。

當(dāng)然，從“四個(gè)九”提升到“五個(gè)九”，遠(yuǎn)比從“兩個(gè)九”變成“三個(gè)九”要困難得多，這就是為什么除了關(guān)鍵性的(也是最昂貴的)服務(wù)之外，您在SLA中鮮少看到“五個(gè)九”的原因。話雖如此，我們?nèi)匀豢梢栽跍p少某些服務(wù)的正常運(yùn)行時(shí)間的同時(shí)，確保其在中斷的極端情況下，不會(huì)影響到既定的服務(wù)處理。例如：Moesif(一個(gè)美國人工智能API服務(wù)平臺(tái))就被設(shè)計(jì)為即使其網(wǎng)站和儀表板出現(xiàn)完全中斷的情況，也能夠繼續(xù)通過各種SDK收集數(shù)據(jù)。也就是說，SDK能夠在本地排隊(duì)收集的信息，而不會(huì)中斷現(xiàn)有的應(yīng)用。

正常運(yùn)行時(shí)間通常是通過諸如Pingdom或 UptimeRobot的ping服務(wù)或綜合測試來衡量的。您可以將探測的頻率配置為每分鐘之類的固定時(shí)間間隔，來探測特定節(jié)點(diǎn)的/health或/status，以獲取諸如：數(shù)據(jù)備份等其他服務(wù)的基本連通性狀態(tài)。您可以通過Statuspage.io之類的工具，將這些收集到的指標(biāo)發(fā)布到目標(biāo)網(wǎng)站上。例如：Moesif就使用了基于Lambda構(gòu)建的開源狀態(tài)頁面(請(qǐng)參見：https://github.com/ks888/LambStatus)。

當(dāng)然，我們還可以設(shè)置并使用一些被稱為“綜合測試”的復(fù)雜ping服務(wù)。例如：運(yùn)行特定的一套測試序列，并判定響應(yīng)負(fù)載中是否包含一定的數(shù)值。盡管綜合測試可能無法代表用戶真實(shí)的流量，但是這些調(diào)試性的API對(duì)于獲悉系統(tǒng)的正常運(yùn)行狀態(tài)還是非常有意義的。值得說明的是：綜合監(jiān)控是由監(jiān)控服務(wù)觸發(fā)的一組預(yù)定義的API調(diào)用，能夠檢查目標(biāo)API序列是否符合預(yù)期運(yùn)行狀態(tài)。

2、CPU使用率

CPU使用率也是非常經(jīng)典的性能指標(biāo)之一，它可以從某種程度上反應(yīng)應(yīng)用程序的響應(yīng)能力。如果服務(wù)器CPU使用率較高，則可能意味著服務(wù)器或虛擬機(jī)已經(jīng)過載，而且可能會(huì)帶來諸如：大量自旋鎖(spinlock)等應(yīng)用程序的性能錯(cuò)誤。

基礎(chǔ)架構(gòu)工程師可以使用CPU使用率(包括內(nèi)存使用百分比)，來規(guī)劃資源，并衡量整體運(yùn)行狀況。某些類型的應(yīng)用程序(例如高帶寬的代理服務(wù)和API網(wǎng)關(guān))本身就會(huì)比其他進(jìn)程具有更高的CPU使用率，特別是在涉及到諸如視頻編碼、以及機(jī)器學(xué)習(xí)等大量浮點(diǎn)運(yùn)算的工作負(fù)載時(shí)。

在本地調(diào)試API時(shí)，您可以通過Windows上的“任務(wù)管理器”(https://en.wikipedia.org/wiki/Task_Manager_(Windows) )或MacBook上的“Activity Monitor”，來輕松地查看系統(tǒng)和進(jìn)程的CPU使用情況。但是在服務(wù)器上，如果您不想使用SSH或運(yùn)行top命令，那么就需要用到各種APM工具了。通過APM提供的代理，您可以將其嵌入應(yīng)用程序或服務(wù)器中，以捕獲諸如CPU和內(nèi)存使用率之類的指標(biāo)。當(dāng)然，您也可以通過執(zhí)行其他特定功能的應(yīng)用程序監(jiān)控，例如：線程分析。

我們?cè)诓榭碈PU使用率時(shí)，應(yīng)當(dāng)主要關(guān)注的是每個(gè)虛擬CPU(即物理線程)的使用率。如果出現(xiàn)不平衡的情況，則可能意味著應(yīng)用程序沒有正確地執(zhí)行進(jìn)程，或者是線程池的大小配置不正確。

許多APM都能夠讓您使用不同的名稱來標(biāo)記應(yīng)用程序，以方便實(shí)現(xiàn)匯總。例如：您可能希望對(duì)諸如：my-api-westus-vm0、my-api-westus-vm1、my-api-eastus-vm0等每一個(gè)VM指標(biāo)進(jìn)行分組，同時(shí)將它們匯總到一個(gè)名為my-API的標(biāo)簽之中。

3、內(nèi)存使用

與CPU使用率類似，內(nèi)存使用率也是衡量資源利用率的性能指標(biāo)。較高的內(nèi)存使用量可能表明服務(wù)器處于過載的狀態(tài)，因此它往往與配置有關(guān)。

通常情況下，大數(shù)據(jù)查詢、大流量處理、以及各種生產(chǎn)環(huán)境的數(shù)據(jù)庫，都會(huì)消耗比CPU更多的內(nèi)存。因此，為了減少每個(gè)VM在批處理查詢時(shí)所花費(fèi)的時(shí)間，我們應(yīng)當(dāng)分配更多的可用內(nèi)存，以減少檢查點(diǎn)(checkpointing)，網(wǎng)絡(luò)同步，以及對(duì)磁盤的分頁。

我們?cè)诓榭磧?nèi)存的使用情況時(shí)，還應(yīng)該查看頁面的錯(cuò)誤數(shù)、以及I/O的操作數(shù)。常見的配置錯(cuò)誤是：只為應(yīng)用程序分配了一小部分的可用物理內(nèi)存。這樣就很可能會(huì)導(dǎo)致高頁面的虛擬內(nèi)存崩潰。

應(yīng)用程序的API指標(biāo)

4、每分鐘請(qǐng)求數(shù)(RPM)

每分鐘請(qǐng)求數(shù)(Requests per Minute，RPM)是我們?cè)诒容^HTTP、或數(shù)據(jù)庫服務(wù)器時(shí)經(jīng)常使用的性能指標(biāo)。由于服務(wù)器無法準(zhǔn)確地計(jì)算出諸如：第三方服務(wù)在對(duì)數(shù)據(jù)庫進(jìn)行I/O操作時(shí)所引起的延遲，因此某些產(chǎn)品雖然會(huì)吹噓自己擁有較高的RPM，但是您的團(tuán)隊(duì)仍然需要以效率為目標(biāo)設(shè)法降低RPM。

通常情況下，您需要將具有多個(gè)API調(diào)用的某些業(yè)務(wù)功能，合并為更少的API調(diào)用，以減少RPM的數(shù)量。例如：您可以在單個(gè)請(qǐng)求中，批量處理多個(gè)請(qǐng)求，以確保自己具有靈活、實(shí)用的分頁方案。

與RPM相關(guān)的術(shù)語包括：每秒請(qǐng)求數(shù)(Requests per Second，RPS)和每秒查詢數(shù)(Queries per Second，QPS)。由于軟件產(chǎn)品的RPM可能會(huì)在每周、甚至是一天中的每一小時(shí)都有所不同，因此您需要靈活地調(diào)整自己的API，以適應(yīng)具體的峰谷值。

5、平均與最大延遲

在跟蹤客戶的體驗(yàn)時(shí)，API的延遲時(shí)間是一項(xiàng)非常重要的指標(biāo)。雖然前文提到的CPU使用率之類的基礎(chǔ)架構(gòu)級(jí)指標(biāo)的增加，可能并不會(huì)讓用戶及時(shí)感知到響應(yīng)能力的下降，但是API的延遲肯定會(huì)。有時(shí)候，單獨(dú)地跟蹤延遲可能無法使您完全理解它為什么會(huì)增加。因此，我們需要通過跟蹤API的各種變更，包括：新API版本的發(fā)布，新節(jié)點(diǎn)加入原有架構(gòu)等方面，來找出導(dǎo)致延遲增加的根本原因。

由于宏觀地檢查總體延遲，可能會(huì)忽略真正有問題的慢速節(jié)點(diǎn)，因此我們需要按照路由、地理位置、以及細(xì)分字段來進(jìn)行排查。例如：某個(gè)POST/checkout節(jié)點(diǎn)隨著時(shí)間的推移而延遲加劇，這很有可能是由于某個(gè)未被正確索引的SQL表在不斷增加所導(dǎo)致。但是，由于針對(duì)POST/checkout的調(diào)用數(shù)量非常少，因此該問題很容易被您的GET/items節(jié)點(diǎn)所掩蓋，畢竟該節(jié)點(diǎn)的調(diào)用量遠(yuǎn)遠(yuǎn)超過了checkout節(jié)點(diǎn)。同理，如果您有用到GraphQL API，那么就需要查看每個(gè)GraphQL操作的平均延遲。

盡管許多開發(fā)與架構(gòu)人員也會(huì)關(guān)注延遲問題，但是他們主要是通過檢查一組VM的總體延遲，來確保VM不會(huì)過載，而不會(huì)深入地研究諸如每條路由等，針對(duì)應(yīng)用程序的特定指標(biāo)。因此，我們認(rèn)為應(yīng)用程序與工程人員更需要關(guān)注延遲的相關(guān)問題。

6、每分鐘錯(cuò)誤率

與RPM相似，“每分鐘錯(cuò)誤”(或簡稱錯(cuò)誤率)是指每分鐘產(chǎn)生的帶有非200系列代碼的API調(diào)用數(shù)量。通過衡量API的錯(cuò)誤率、以及易錯(cuò)性，我們可以進(jìn)一步了解正在發(fā)生的錯(cuò)誤類型。例如：500系列錯(cuò)誤意味著您的代碼存在著問題，而400系列錯(cuò)誤則意味著不當(dāng)?shù)腁PI設(shè)計(jì)和文檔?？梢?，我們?cè)谠O(shè)計(jì)API時(shí)，使用適當(dāng)?shù)腍TTP狀態(tài)代碼是非常重要的，具體請(qǐng)參見：https://www.restapitutorial.com/httpstatuscodes.html。

API產(chǎn)品指標(biāo)

值得注意的是，我們?cè)诖怂懻摰腁PI，不僅僅是指與微服務(wù)和SOA相關(guān)的應(yīng)用接口，也包括那些獨(dú)立的產(chǎn)品。此類產(chǎn)品正在變得越來越普遍，尤其在與新的合作伙伴開辟調(diào)用通道的時(shí)候。

那些以API為產(chǎn)品驅(qū)動(dòng)的團(tuán)隊(duì)，既需要檢查諸如錯(cuò)誤和延遲之類的指標(biāo)，也需要了解API的使用方式，包括為何無法實(shí)現(xiàn)其預(yù)定的效果等方面。

7、API使用量的增長

對(duì)于許多產(chǎn)品經(jīng)理來說，API的使用率是一項(xiàng)黃金標(biāo)準(zhǔn)，可以衡量API作為產(chǎn)品的轉(zhuǎn)換效果。一個(gè)好的API產(chǎn)品不僅應(yīng)該沒有缺陷，而且有著與日俱增的實(shí)際使用量。通常情況下，我們可以月為單位衡量API使用量的增長。

8、API專門使用者

當(dāng)然，一個(gè)月內(nèi)某個(gè)API使用的增加量可能僅來自于某一個(gè)用戶賬號(hào)，因此我們需要衡量API的月活用戶(Monthly Active Users，MAU)或是API的專門使用者(unique consumers)。此類指標(biāo)可以讓您獲悉用戶的“拉新”和使用量增長的整體狀況。同時(shí)，許多API平臺(tái)團(tuán)隊(duì)也會(huì)將API的MAU與其網(wǎng)站的MAU相關(guān)聯(lián)，以獲取完整的產(chǎn)品態(tài)勢。

9、使用API的頭部用戶

對(duì)于一些專注于B2B業(yè)務(wù)的公司而言，了解自己的API產(chǎn)品有哪些頭部用戶是非常必要的。這些少數(shù)頭部用戶通常會(huì)為您的公司帶來更多的收入和轉(zhuǎn)發(fā)推薦，因此您可以據(jù)此來調(diào)用對(duì)應(yīng)的節(jié)點(diǎn)，并對(duì)它們采取進(jìn)一步的細(xì)分，以獲悉其使用特定節(jié)點(diǎn)的頻率，和使用時(shí)的體驗(yàn)。

10、API的使用與留存

您也許正在疑惑到底是應(yīng)該在產(chǎn)品和工程上投入更多，還是在增長上燒錢?光看用戶的留存與流失是無法給出清晰的參考依據(jù)。畢竟有些用戶雖然覺得您的API不夠友好，但是迫于已經(jīng)訂閱的年度合同，而無法馬上退訂，但是他們并不會(huì)積極地使用您所提供的API​​。因此，我們需要跟蹤的是API作為一種產(chǎn)品，在用戶側(cè)的實(shí)際使用情況。

11、首次進(jìn)入時(shí)間(TTFHW)

作為一項(xiàng)重要的KPI，首次進(jìn)入時(shí)間(Time to First Hello World，TTFHW)，不僅可以跟蹤API產(chǎn)品的運(yùn)行狀況，而且可以跟蹤開發(fā)者的總體體驗(yàn)(developer experience，DX)。

如果您的API是一個(gè)吸引第三方開發(fā)人員和合作伙伴來使用的開放平臺(tái)，那么您需要確保他們?cè)谑状握{(diào)用時(shí)，就能夠順利流暢運(yùn)用您提供的API來開發(fā)應(yīng)用。TTFHW主要衡量的是：從首次訪問目標(biāo)網(wǎng)頁到通過您的API平臺(tái)進(jìn)行首次事務(wù)的MVP集成時(shí)間。該指標(biāo)不但適用于API本身，也能考察您的營銷效果、以及配套的文檔和教程。

12、每種業(yè)務(wù)交易的API調(diào)用

盡管一般而言，各種產(chǎn)品和業(yè)務(wù)的指標(biāo)往往是多多益善的，但每一種業(yè)務(wù)交易的調(diào)用次數(shù)卻是越少越好。該指標(biāo)直接反映了API的設(shè)計(jì)水平。如果新的用戶需要通過三次不同的調(diào)用，才能將數(shù)據(jù)組合到一起的話，那么這可能意味著該API沒有找到正確的節(jié)點(diǎn)。因此在設(shè)計(jì)API時(shí)，我們應(yīng)當(dāng)考慮到業(yè)務(wù)交易本身、以及用戶想要達(dá)到的目標(biāo)，而不僅僅是能夠提供的功能和涉及到的節(jié)點(diǎn)。此外，您還可能需要對(duì)API采取靈活的過濾和分頁操作，具體請(qǐng)參見：https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/?utm_source=dzone&utm_medium=paid&utm_campaign=placed%20article&utm_term=13%20api%20metrics。

13、SDK和版本的采用

許多API平臺(tái)團(tuán)隊(duì)還可能需要維護(hù)大量的SDK和集成。與僅以iOS和Android為核心的移動(dòng)端不同，您的平臺(tái)上可能擁有十來個(gè)、甚至上百個(gè)SDK。因此，對(duì)它們進(jìn)行持續(xù)維護(hù)往往既費(fèi)時(shí)又費(fèi)力。那么，您可以選擇性地將一些關(guān)鍵性的功能部署到那些最受歡迎的SDK之中。同時(shí)，在棄用某些節(jié)點(diǎn)和功能時(shí)，您也需要詢問那些頭部用戶的意見，以做出對(duì)于API或SDK的取舍，以及版本的權(quán)衡。

結(jié)論

對(duì)于任何從事API構(gòu)建和使用​​的人員來說，跟蹤正確的API指標(biāo)是至關(guān)重要的。不同的團(tuán)隊(duì)成員對(duì)于不同的API指標(biāo)有著不同的關(guān)注點(diǎn)，也更能夠從自身專業(yè)的角度解決當(dāng)前和潛在的性能問題。希望上述討論能夠給您和您的團(tuán)隊(duì)提供一定的幫助。

原文標(biāo)題：13 API Metrics That Every Platform Team Should Be Tracking，作者：Derric Gilling

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】