為了編寫基于cellnet的新一代游戲服務器框架，最近深入研究微服務，ServiceMesh等概念。研究過程中對Web和游戲兩種服務器架構設計有一些心得，編寫并記錄下來。(下文中，Game表示游戲服務器，Web表示Web服務器) ``
狀態緩存
所謂狀態緩存，就是在內存而非專業數據緩存服務器（如redis）中保存和處理邏輯數據，手動編寫此過程較為繁瑣但是效率較高，但隨著狀態邏輯復雜性和并發、擴容問題提出，狀態同步會變得越來越復雜。
Game:
強交互性的服務器類型需要在服務器做緩存，邏輯編寫也較為容易，無需處理事務并發問題。例如：組隊，匹配，戰斗邏輯。服務器不能隨意重啟。
弱交互性的服務器類型可配合redis做成無狀態服務器，例如：養成，技能升級，領取物品等。服務器隨時支持重啟。
游戲服務器為了提高性能，早期所有服務器都是使用狀態緩存寫法編寫，特別是MMORPG這類強交互的游戲服務器尤為嚴重。
Web:
均為無狀態服務器，弱交互。使用事務方式處理并發邏輯，例如：交易，下單等。
推送，單獨發送
這里提到的所謂推送，單獨發送是與RPC區別的通訊方法。RPC要求請求必須有回應。而推送單獨發送則更像是通知和廣播，無需目的方返回任何消息。
Game:
找到服務器的Session，直接Send
通過中轉服務器，或稱為中心服務器進行注冊/廣播
客戶端的model數據需要更新時，服務器會主動推送消息。
游戲服務器沒有嚴格的RPC設計需求，推送和單獨發送較Web服務器更多。而且游戲服務器多使用長連接，所以主動推送也比Web服務器來的方便一些。
Web:
將推送做成專有的服務，并做排隊和并發處理。
可用性
聽說過游戲停服更新，支付寶服務器在刷二維碼時停服了可一定被罵慘吧。Web對服務器高可用性要求很高，游戲雖然也注重服務器穩定性和可用性，但是由于版本迭代更新頻繁，停服更新反而能獲得玩家接受。
Game:
游戲對可用性要求不高。
游戲大版本更新時需要停服更新。支持熱更新技術的服務器（例如Erlang，Skynet）僅使用熱更新修復bug，很少直接更新新版本。
不是所有的游戲服務器支持動態添加服務器。
Web:
極高的可用性，服務不允許停服更新，使用藍綠及灰度方式更新服務器。
隨時可以橫向擴展服務器，提高服務器容量和承載。
連接及傳輸
均使用TCP傳輸協議，游戲服務器注重性能，自有協議及二進制協議使用較多。
Web注重兼容和接口友好，使用JSON格式較多。
Game:
使用長連接，需要從邏輯層維護連接狀態及處理服務器不在線情況
使用自有封包格式，大部分使用protobuf或二進制流格式。
Web:
微服務大部分使用短連接，grpc支持http2長連接
使用json編碼方便調試和版本兼容。
流量限制
人數多了，任何服務器都扛不住，流量限制和登入限制能有效保護服務器穩定。
Game:
單服有人數限制，可以通過GM后臺設置擋墻，超過無法進入
Web:
限流器中間件，可以精確到服務控制流量
斷流，防止雪崩
Game:
游戲沒有，也不需要這種概念，游戲請求不會突然升高，即便有，也通過GM后臺人為控制
Web:
斷流器中間件
服務發現
如何找到服務器地址。
服務有變化時，通過Watch系統通知訂閱者更新本地緩存
服務器沒有變化時，使用本地緩存找到服務地址
Game:
游戲服務器互相依賴復用只在很小的范圍內，因此無需在不同語言不同進程服務間獲得地址，大部分在配置文件中填寫各服務的IP及地址即可互相訪問。
早期游戲自己編寫服務器狀態及地址發現服務。
有用redis做服務發現
Web:
使用服務發現系統，分布式部署。無需依賴配置文件
網關需求
Game:
網關處理客戶端上下線通知，心跳，維持連接，轉發，廣播上下行封包
Web:
根據請求地址路由，無上下線概念，無心跳。廣播通過消息推送系統完成
由于筆者從事游戲行業，對Web服務器概念在逐漸熟悉中，若有錯誤和不足請各位大佬指出。
本人新書《Go語言從入門到進階實戰》，生動的語言，例子帶有各種彩蛋，輕松了解Go語言特性，更有cellnet框架剖析解密