服務端架構中的「網關服務器」

這麼一個場景：一個要承載高併發、具備高性能的後臺服務，每每會有多個不一樣的應用服務。問題來了，你會怎樣設計架構呢？

以下圖所示，爲了共用一個穩定高效的網絡處理功能，把全部服務寫在一個進程裏。

接下來悲劇一幕幕就要上演了，若是各個模塊是多人協做開發，網絡庫的做者得想辦法設計個插件機制供各個應用掛載，開發時不管是人員或者代碼都耦合很是嚴重，大大影響協做、開發效率，後期要增減一個應用也得大動手腳。好吧，這還能夠忍受，問題是寫應用的人技術水準還可能層次不齊，一個短板就可能形成整個服務崩潰。

彼此的依賴太嚴重，效率低下，責任推諉讓各個協做者們苦不堪言，各個應用服務的做者決定在本身的服務裏單獨提供網絡模塊。就有了以下圖的狀況，每一個應用服務的提供者本身還要提供網絡功能模塊

接下來悲劇又一幕幕上演了，要知道高性能網絡服務模塊須要的技術含量之高不是人人均可以寫好的，即便咱都能寫好或者統一使用了一個牛X的網絡庫，你對客戶端暴露那麼多服務地址不討人嫌嘛，甚至在我身邊還有采用專門寫一個集中服務來供客戶端獲取各應用服務的地址的設計......。

經過對上面兩種設計的批判，你們是否是會想，這架構缺陷很明顯，確定採用的人不多吧，可是說實在的我已經遇到屢次這種設計了，也許是觀點不一樣吧，我對以上兩種設計在上述場景下持否認態度。

那咱們應該採用怎樣的設計適應這種場景呢？

以下圖，這是騰訊和微信的部分後臺設計架構圖

能夠看到都會有個接入服務，而後把不一樣的請求分發給不一樣的應用服務。其實這個接入服務就是「網關服務」，這種設計在nginx的負載均衡和反向代理功能中都有體現，另外在網遊服務器中也大量採用了這種設計思路，由網關服務器將不一樣的請求分發到不一樣的應用服務上，等應用服務器處理完後再經過網關服務器轉發給客戶。

那這種設計的優勢在哪呢？

借用知乎王明雨知友的一個比喻：

把服務器想象成飯店，沒有網關服務器的狀況，就如同每個廚師服務一桌顧客，從點菜開始到炒菜到上菜到收銀，有n個廚師就只能服務n桌顧客。有了網關服務器的話，網關服務器就成了強大的服務員，把招呼，點菜、上菜和收銀的活都作了，廚師只須要專心炒菜就行。這樣飯店的效率就大大提升了。

1. 這樣能夠把要承載高併發，高性能任務的網絡服務獨立出來專門作好，作強（對於http協議的場景，能夠直接用nginx作網關服務器）。這樣各個應用只需把重點放在對業務邏輯的處理便可。從技術架構和項目協做上都作到了解耦。

2. 加強了系統的健壯性，一個應用出現故障並不會對其餘應用產生影響。後期運維也好作灰度更迭。

3. 有應用集羣的狀況下，能夠經過網關服務器作負載均衡，把請求分發在負載低的服務器上。

再引用一個遊戲公司對網關服務器的評價：

服務器架構

採用帶網關的服務器架構，將客戶端與遊戲服務器隔離，相比傳統的客戶端-服務端直連的架構有以下優點：

（1）做爲網絡通訊的中轉站，負責維護將內網和外網隔離開，使外部沒法直接訪問內部服務器，保障內網服務器的安全，必定程度上減小外掛的***。

（2）網關服務器負責解析數據包、加解密、超時處理和必定邏輯處理，這樣能夠提早過濾掉錯誤包和非法數據包。

（3）客戶端程序只需創建與網關服務器的鏈接便可進入遊戲，無需與其它遊戲服務器同時創建多條鏈接，節省了客戶端和服務器程序的網絡資源開銷。

服務端高度模塊化

大廳服務端將登陸、用戶信息、房間信息、平常任務、道具、銀行、比賽、排行、活動、網站等11個功能拆分紅11個獨立的服務端子模塊，模塊之間不會相互影響，即便某模塊出錯也不會影響全局，提升了服務端的穩定性；與子模塊平行的新功能能夠自由新增掛載，擴展性強。