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

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

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

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

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

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

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

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

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

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

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

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

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

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

有應用集群的情況下，可以通過網關服務器做負載均衡，把請求分發在負載低的服務器上。

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

服務器架構

采用帶網關的服務器架構，將客戶端與游戲服務器隔離，相比傳統的客戶端-服務端直連的架構有如下優勢：

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

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

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

服務端高度模塊化

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

總結

以上是生活随笔為你收集整理的服务端架构中的“网关服务器”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。