游戲公司不使用微服務(wù)架構(gòu)的原因

背景介紹

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

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

我問他，公司有沒有做微服務(wù)架構(gòu)的打算及考量？

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

我大概說了，方便測(cè)試，方便維護(hù)，方便升級(jí)，服務(wù)之間松耦合，可多語言開發(fā)，自動(dòng)擴(kuò)容…之類的點(diǎn)

然后他說游戲 server 不太需要微服務(wù)，因?yàn)橐?real time，做微服務(wù)會(huì)影響效能，分模組來開發(fā)就好了

我也不確定，但微服務(wù)不是趨勢(shì)嗎？特別是大公司，游戲 server 的服務(wù)應(yīng)該很容易拆分吧？

回答

整理了幾個(gè)不錯(cuò)的回答，分享一下。只能說學(xué)到了，技術(shù)也要用對(duì)場(chǎng)景呀！

陳宏基的回答

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

賬號(hào)系統(tǒng)，符文系統(tǒng)，英雄系統(tǒng)，皮膚系統(tǒng)，好友系統(tǒng)，好友之間 messaging，這些都是常規(guī)操作，如果流量足夠大，當(dāng)然可以用微服務(wù)的架構(gòu)去做。

不過這不是這個(gè)游戲的核心，核心是 MOBA：Multiplayer online battle arena。特性是什么？

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

所以游戲的核心在于小規(guī)模群體之間的高速網(wǎng)絡(luò)通信 。就是對(duì)方說的 realtime。多了一個(gè) 10ms 的延遲玩家就要罵娘了。

微服務(wù)為了把業(yè)務(wù)完美拆解，把原來的同一個(gè)進(jìn)程里的模塊拆分成不同的服務(wù)，顯著增加額外的網(wǎng)絡(luò)開銷 。更別說什么 service mesh，各種 gateway，proxy，sidecar，簡(jiǎn)直就是擔(dān)心延遲太低。

微服務(wù)基本只有 request/response 的模式。做不了 streaming？微服務(wù)通常要求應(yīng)用是無狀態(tài)的才能做到水平擴(kuò)展。streaming 本身就是加入了狀態(tài)

我可以想像，為了提高通訊的性能，一場(chǎng)英雄聯(lián)盟游戲很可能會(huì)使用同一個(gè)服務(wù)器負(fù)責(zé)這 10 個(gè)玩家之間的通訊，這樣就使得數(shù)據(jù)可以在本地交換，性能最大化 。這對(duì)客戶端或者說服務(wù)端統(tǒng)一網(wǎng)關(guān)的要求是必須支持 sticky routing。假設(shè)客戶端連接斷了，接下來的必須重連之前的同一個(gè)服務(wù)器。微服務(wù)的 stateless，水瓶擴(kuò)展要求本身就是反 sticky routing 的，因?yàn)?sticky routing 本身就是狀態(tài)。

對(duì)服務(wù)端集群來說，同時(shí)有無數(shù)個(gè)王者榮耀的比賽在進(jìn)行，每個(gè)都可以看成一個(gè)沙盒，每個(gè)沙盒都處于一個(gè)不同的狀態(tài)：塔被推了幾個(gè)了，你被殺了幾次了，對(duì)面幾個(gè)超神了，20 分鐘到了沒。這些都是長(zhǎng)時(shí)間存在的狀態(tài)，直到游戲結(jié)束，服務(wù)端才可以清理一場(chǎng)游戲的狀態(tài)。

所以雖然不用把這些狀態(tài)寫進(jìn)持久性存儲(chǔ)，但是必然會(huì)在內(nèi)存中存在很長(zhǎng)時(shí)間。都是狀態(tài)，反正有狀態(tài)，就別想用微服務(wù)。除非你說把這些狀態(tài)都移到 redis 里去，那么在服務(wù)器在信息流傳輸?shù)揭话脒€要做一個(gè) remote request，一來一回，延遲就上升了。總之怎樣都不好。（比如想象對(duì)方在 A 你的水晶，每一次 A 的操作都是一個(gè) event，被 streaming 到服務(wù)端的沙盒中，沙盒中有一個(gè)流處理器，每次接收到一個(gè)你水晶被 A 的 event 都會(huì)計(jì)算一下你水晶爆了沒。這個(gè)計(jì)算需要極快，你是不可能把你水晶生命值的數(shù)據(jù)存在遠(yuǎn)端的）

像這類游戲，都是對(duì)網(wǎng)絡(luò)，內(nèi)存，CPU 的優(yōu)化需求很高，整個(gè)游戲進(jìn)行過程中，幾乎不存在什么 RPC call，真的需要 remote data，也應(yīng)該是 prefetch，就是在游戲剛開始的時(shí)候加載好

微服務(wù)不是什么銀彈，也就是方便拆解一下原來的 CRUD 應(yīng)用罷了而已，一沒觸及高級(jí)的交互方式，二沒觸及分布式系統(tǒng)真正的難點(diǎn)：狀態(tài)，其實(shí)沒有大家想的那么有用。之所以感覺上好像微服務(wù)改變了互聯(lián)網(wǎng)，只不過 90%的互聯(lián)網(wǎng)應(yīng)用都只是簡(jiǎn)單小規(guī)模的 CRUD 而已。

對(duì)方?jīng)]有聽說過微服務(wù)完全沒有問題，因?yàn)檫@本身就不是什么高深的概念，反而對(duì)方聽你一說一下就知道微服務(wù)不適合游戲，說明對(duì)方理解能力很強(qiáng)，對(duì)游戲系統(tǒng)設(shè)計(jì)也了解足夠深。

陳宏基的回答：

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

一位匿名用戶的回答

看來是是最近被 微服務(wù)洗腦了， 個(gè)人感覺正常微服務(wù)，一個(gè)服務(wù)必須有 3 個(gè)以上工程師單獨(dú)維護(hù)，才真真把微服務(wù)盤起來。

而且微服務(wù)現(xiàn)在最多就是 HTTP 這種協(xié)議跑，很占性能的，就算是走 TCP HTTP2 遠(yuǎn)遠(yuǎn)不如單體性能，尤其是微服務(wù)做業(yè)務(wù)分叉調(diào)用的時(shí)候怎么劃分，數(shù)據(jù)事件一致性 是非常頭痛的一件事。

微服務(wù)用的廣是 WEB 方面 而且工程師多，業(yè)務(wù)變來變多，而且它幾乎是自己玩自己的。這種場(chǎng)景就非常適合。實(shí)時(shí)性不需要那么高那種

我知道很多人，把微服務(wù)魔化了，別人要 100 層功力，而你只學(xué)到了 1 層。然后就硬搬上來跟別人說這很牛逼

我看過那么多博客，技術(shù)文，唯獨(dú)就微軟官方那一篇 微服務(wù)技術(shù)寫的最好，明確的告訴你這種架構(gòu)適合什么樣的場(chǎng)景跟團(tuán)隊(duì)，什么樣的場(chǎng)景不要用，而不是一些文章無腦吹

脫離業(yè)務(wù)的技術(shù)架構(gòu)，就是為了框架而架構(gòu)，就是沒事給自己搬石頭砸腳跟

對(duì)于開發(fā)者來說，自己去研究研究新技術(shù)是值的非常推崇的。但是不考慮實(shí)際情況，那就是魔怔了。

為啥有這種感觸，因?yàn)槲沂鞘芎θ?。所以奉勸各?什么樣的團(tuán)隊(duì)項(xiàng)目底子業(yè)務(wù) 就選擇最合適自己的架構(gòu)，不要盲目去跟風(fēng)，更不要盲目的去對(duì)比大廠云云云，你的業(yè)務(wù)跟團(tuán)隊(duì)是別人的零頭都不夠。別人的 HR 團(tuán)隊(duì)可能都比你技術(shù)團(tuán)隊(duì)人數(shù)多。

架構(gòu)分的越單元化，那么需要的人數(shù)是翻倍起來維護(hù)的，不然你就會(huì)發(fā)現(xiàn)為什么這個(gè)架構(gòu)我用起來這么啰嗦。不是別人的架構(gòu)不夠好，是你的團(tuán)隊(duì)還不需要

有小伙伴想找微軟的微服務(wù)架構(gòu)鏈接 我放一下：

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

liulilte 的回答

...游戲服務(wù)器都是幾乎都是帶大量狀態(tài)的，我就問你一個(gè)致命問題，游戲里面本來在同個(gè)進(jìn)程內(nèi)，內(nèi)存直接可以訪問到，走微服務(wù)就可能這個(gè)服務(wù)不在本機(jī)設(shè)備上面，那就需要走網(wǎng)絡(luò)傳輸過去，那么你考慮過延遲問題嗎？有考慮過如果連接掛掉？

每個(gè)微服務(wù)跨本機(jī)都是一個(gè) RPC 調(diào)用，這東西是不可靠的，如果你要可靠行啊，你準(zhǔn)備約定一個(gè)接口調(diào)用多少毫秒超時(shí)重傳？200/500?(這就存在兩個(gè)情況：對(duì)面已經(jīng)處理，對(duì)面沒有處理，但實(shí)際上是同一個(gè)調(diào)用請(qǐng)求）

如果玩家只是放一個(gè)技能，需要投射狀態(tài)呢，因?yàn)閿嚅_重傳等幾百毫秒響應(yīng)，那么玩家體驗(yàn)是啥。

固然，我們可以使用協(xié)程，C++也可以，那么編碼復(fù)雜度有考慮過嗎？而且大量的異步編程在游戲服務(wù)器上面是很困難的，也就意味著需要更多的游戲服務(wù)器開發(fā)人員，而且還得要求開發(fā)人員的綜合素質(zhì)不能太差。

審核編輯：黃飛