網絡遊戲架構與微服務架構簡單對比

　　筆者十年前作過網絡遊戲，當第一次看到微服務架構就發現它和網絡遊戲架構很像，以下圖：

　　

　　先來簡單介紹一下這個網遊架構，有些東西記不清了，現在的網遊大牛看到可別丟磚頭。

       用戶下載網遊客戶端，登陸網遊，首先會執行登陸服務，登陸服務主要就是給你分配一個網關，由於網關後面鏈接的纔是真正的遊戲服務器。登陸後，進入遊戲，發出指令，好比你移動到某個位置，這個指令會先發送到網關，而後再由網關識別發送到「移動系統」服務，移動系統計算後再經由網關發送給玩家客戶端，玩家客戶端執行一個動畫讓你移動到某個位置。      

       假如子服務間要通訊也是經過網關轉發，好比任務系統裏面要購買物品，那麼任務系統發一個指令消息給網關，網關再轉發給物品系統等等。圖中的「遊戲A服務器集羣」，其中「遊戲A」表明你所屬的遊戲服務器，每一個遊戲服務器能承載的人數是有限的（當時的技術一個服務器組最多同時在線也就幾千人），人數滿了，你就要登陸到另外的服務器。「集羣」表示服務部署的集羣。每個明面上的遊戲服務器，對應一個N臺服務器構成的遊戲服務集羣，但只對應一個用戶數據庫，數據庫沒有使用集羣技術，由於你即便使用了數據庫集羣技術，在實時性方面也跟不上。

從編程上來說，包括如下應用：

       客戶端.exe

       網關.exe

       移動系統.exe

       聊天系統.exe

       ….

       說到這裏，瞭解微服務的人可能看出來了，上面的網關就比如nginx反向代理服務器，每個遊戲服務就比如微服務中的服務，若是你的微服務通訊協議使用的是TCP那後面服務部分基本就如出一轍了。網絡遊戲中數據訪問沒有分層直接放到業務處理模塊，在遊戲中每個遊戲執行邏輯不論是加載腳本、配置數據仍是帳戶數據都是在同一個邏輯中處理的，不會去劃分出什麼數據庫訪問層、腳本訪問層，這樣處理有一個很大的好處，那就是能夠處理複雜的邏輯，而又不用喪失效率。

       在網遊中，由於服務間通訊的是二進制消息，在編程時解析消息和組裝消息很是麻煩，所以須要設計一個統一的類庫，這個類庫把二進制消息傳遞直接變成面向對象調用。好比你調用了一個方法，其實就是向網關發送了一個二進制消息。這用在微服務這裏也是同樣的，讓接口的收發消息變成面向對象調用，能夠提升編程開發的效率，又能下降通訊所產生的bug，孢子框架中的接口訪問層也完成相似功能。

       至於說分佈式事務的問題，在網遊開發中比較容易就能夠解決（即便解決不了還有客服），由於全部事物相關數據都在一個數據庫，即便不在一個數據庫也是經過消息去同步。好比你砍了怪物一刀，你的等級數據上升、體力降低都在一個服務裏計算的，假如怪物被砍了一刀的計算不在這個服務裏，那麼會發一個消息給那個服務，那個服務計算怪物被砍了一刀，若是計算失敗，再回發一個消息給前一個服務來協同這方面，若是被砍死了掉物品了，就發一個消息給物品服務去計算，物品服務再回發消息與主計算協同。這其實就是經過消息機制進行事務協同最原始的版本。

       和微服務對比概括一下：

       遊戲（Gate網關）至關於：微服務（nginx或API Gateway）

       遊戲（個體服務）至關於：微服務（個體服務）

       遊戲（接口訪問層）至關於：孢子框架（接口訪問層）

       另外微服務中流行的分佈式事務解決方法也是經過消息來實現，好比支付，調用方調用支付接口失敗，發一個失敗消息給消息隊列，支付接口服務監聽消息隊列並處理支付失敗。

 

補充：少了場景服務，場景服務管理進入某地圖的全部資源，好比一我的要移動，計算完我的移動後，還要向地圖內（可視範圍內）全部人發送移動消息。