后臺(tái)開發(fā)小白必學(xué)服務(wù)器框架——UDPServer

畢業(yè)后加入了一家大型的互聯(lián)網(wǎng)公司的音視頻產(chǎn)品部門做后臺(tái)開發(fā)，其實(shí)我本身是學(xué)習(xí)自動(dòng)化的，研究生的方向嵌入式系統(tǒng)，對(duì)互聯(lián)網(wǎng)可是一知半解，因此能進(jìn)入這樣一個(gè)大公司還是很幸運(yùn)的。

剛開始工作的半年應(yīng)該是在上份工作最快樂的時(shí)光，那時(shí)候我們十來個(gè)人被抽調(diào)出來做好友系統(tǒng)，由Z組長(zhǎng)負(fù)責(zé)。從產(chǎn)品到開發(fā)，大部分都是新入職員工，pm給畫了一個(gè)大餅，大家都滿懷憧憬。閑話少說，先介紹一下剛開始接觸后臺(tái)開發(fā)用到的服務(wù)器框架。

第一個(gè)接觸的叫udpserver。顧名思義，就是只支持udp的服務(wù)框架。因?yàn)槲覀儾块T是做音視頻產(chǎn)品的，音視頻數(shù)據(jù)對(duì)實(shí)時(shí)性要求很高，因此常用udp傳輸數(shù)據(jù)。Udp server是同步多進(jìn)程模型，包含1個(gè)Interface進(jìn)程和多個(gè)Worker進(jìn)程。

Iterface進(jìn)程負(fù)責(zé)接收來自外部的請(qǐng)求，做一些合法性校驗(yàn)和格式轉(zhuǎn)換后，轉(zhuǎn)發(fā)給后端的Worker進(jìn)程。Worker進(jìn)程監(jiān)聽不同的端口收包，并處理業(yè)務(wù)邏輯。Worker進(jìn)程的回包直接發(fā)給客戶端。

此處有幾個(gè)點(diǎn)值得關(guān)注：

首先，Worker進(jìn)程監(jiān)聽的是不同端口。

監(jiān)聽相同的端口顯然是更常見的做法，而監(jiān)聽相同的端口也需要注意一點(diǎn)，即監(jiān)聽的端口socket必須是從父進(jìn)程中繼承得到的，而非Worker自己創(chuàng)建的socket。因?yàn)閷?duì)于前者內(nèi)核才能保證調(diào)度的均勻性，而后者是沒有這種效果的，內(nèi)核只會(huì)把請(qǐng)求包扔給同一個(gè)Worker。

這里之所以使用監(jiān)聽不同端口的方案，是為了保證調(diào)度的可控性，請(qǐng)求包發(fā)往哪個(gè)Worker是有預(yù)期的，可以做更個(gè)性化的調(diào)度策略，問題定位也方便得多。Udp server默認(rèn)是使用輪詢的調(diào)度方式。

第二點(diǎn)是，Worker進(jìn)程回包是直接返回給客戶端的。

另一種常見做法是通過Interface進(jìn)程回包，缺點(diǎn)是Interface會(huì)成為瓶頸。而Worker直接回包的缺點(diǎn)是向外部暴露Worker，不過這個(gè)問題并不十分嚴(yán)重。相較之下，我們更希望獲得性能的提升。為了給客戶端回包，Interface會(huì)把客戶端的ip和端口封裝到請(qǐng)求包發(fā)給Worker。

框架雖簡(jiǎn)單，但是性能非常優(yōu)異，作為echosvr性能可達(dá)30w+ QPS。但是這個(gè)框架不支持TCP，因此只能作為內(nèi)部的服務(wù)框架使用。

因?yàn)楹芫脹]用這個(gè)框架了，以上所述可能有不準(zhǔn)確或者不充分的地方，望不吝賜教。