今天,在知乎上看到這樣一個問題:"為什么游戲公司的server不愿意微服務化?"
背景介紹
最近面試了一家游戲公司(滿大間的,有上市)
我問他,公司有沒有做微服務架構的打算及考量?
他很驚訝的說,我沒聽說過微服務耶,你可以解釋一下嗎?
我大概說了,方便測試,方便維護,方便升級,服務之間松耦合,可多語言開發(fā),自動擴容…之類的點。
然后他說游戲server不太需要微服務,因為要求real time,做微服務會影響效能,分模組來開發(fā)就好了。
我也不確定,但微服務不是趨勢嗎?特別是大公司,游戲server的服務應該很容易拆分吧?。
hongjic93 是這樣回答的
比如moba類游戲/王者榮耀/LOL,就看王者榮耀的客戶端吧,想象一下。
賬號系統(tǒng),符文系統(tǒng),英雄系統(tǒng),皮膚系統(tǒng),好友系統(tǒng),好友之間messaging,這些都是常規(guī)操作,如果流量足夠大,當然可以用微服務的架構去做。
不過這不是這個游戲的核心,核心是MOBA:Multiplayer online battle arena。特性是什么?
10個人之間各種游戲事件的高速多向通訊 streaming/broadcast/multicast/pubsub各種通訊模式。
所以游戲的核心在于小規(guī)模群體之間的高速網(wǎng)絡通信。就是對方說的realtime。多了一個10ms的延遲玩家就要罵娘了。
1、微服務為了把業(yè)務完美拆解,把原來的同一個進程里的模塊拆分成不同的服務,顯著增加額外的網(wǎng)絡開銷。更別說什么service mesh,各種gateway,proxy,sidecar,簡直就是擔心延遲太低。
2、微服務基本只有request/response的模式。做不了streaming?微服務通常要求應用是無狀態(tài)的才能做到水平擴展。streaming本身就是加入了狀態(tài)
3、我可以想像,為了提高通訊的性能,一場英雄聯(lián)盟游戲很可能會使用同一個服務器負責這10個玩家之間的通訊,這樣就使得數(shù)據(jù)可以在本地交換,性能最大化。這對客戶端或者說服務端統(tǒng)一網(wǎng)關的要求是必須支持sticky routing。假設客戶端連接斷了,接下來的必須重連之前的同一個服務器。微服務的stateless,水瓶擴展要求本身就是反sticky routing的,因為sticky routing本身就是狀態(tài)。
4、對服務端集群來說,同時有無數(shù)個王者榮耀的比賽在進行,每個都可以看成一個沙盒,每個沙盒都處于一個不同的狀態(tài):塔被推了幾個了,你被殺了幾次了,對面幾個超神了,20分鐘到了沒。
這些都是長時間存在的狀態(tài),直到游戲結束,服務端才可以清理一場游戲的狀態(tài)。所以雖然不用把這些狀態(tài)寫進持久性存儲,但是必然會在內存中存在很長時間。
都是狀態(tài),反正有狀態(tài),就別想用微服務。除非你說把這些狀態(tài)都移到redis里去,那么在服務器在信息流傳輸?shù)揭话脒€要做一個remote request,一來一回,延遲就上升了。
總之怎樣都不好。(比如想象對方在A你的水晶,每一次A的操作都是一個event,被streaming到服務端的沙盒中,沙盒中有一個流處理器,每次接收到一個你水晶被A的event都會計算一下你水晶爆了沒。這個計算需要極快,你是不可能把你水晶生命值的數(shù)據(jù)存在遠端的)。
像這類游戲,都是對網(wǎng)絡,內存,CPU的優(yōu)化需求很高,整個游戲進行過程中,幾乎不存在什么RPC call,真的需要remote data,也應該是prefetch,就是在游戲剛開始的時候加載好。
微服務不是什么銀彈,也就是方便拆解一下原來的CRUD應用罷了而已,一沒觸及高級的交互方式,二沒觸及分布式系統(tǒng)真正的難點:狀態(tài),其實沒有大家想的那么有用。之所以感覺上好像微服務改變了互聯(lián)網(wǎng),只不過90%的互聯(lián)網(wǎng)應用都只是簡單小規(guī)模的CRUD而已。
對方?jīng)]有聽說過微服務完全沒有問題,因為這本身就不是什么高深的概念,反而對方聽你一說一下就知道微服務不適合游戲,說明對方理解能力很強,對游戲系統(tǒng)設計也了解足夠深。
brice 是這樣回答到
做過棋牌游戲(游戲最簡單的一種),可以嘗試說幾個點:
1、微服務本身是為了應對業(yè)務邏輯的復雜,需要要的新的組織接口的方式。游戲本身邏輯其實沒有這么復雜,比如大廳就是一些基本功能,修改帳號,登錄等。游戲本身就是游戲本身的邏輯。
2、游戲邏輯服務器本身(比如斗地主等棋牌)因為網(wǎng)絡響應性能要求問題(玩家對每個操作的反饋時長敏感度遠高于業(yè)務系統(tǒng)),所以游戲服務器都是有狀態(tài)的,狀態(tài)就存在內存,偶爾會接受redis,mysql等是絕對不可以的接受的,關系行數(shù)據(jù)庫僅用來定時異步持久化數(shù)據(jù),僅游戲服務器而言持久化在redis即可。
3、游戲服務器一般純需要主動推送,所以第一代微服務網(wǎng)關就沒辦法滿足需求, tcp的沒有網(wǎng)關用,spring cloud gateway的web socket也許可以用(但是從防攻擊角度講端游用TCP絕對比web socket合理)。
4、服務間通信rpc首先ribbon,feign等并不是合適,因為都是基于http的,用Http存在一個消息亂序問題,比如玩家出牌兩次,在http就可能出現(xiàn)次序不一致。游戲服務器集群一般使用長連接互聯(lián)。可能需要用dubbo?(聽說是長連接)
5、游戲邏輯服務器(比如斗地主服務器),一般是不能用spring mvc做的,因為線程模型完全不同。多線程模型處理游戲性能差還非常復雜,一般都是使用單進程/線程 驅動固定數(shù)量房間的方式(這也是為何服務器一定有狀態(tài),一定不能直接讀寫mysql)。一般就直接netty了
6、自動擴容在游戲這邊叫做開服,早就有固定流程和工具和限流方式了
7、游戲很多操作不存在服務降級熔斷,不行就要直接報錯給用戶。
8、大廳服務器登錄注冊等的確可以做微服務,但是其實也不是做微服務,就是幾個接口有自動水平擴容的方案即可。服務注冊發(fā)現(xiàn)用處不大,開服都是確定的事情,還有一系列運營手段配合,關服也是絕對不能隨便關的。
9、游戲處理的流量真的不算多,你在線1萬的棋牌游戲已經(jīng)很賺錢了,10W就是個特別厲害的產品了。
10、一些獨立的服務器比如充值之類的需要微服務化么?只能說這種服務器都需要微服務處理了,項目組做夢都能笑醒。
雖然上面說了很多點,但是其實也是可以考慮用spring cloud改造的,因為游戲集群一樣有注冊中心,需要服務發(fā)現(xiàn),需要編排啟動順序,只是spring cloud沒有為了游戲設計而已,比如至少要完全支持 webflux吧,需要一個單線程的長連接最好支持protobuf rpc框架吧(集成服務發(fā)現(xiàn)相關功能與接口),網(wǎng)關支持tcp或者至少封裝或者暴露一些netty的decoder encoder(或者允許注入)等等。
審核編輯 :李倩
-
服務器
+關注
關注
12文章
9129瀏覽量
85350 -
架構
+關注
關注
1文章
513瀏覽量
25468 -
微服務
+關注
關注
0文章
137瀏覽量
7341
原文標題:王者榮耀為什么不使用微服務架構?
文章出處:【微信號:AndroidPush,微信公眾號:Android編程精選】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論