為啥王者榮耀為什麼不使用微服務架構？

最近，在知乎上看到這樣一個問題：

"為什麼遊戲公司的server不願意微服務化？"

背景介紹

最近面試了一家遊戲公司（滿大間的，有上市）

我問他，公司有沒有做微服務架構的打算及考量？

他很驚訝的說，我沒聽說過微服務耶，你可以解釋一下嗎？

我大概說了，友善測試，友善維護，友善更新，服務之間松耦合，可多語言開發，自動擴容…之類的點。

然後他說遊戲server不太需要微服務，因為要求real time，做微服務會影響效能，分模組來開發就好了。

我也不确定，但微服務不是趨勢嗎？特别是大公司，遊戲server的服務應該很容易拆分吧？。

[hongjic93] 是這樣回答的：

比如moba類遊戲，就看LOL的用戶端吧，想象一下。

賬号系統，符文系統，英雄系統，皮膚系統，好友系統，好友之間messaging，這些都是正常操作，如果流量足夠大，當然可以用微服務的架構去做。

不過這不是這個遊戲的核心，核心是MOBA：Multiplayer online battle arena。特性是什麼？

10個人之間各種遊戲事件的高速多向通訊streaming/broadcast/multicast/pubsub各種通訊模式

是以遊戲的核心在于小規模群體之間的高速網絡通信。就是對方說的realtime。多了一個10ms的延遲玩家就要生氣了。

• 微服務為了把業務完美拆解，把原來的同一個程序裡的子產品拆分成不同的服務，顯著增加額外的網絡開銷。更别說什麼service mesh，各種gateway，proxy，sidecar，簡直就是擔心延遲太低。

• 微服務基本隻有request/response的模式。做不了streaming？微服務通常要求應用是無狀态的才能做到水準擴充。streaming本身就是加入了狀态

• 我可以想象，為了提高通訊的性能，一場英雄聯盟遊戲很可能會使用同一個伺服器負責這10個玩家之間的通訊，這樣就使得資料可以在本地交換，性能最大化。這對用戶端或者說服務端統一網關的要求是必須支援sticky routing。假設用戶端連接配接斷了，接下來的必須重連之前的同一個伺服器。微服務的stateless，水瓶擴充要求本身就是反sticky routing的，因為sticky routing本身就是狀态。

• 對服務端叢集來說，同時有無數個LOL比賽在進行，每個都可以看成一個沙盒，每個沙盒都處于一個不同的狀态：塔被推了幾個了，你被殺了幾次了，對面幾個超神了，20分鐘到了沒。這些都是長時間存在的狀态，直到遊戲結束，服務端才可以清理一場遊戲的狀态。是以雖然不用把這些狀态寫進持久性存儲，但是必然會在記憶體中存在很長時間。都是狀态，反正有狀态，就别想用微服務。除非你說把這些狀态都移到redis裡去，那麼在伺服器在資訊流傳輸到一半還要做一個remote request，一來一回，延遲就上升了。總之怎樣都不好。（比如想象對方在A你的水晶，每一次A的操作都是一個event，被streaming到服務端的沙盒中，沙盒中有一個流處理器，每次接收到一個你水晶被A的event都會計算一下你水晶爆了沒。這個計算需要極快，你是不可能把你水晶生命值的資料存在遠端的）

像這類遊戲，都是對網絡，記憶體，CPU的優化需求很高，整個遊戲進行過程中，幾乎不存在什麼RPC call，真的需要remote data，也應該是prefetch，就是在遊戲剛開始的時候加載好

微服務不是什麼銀彈，也就是友善拆解一下原來的CRUD應用罷了而已，一沒觸及進階的互動方式，二沒觸及分布式系統真正的難點：狀态，其實沒有大家想的那麼有用。之是以感覺上好像微服務改變了網際網路，隻不過90%的網際網路應用都隻是簡單小規模的CRUD而已。

對方沒有聽說過微服務完全沒有問題，因為這本身就不是什麼高深的概念，反而對方聽你一說一下就知道微服務不适合遊戲，說明對方了解能力很強，對遊戲系統設計也了解足夠深。

（雖然我沒的确沒寫過遊戲，以上僅供參考）

[放浪者] 是這樣回答的：

……有些國民級moba遊戲的微服務化過程，可能有保密問題，我就不談了。

拿中年人喜聞樂見的WOW來說，你們不知道有專門的排隊伺服器、場景伺服器、副本伺服器麼這些麼？你以為每次切換場景時的loading界面在做啥？就是完成service的切換啊。

你非要用web那一套來套在遊戲上面，那當然不行，那說明你對microservice的了解太狹隘了。microservice重點是業務邏輯的拆分和獨立，難道你以為這麼多mmorpg，是一個巨大無比的monolithic的應用在跑？怎麼可能。

多人遊戲和網際網路app相比，最大的差别不是microservice還是monolithic，也不是啥實時還是非實時，而是stateful和stateless的差别。網際網路app大量的工作是在資料讀寫上，為了能瘋狂scale，service本身一般是stateless的，最簡單的一個例子就是web server的session概念（現在比較過時了，但是是個很好的例子），既可以本地，也可以存入redis或者db。遊戲的server其實也是儲存這樣一個目前場景涵蓋所有人的巨大session（比如副本，比如moba中的遊戲全局狀态）。由于遊戲過程本身并沒有什麼儲存價值，是以對這些實時進行的遊戲狀态進行持久化沒啥意義，是以才有專門的對戰伺服器等等。

其實你把什麼對戰伺服器、排隊伺服器、比對伺服器等等都叫做xx service，就會發現其實就是微服務概念。

補充一點個人不保證正确的私貨：其實整個遊戲開發行業和網際網路行業的技術思維差異就在于stateful vs stateless，做習慣了遊戲開發的人（無論用戶端還是backend），習慣了直接在記憶體讀寫資料，不習慣從遠端讀寫（無論是redis還是db或者nosql或者啥），換句話說他們不太習慣原始資料不在本地機器上，而恰恰業務邏輯和資料分離是網際網路架構的重要指導思想。這使得遊戲開發程式員的技術思維很有些不一樣，我不能說不好，但是确實有點技能點的配置不同的感覺，這當實作非遊戲項目的時候是有障礙的。

[brice] 是這樣回答的：

做過棋牌遊戲（遊戲最簡單的一種），可以嘗試說幾個點：

1、微服務本身是為了應對業務邏輯的複雜，需要要的新的組織接口的方式。遊戲本身邏輯其實沒有這麼複雜，比如大廳就是一些基本功能，修改帳号，登入等。遊戲本身就是遊戲本身的邏輯。

2、遊戲邏輯伺服器本身（比如鬥地主等棋牌）因為網絡響應性能要求問題（玩家對每個操作的回報時長敏感度遠高于業務系統），是以遊戲伺服器都是有狀态的，狀态就存在記憶體，偶爾會接受redis，mysql等是絕對不可以的接受的，關系行資料庫僅用來定時異步持久化資料，僅遊戲伺服器而言持久化在redis即可。

3、遊戲伺服器一般純需要主動推送，是以第一代微服務網關就沒辦法滿足需求， tcp的沒有網關用，spring cloud gateway的web socket也許可以用（但是從防攻擊角度講端遊用TCP絕對比web socket合理）。

4、服務間通信rpc首先ribbon,feign等并不是合适，因為都是基于http的，用Http存在一個消息亂序問題，比如玩家出牌兩次，在http就可能出現次序不一緻。遊戲伺服器叢集一般使用長連接配接互聯。可能需要用dubbo?(聽說是長連接配接)

5、遊戲邏輯伺服器（比如鬥地主伺服器），一般是不能用spring mvc做的，因為線程模型完全不同。多線程模型處理遊戲性能差還非常複雜，一般都是使用單程序/線程 驅動固定數量房間的方式（這也是為何伺服器一定有狀态，一定不能直接讀寫mysql）。一般就直接netty了

6、自動擴容在遊戲這邊叫做開服，早就有固定流程和工具和限流方式了

7、遊戲很多操作不存在服務降級熔斷，不行就要直接報錯給使用者。

8、大廳伺服器登入注冊等的确可以做微服務，但是其實也不是做微服務，就是幾個接口有自動水準擴容的方案即可。服務注冊發現用處不大，開服都是确定的事情，還有一系列營運手段配合，關服也是絕對不能随便關的。

9、遊戲處理的流量真的不算多，你線上1萬的棋牌遊戲已經很賺錢了，10W就是個特别厲害的産品了。

10、一些獨立的伺服器比如充值之類的需要微服務化麼?隻能說這種伺服器都需要微服務處理了，項目組做夢都能笑醒。

雖然上面說了很多點，但是其實也是可以考慮用spring cloud改造的，因為遊戲叢集一樣有注冊中心，需要服務發現，需要編排啟動順序，隻是spring cloud沒有為了遊戲設計而已，比如至少要完全支援 webflux吧，需要一個單線程的長連接配接最好支援protobuf rpc架構吧（內建服務發現相關功能與接口），網關支援tcp或者至少封裝或者暴露一些netty的decoder encoder（或者允許注入）等等。

大家對于"為什麼遊戲公司的server不願意微服務化？"這一問題，有怎樣的思考和想法呢？歡迎在留言區交流~

整理丨不才陳某（ID：oneswholife）

來源丨網址：zhihu.com/question/359630395/answer/954452799

dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]

活動推薦

第八屆DAMS-中國資料智能管理峰會将于2023年3月31日在上海舉辦，與大家一起探索大資料與雲原生強強聯合的方式、挖掘由此激發的軟體發展和技術進步。

報名連結：2023年DAMS中國資料智能管理峰會-上海站 - 百格活動

演講嘉賓所在機關：阿裡、騰訊、京東、美團、華為雲、位元組、螞蟻、網易、新浪、攜程、哔哩哔哩、小紅書、vivo、快狗打車、貨拉拉、工商銀行、建設銀行、中國銀行、平安銀行、光大銀行、彙豐銀行、微衆銀行、複旦大學等産學研界技術領跑機關。

演講議題聚焦：

• 大資料&資料資産管理：資料治理丨存算分離丨雲原生OLAP丨湖倉一體丨智能分析
• 資料庫：雲原生分布式丨時間序列丨服務自治丨中間件丨跨雲多活
• 運維：AIOps丨故障分析丨性能優化丨離線上混部丨高可用建設
• 金融科技：規模化監控丨實時數倉丨分布式改造丨國産化替代丨數字化轉型丨混沌工程