背景介紹

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

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

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

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

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

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

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

回答

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

陳宏基的回答

比如 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 本身就是狀態。

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

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

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

微服務不是什么銀彈，也就是方便拆解一下原來的 CRUD 應用罷了而已，一沒觸及高級的交互方式，二沒觸及分布式系統真正的難點：狀態，其實沒有大家想的那么有用。之所以感覺上好像微服務改變了互聯網，只不過 90%的互聯網應用都只是簡單小規模的 CRUD 而已。

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

陳宏基的回答：

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++也可以，那么編碼復雜度有考慮過嗎？而且大量的異步編程在游戲服務器上面是很困難的，也就意味著需要更多的游戲服務器開發人員，而且還得要求開發人員的綜合素質不能太差。

審核編輯：黃飛