你的接口多少Q(mào)PS？

我是3y，一年CRUD經(jīng)驗(yàn)用十年的markdown程序員???????常年被譽(yù)為職業(yè)八股文選手

前陣子被股東們問到了消息推送平臺Austin接口性能相關(guān)的問題，本來想著早早就可以安排一波文章的。實(shí)在沒想到這兩周竟然在工作中出現(xiàn)了這么多線上的問題，熬了幾天夜，導(dǎo)致文章拖到了現(xiàn)在。

消息推送平臺提會(huì)供接口給業(yè)務(wù)方進(jìn)行調(diào)用，一般面試官看到了也會(huì)想問：「你這接口有多少的QPS？RT是多少？有壓測過嗎？業(yè)務(wù)增長，調(diào)用接口的量也在增長，這時(shí)候你會(huì)怎么辦？」

對于這個(gè)問題，我提供下思路哈，你們可以根據(jù)自身技術(shù)棧的情況做一些簡單修整。

聊些指標(biāo)和系統(tǒng)業(yè)務(wù)/架構(gòu)

我們的QPS和RT的指標(biāo)都來源于日志，我們在接口被調(diào)用時(shí)打印出了耗時(shí)（RT）以及記錄了一條日志（QPS）。有了這日志，我們通過GrayLog就能配置出QPS和RT的監(jiān)控了。所以，我們的接口對QPS和RT都是有監(jiān)控的哈

在接入層部署了4臺4C8G的機(jī)器，通過監(jiān)控可以看到，日常的QPS大概百級（200左右），大促時(shí)記錄的峰值是2000，RT大概在20ms。

發(fā)送接口是提供了單發(fā)和批量接口的。如果有批量推送消息的需求，我們這邊是建議業(yè)務(wù)走批量接口的，這樣就能一定程度上減少網(wǎng)絡(luò)的IO，我這邊所承接的QPS并不會(huì)太大。

但話又說回來，在接口層面的壓力并不大。回到我們的系統(tǒng)架構(gòu)上，我們有接入層->MQ->發(fā)送邏輯層，接入層做的工作僅僅是組裝參數(shù)，然后把消息發(fā)給MQ了。

至于壓測的話，我這邊沒有操作過，一般是提給測試去搞的，這塊我就不太清楚了。不過系統(tǒng)成型了以后，發(fā)送消息這種確實(shí)不太好壓，壓接入層并沒有什么太大的意義（只要MQ能頂?shù)米。墙尤雽泳筒皇菃栴}）。

發(fā)送消息的速率瓶頸一般在下游渠道側(cè)，我們調(diào)用短信/郵件等渠道都會(huì)限制速度，不同的渠道還不一樣。有大概幾個(gè)指標(biāo)：

• 騰訊云短信3000QPS（不過我們會(huì)負(fù)載到幾個(gè)短信渠道方）
• 騰訊企業(yè)郵箱大概只支持百級以下QPS（當(dāng)時(shí)調(diào)高了，就會(huì)限制發(fā)送失敗了，沒公布出具體的QPS）
• 個(gè)推PUSH我們按發(fā)送人數(shù)（8000人/QPS）進(jìn)行限制
• 而IM是我們自研的（通知類的都需要進(jìn)MySQL和過風(fēng)控），限制人數(shù)在600人/QPS
• ...

在消費(fèi)MQ的時(shí)候，我們是每個(gè)消息渠道的每種類型都會(huì)有對應(yīng)的線程池進(jìn)行消費(fèi)，而且這個(gè)是動(dòng)態(tài)的線程池（不用重啟發(fā)布就能調(diào)整線程池的參數(shù)）

隨著業(yè)務(wù)增長，當(dāng)QPS真的上來了（連接數(shù)變多），我們只要橫向擴(kuò)容就好了，對于接入層來說就是無狀態(tài)的。

總結(jié)

當(dāng)我們負(fù)責(zé)一個(gè)系統(tǒng)時(shí)，對外需要提供接口給業(yè)務(wù)方調(diào)用，我們是需要了解這個(gè)接口的指標(biāo)以及對應(yīng)的上下游。這樣在出現(xiàn)的問題的時(shí)候，就可以根據(jù)歷史的指標(biāo)去找問題，去找上下游提醒有什么風(fēng)險(xiǎn)。

面試官問到接口的性能/QPS或者壓測主要是想看你是不是真的了解你所負(fù)責(zé)的內(nèi)容，如果是搜索/推薦/流量的接口還比較好壓測，但發(fā)送消息/訂單/支付類似這類接口就不太好壓測了。

我們能表達(dá)出對接口的指標(biāo)以及相關(guān)業(yè)務(wù)的細(xì)節(jié)，那么一般面試官也不會(huì)糾著你啦（除非這個(gè)面試官也剛好做這塊業(yè)務(wù)）

還想了解Austin消息推送平臺什么面試問題？評論區(qū)告訴我吧！

最近我開通了股東服務(wù)，感興趣的可戳：我開通了付費(fèi)渠道

閱讀原文可跳轉(zhuǎn)至消息推送平臺倉庫