後臺開發小白必學服務器框架——UDPServer

畢業後加入了一家大型的互聯網公司的音視頻產品部門作後臺開發，其實我自己是學習自動化的，研究生的方向嵌入式系統，對互聯網但是隻知其一;不知其二，所以能進入這樣一個大公司仍是很幸運的。

剛開始工做的半年應該是在上份工做最快樂的時光，那時候咱們十來我的被抽調出來作好友系統，由Z組長負責。從產品到開發，大部分都是新入職員工，pm給畫了一個大餅，你們都滿懷憧憬。閒話少說，先介紹一下剛開始接觸後臺開發用到的服務器框架。

第一個接觸的叫udpserver。顧名思義，就是隻支持udp的服務框架。由於咱們部門是作音視頻產品的，音視頻數據對實時性要求很高，所以經常使用udp傳輸數據。Udp server是同步多進程模型，包含1個Interface進程和多個Worker進程。

 

Iterface進程負責接收來自外部的請求，作一些合法性校驗和格式轉換後，轉發給後端的Worker進程。Worker進程監聽不一樣的端口收包，並處理業務邏輯。Worker進程的回包直接發給客戶端。

此處有幾個點值得關注：

首先，Worker進程監聽的是不一樣端口。

監聽相同的端口顯然是更常見的作法，而監聽相同的端口也須要注意一點，即監聽的端口socket必須是從父進程中繼承獲得的，而非Worker本身建立的socket。由於對於前者內核才能保證調度的均勻性，然後者是沒有這種效果的，內核只會把請求包扔給同一個Worker。

這裏之因此使用監聽不一樣端口的方案，是爲了保證調度的可控性，請求包發往哪一個Worker是有預期的，能夠作更個性化的調度策略，問題定位也方便得多。Udp server默認是使用輪詢的調度方式。

第二點是，Worker進程回包是直接返回給客戶端的。

另外一種常見作法是經過Interface進程回包，缺點是Interface會成爲瓶頸。而Worker直接回包的缺點是向外部暴露Worker，不過這個問題並不十分嚴重。相較之下，咱們更但願得到性能的提高。爲了給客戶端回包，Interface會把客戶端的ip和端口封裝到請求包發給Worker。

框架雖簡單，可是性能很是優異，做爲echosvr性能可達30w+ QPS。可是這個框架不支持TCP，所以只能做爲內部的服務框架使用。

由於好久沒用這個框架了，以上所述可能有不許確或者不充分的地方，望不吝賜教。