為什麼遊戲公司的伺服器不願意微服務化?

香港cn2發表於2022-07-18

賬號系統、符文系統、英雄系統、皮膚系統、好友系統、好友之間的交流,這些都是日常操作。 如果流量夠大,當然可以用

微服務架構來完成。


但這不是這款遊戲的核心,它是 MOBA:多人線上戰鬥競技場。


有什麼特點? 高速多向通訊流/廣播/組播/10人之間釋出和訂閱各種遊戲活動的各種通訊模式


所以遊戲的核心是小團體之間的高速網路通訊。 是對方所說的真實時間。 如果有額外的 10ms 延遲,玩家將被詛咒。


微服務為了完美拆解業務,將同一程式中的原有模組拆分為不同的服務,顯著增加了額外的網路開銷。 更不用說服務網格、

各種閘道器、代理和邊車,只需要擔心低延遲。


微服務基本上只有一種請求/響應模式。 不能做流媒體? 微服務通常要求應用程式是無狀態的,以便水平擴充套件。 流式傳輸本

身被新增到狀態中。 可以想象,為了提高通訊效能,一款英雄聯盟遊戲很可能會使用同一個伺服器來進行這10名玩家之間

的通訊,這樣就可以在本地交換資料,從而最大限度地提高效能。 . 客戶端或伺服器端統一閘道器的要求是支援粘性路由。 

假設客戶端斷開連線,下一個客戶端必須像以前一樣重新連線到同一臺伺服器。 微服務的無狀態、水瓶擴充套件需求本質上是

反粘性路由,因為粘性路由本身就是狀態。


對於一個伺服器叢集來說,同時進行的LOL遊戲數不勝數,每一局都可以看成一個沙盒,每個沙盒都處於不同的狀態:推了

多少塔,殺了多少? 這是第二次。 對面有多少個超神,20分鐘就到了? 這些是長期存在的狀態,直到遊戲結束才能被服務

器清除。 因此,雖然這些狀態不需要寫入持久儲存,但它們不可避免地會在記憶體中保留很長時間。 他們都是州。 無論如何,

如果你有狀態,甚至不要考慮使用微服務。 除非您正在談論將所有這些狀態轉移到 redis,否則伺服器將不得不在流的中途

發出遠端請求,並且隨著您來回移動,延遲會增加。 無論如何都不好。 (比如,假設對方在你A的水晶中,A的每一次操作

都是到伺服器沙箱的一個事件流。沙箱中有一個流處理器來計算你的水晶是否爆炸。這個計算需要很 快,你不能遠端儲存你

的水晶健康資料)


這類遊戲對網路、記憶體、CPU最佳化的要求很高。 整個遊戲過程中,幾乎沒有RPC呼叫,確實需要遠端資料,也應該是prefetch

,也就是遊戲剛開始的時候。 載入。


微服務不是靈丹妙藥,也就是說,它們只是為了輕鬆拆解原始 CRUD 應用程式。 一是不涉及高階互動方式,二是不涉及分

布式系統真正的難點:狀態,其實並沒有大家想象的那麼好用。 感覺微服務改變了網際網路的原因是因為 90% 的網際網路應用

程式只是小規模的 CRUD。


對方沒聽說過微服務是沒有問題的,因為它本身並不是一個深奧的概念。 相反,對方聽了你的話,就會知道微服務不適

合遊戲,說明對方理解能力強,對遊戲系統設計有足夠的瞭解深的。 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70017615/viewspace-2906163/,如需轉載,請註明出處,否則將追究法律責任。

相關文章