當前位置: 妍妍網 > 碼農

為什麽遊戲公司不使用微服務架構

2024-04-01碼農

【幹貨】

【幹貨】

轉自:知乎

https://www.zhihu.com/question/359630395/answer/954452799

背景介紹

筆者最近去面試了家遊戲公司。

最近面試了一家遊戲公司(滿大間的,有上市)

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

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

我大概說了,方便測試,方便維護,方便升級,服務之間松耦合,可多語言開發,自動擴容…之類的點

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

我也不確定,但微服務不是趨勢嗎?特別是大公司,遊戲 server 的服務應該很容易拆分吧?

回答

整理了幾個不錯的回答,分享一下。只能說學到了,技術也要用對場景呀!

陳宏基的回答

比如 moba 類遊戲/王者榮耀/LOL,就看王者榮耀的客戶端吧,想象一下。

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

不過這不是這個遊戲的核心,核心是 MOBA:Multiplayer online battle arena。特性是什麽?

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

所以遊戲的核心在於小規模群體之間的高速網路通訊 。就是對方說的 realtime。多了一個 10ms 的延遲玩家就要罵娘了。

  1. 微服務為了把業務完美拆解,把原來的同一個行程裏的模組拆分成不同的服務,顯著增加額外的網路開銷 。更別說什麽 service mesh,各種 gateway,proxy,sidecar,簡直就是擔心延遲太低。

  2. 微服務基本只有 request/response 的模式。做不了 streaming?微服務通常要求套用是無狀態的才能做到水平擴充套件。streaming 本身就是加入了狀態

  3. 我可以想像,為了提高通訊的效能,一場英雄聯盟遊戲很可能會使用同一個伺服器負責這 10 個玩家之間的通訊,這樣就使得數據可以在本地交換,效能最大化 。這對客戶端或者說伺服端統一閘道器的要求是必須支持 sticky routing。假設客戶端連線斷了,接下來的必須重連之前的同一個伺服器。微服務的 stateless,水瓶擴充套件要求本身就是反 sticky routing 的,因為 sticky routing 本身就是狀態。

  4. 對伺服端集群來說,同時有無數個王者榮耀的比賽在進行,每個都可以看成一個沙盒,每個沙盒都處於一個不同的狀態:塔被推了幾個了,你被殺了幾次了,對面幾個超神了,20 分鐘到了沒。這些都是長時間存在的狀態,直到遊戲結束,伺服端才可以清理一場遊戲的狀態。

所以雖然不用把這些狀態寫進永續性儲存,但是必然會在記憶體中存在很長時間。都是狀態,反正有狀態,就別想用微服務。除非你說把這些狀態都移到 redis 裏去,那麽在伺服器在資訊流傳輸到一半還要做一個 remote request,一來一回,延遲就上升了。總之怎樣都不好。(比如想象對方在 A 你的水晶,每一次 A 的操作都是一個 event,被 streaming 到伺服端的沙盒中,沙盒中有一個流處理器,每次接收到一個你水晶被 A 的 event 都會計算一下你水晶爆了沒。這個計算需要極快,你是不可能把你水晶生命值的數據存在遠端的)

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

微服務不是什麽銀彈,也就是方便拆解一下原來的 CRUD 套用罷了而已,一沒觸及高級的互動方式,二沒觸及分布式系統真正的難點:狀態,其實沒有大家想的那麽有用。之所以感覺上好像微服務改變了互聯網,只不過 90%的互聯網套用都只是簡單小規模的 CRUD 而已。微信搜尋公眾號:Linux技術迷,回復:linux 領取資料 。

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

陳宏基的回答:

https://www.zhihu.com/question/359630395/answer/954452799

一位匿名使用者的回答

看來是是最近被 微服務洗腦了, 個人感覺正常微服務,一個服務必須有 3 個以上工程師單獨維護,才真真把微服務盤起來。

而且微服務現在最多就是 HTTP 這種協定跑,很占效能的,就算是走 TCP HTTP2 遠遠不如單體效能,尤其是微服務做業務分叉呼叫的時候怎麽劃分,數據事件一致性 是非常頭痛的一件事。

微服務用的廣是 WEB 方面 而且工程師多,業務變來變多,而且它幾乎是自己玩自己的。這種場景就非常適合。即時性不需要那麽高那種

我知道很多人,把微服務魔化了,別人要 100 層功力,而你只學到了 1 層。然後就硬搬上來跟別人說這很牛逼

我看過那麽多部落格,技術文,唯獨就微軟官方那一篇 微服務技術寫的最好,明確的告訴你這種架構適合什麽樣的場景跟團隊,什麽樣的場景不要用,而不是一些文章無腦吹

脫離業務的技術架構,就是為了框架而架構,就是沒事給自己搬石頭砸腳跟

對於開發者來說,自己去研究研究新技術是值的非常推崇的。但是不考慮實際情況,那就是魔怔了。

為啥有這種感觸,因為我是受害人。所以奉勸各位 什麽樣的團隊計畫底子業務 就選擇最合適自己的架構,不要盲目去跟風,更不要盲目的去對比大廠雲雲雲,你的業務跟團隊是別人的零頭都不夠。別人的 HR 團隊可能都比你技術團隊人數多。

架構分的越單元化,那麽需要的人數是翻倍起來維護的,不然你就會發現為什麽這個架構我用起來這麽啰嗦。不是別人的架構不夠好,是你的團隊還不需要

有小夥伴想找微軟的微服務架構連結 我放一下:

https://learn.microsoft.com/zh-cn/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design

liulilte 的回答

...遊戲伺服器都是幾乎都是帶大量狀態的,我就問你一個致命問題,遊戲裏面本來在同個行程內,記憶體直接可以存取到,走微服務就可能這個服務不在本機裝置上面,那就需要走網路傳輸過去,那麽你考慮過延遲問題嗎?有考慮過如果連線掛掉?

每個微服務跨本機都是一個 RPC 呼叫,這東西是不可靠的,如果你要可靠行啊,你準備約定一個介面呼叫多少毫秒超時重傳?200/500?(這就存在兩個情況:對面已經處理,對面沒有處理,但實際上是同一個呼叫請求)

如果玩家只是放一個技能,需要投射狀態呢,因為斷開重傳等幾百毫秒響應,那麽玩家體驗是啥。

固然,我們可以使用協程,C++也可以,那麽編碼復雜度有考慮過嗎?而且大量的異步編程在遊戲伺服器上面是很困難的,也就意味著需要更多的遊戲伺服器開發人員,而且還得要求開發人員的綜合素質不能太差。

<END>

點這裏👇關註我,記得標星呀~

往期精選:

GPT中文網站

可以在國內同ChatGPT直接進行對話,支持GPT4.0 和 AI繪圖,簡直太方便了,今天新註冊的直接送4.0提問次數 !

點「在看」的人都變好看了哦