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

如下圖所示，為了共用一個穩定高效的網路處理功能，把所有服務寫在一個程序裡。

接下來悲劇一幕幕就要上演了，如果各個模組是多人協作開發，網路庫的作者得想辦法設計個外掛機制供各個應用掛載，開發時無論是人員或者程式碼都耦合非常嚴重，大大影響協作、開發效率，後期要增減一個應用也得大動手腳。好吧，這還可以忍受，問題是寫應用的人技術水準還可能層次不齊，一個短板就可能造成整個服務崩潰。

彼此的依賴太嚴重，效率低下，責任推諉讓各個協作者們苦不堪言，各個應用服務的作者決定在自己的服務裡單獨提供網路模組。就有了如下圖的情況，每個應用服務的提供者自己還要提供網路功能模組

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

通過對上面兩種設計的批判，大家是不是會想，這架構缺陷很明顯，肯定採用的人很少吧，但是說實在的我已經遇到多次這種設計了，也許是觀點不同吧，我對以上兩種設計在上述場景下持否定態度。

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

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

可以看到都會有個接入服務，然後把不同的請求分發給不同的應用服務。其實這個接入服務就是“閘道器服務”，這種設計在nginx的負載均衡和反向代理功能中都有體現，另外在網遊伺服器中也大量採用了這種設計思路，由閘道器伺服器將不同的請求分發到不同的應用服務上，等應用伺服器處理完後再通過閘道器伺服器轉發給客戶。

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

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

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

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

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

3. 有應用叢集的情況下，可以通過閘道器伺服器做負載均衡，把請求分發在負載低的伺服器上。

再引用一個遊戲公司對閘道器伺服器的評價：

伺服器架構

採用帶閘道器的伺服器架構，將客戶端與遊戲伺服器隔離，相比傳統的客戶端-服務端直連的架構有如下優勢：

（1）作為網路通訊的中轉站，負責維護將內網和外網隔離開，使外部無法直接訪問內部伺服器，保障內網伺服器的安全，一定程度上減少外掛的攻擊。

（2）閘道器伺服器負責解析資料包、加解密、超時處理和一定邏輯處理，這樣可以提前過濾掉錯誤包和非法資料包。

（3）客戶端程式只需建立與閘道器伺服器的連線即可進入遊戲，無需與其它遊戲伺服器同時建立多條連線，節省了客戶端和伺服器程式的網路資源開銷。

服務端高度模組化

大廳服務端將登入、使用者資訊、房間資訊、日常任務、道具、銀行、比賽、排行、活動、網站等11個功能拆分成11個獨立的服務端子模組，模組之間不會相互影響，即使某模組出錯也不會影響全域性，提高了服務端的穩定性；與子模組平行的新功能可以自由新增掛載，擴充套件性強。