來源：zhihu.com/question/359630395/answer/954452799 今天，在知乎上看到這樣一個問題："為什麼游戲公司的server不願意微服務化？" 背景介紹 最近面試了一家游戲公司（滿大間的，有上市） 我問他，公司有沒有做微服務架構的打算及考量？ 他很驚訝的說，我沒聽 ...
來源：zhihu.com/question/359630395/answer/954452799
今天，在知乎上看到這樣一個問題："為什麼游戲公司的server不願意微服務化？"
背景介紹
最近面試了一家游戲公司（滿大間的，有上市）
我問他，公司有沒有做微服務架構的打算及考量？
他很驚訝的說，我沒聽說過微服務耶，你可以解釋一下嗎？
我大概說了，方便測試，方便維護，方便升級，服務之間松耦合，可多語言開發，自動擴容…之類的點。
然後他說游戲server不太需要微服務，因為要求real time，做微服務會影響效能，分模組來開發就好了。
我也不確定，但微服務不是趨勢嗎？特別是大公司，游戲server的服務應該很容易拆分吧？
推薦一個開源免費的 Spring Boot 實戰項目：
hongjic93 是這樣回答的
比如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而已。
對方沒有聽說過微服務完全沒有問題，因為這本身就不是什麼高深的概念，反而對方聽你一說一下就知道微服務不適合游戲，說明對方理解能力很強，對游戲系統設計也瞭解足夠深。
brice 是這樣回答到
做過棋牌游戲（游戲最簡單的一種），可以嘗試說幾個點：
1、微服務本身是為了應對業務邏輯的複雜，需要要的新的組織介面的方式。游戲本身邏輯其實沒有這麼複雜，比如大廳就是一些基本功能，修改帳號，登錄等。游戲本身就是游戲本身的邏輯。
2、游戲邏輯伺服器本身（比如鬥地主等棋牌）因為網路響應性能要求問題（玩家對每個操作的反饋時長敏感度遠高於業務系統），所以游戲伺服器都是有狀態的，狀態就存在記憶體，偶爾會接受redis，mysql等是絕對不可以的接受的，關係行資料庫僅用來定時非同步持久化數據，僅游戲伺服器而言持久化在redis即可。
3、游戲伺服器一般純需要主動推送，所以第一代微服務網關就沒辦法滿足需求， tcp的沒有網關用，spring cloud gateway的web socket也許可以用（但是從防攻擊角度講端游用TCP絕對比web socket合理）。
4、服務間通信rpc首先ribbon,feign等並不是合適，因為都是基於http的，用Http存在一個消息亂序問題，比如玩家出牌兩次，在http就可能出現次序不一致。游戲伺服器集群一般使用長連接互聯。可能需要用dubbo?(聽說是長連接)
5、游戲邏輯伺服器（比如鬥地主伺服器），一般是不能用spring mvc做的，因為線程模型完全不同。多線程模型處理游戲性能差還非常複雜，一般都是使用單進程/線程 驅動固定數量房間的方式（這也是為何伺服器一定有狀態，一定不能直接讀寫mysql）。一般就直接netty了
6、自動擴容在游戲這邊叫做開服，早就有固定流程和工具和限流方式了
7、游戲很多操作不存在服務降級熔斷，不行就要直接報錯給用戶。
8、大廳伺服器登錄註冊等的確可以做微服務，但是其實也不是做微服務，就是幾個介面有自動水平擴容的方案即可。服務註冊發現用處不大，開服都是確定的事情，還有一系列運營手段配合，關服也是絕對不能隨便關的。
9、游戲處理的流量真的不算多，你線上1萬的棋牌游戲已經很賺錢了，10W就是個特別厲害的產品了。
10、一些獨立的伺服器比如充值之類的需要微服務化麽?只能說這種伺服器都需要微服務處理了，項目組做夢都能笑醒。
雖然上面說了很多點，但是其實也是可以考慮用spring cloud改造的，因為游戲集群一樣有註冊中心，需要服務發現，需要編排啟動順序，只是spring cloud沒有為了游戲設計而已，比如至少要完全支持 webflux吧，需要一個單線程的長連接最好支持protobuf rpc框架吧（集成服務發現相關功能與介面），網關支持tcp或者至少封裝或者暴露一些netty的decoder encoder（或者允許註入）等等。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！
