今天在知乎上看到這樣一個問題："為什么游戲公司的 Server 不愿意微服務化?
1.背景介紹
最近面試了一家游戲公司(滿大間的，有上市)，我問他，公司有沒有做微服務架構的打算及考量?
他很驚訝的說，我沒聽說過微服務耶，你可以解釋一下嗎?我大概說了，方便測驗，方便維護，方便升級，服務之間松耦合，可多語言開發，自動擴容…之類的點，
然后他說游戲 Server 不太需要微服務，因為要求 Real Time，做微服務會影響效能，分模組來開發就好了，
我也不確定，但微服務不是趨勢嗎?特別是大公司，游戲 Server 的服務應該很容易拆分吧?
下面，我們來看看兩位高贊回答，
2.hongjic93 是這樣回答的
比如 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，也應該是 Rrefetch，就是在游戲剛開始的時候加載好，
微服務不是什么銀彈，也就是方便拆解一下原來的 CRUD 應用罷了而已，一沒觸及高級的互動方式，二沒觸及分布式系統真正的難點：狀態，其實沒有大家想的那么有用，
之所以感覺上好像微服務改變了互聯網，只不過 90% 的互聯網應用都只是簡單小規模的 CRUD 而已，
對方沒有聽說過微服務完全沒有問題，因為這本身就不是什么高深的概念，反而對方聽你一說一下就知道微服務不適合游戲，說明對方理解能力很強，對游戲系統設計也了解足夠深，
3.brice 是這樣回答到
做過棋牌游戲(游戲最簡單的一種)，可以嘗試說幾個點：
①微服務本身是為了應對業務邏輯的復雜，需要要的新的組織介面的方式，
游戲本身邏輯其實沒有這么復雜，比如大廳就是一些基本功能，修改帳號，登錄等，游戲本身就是游戲本身的邏輯，
②游戲邏輯服務器本身(比如斗地主等棋牌)因為網路回應性能要求問題(玩家對每個操作的反饋時長敏感度遠高于業務系統)，所以游戲服務器都是有狀態的，
狀態就存在記憶體，偶爾會接受 Redis，MySQL 等是絕對不可以的接受的，關系行資料庫僅用來定時異步持久化資料，僅游戲服務器而言持久化在 Redis 即可，
③游戲服務器一般純需要主動推送，所以第一代微服務網關就沒辦法滿足需求， TCP 的沒有網關用，Spring Cloud Gateway 的 Web Socket 也許可以用(但是從防攻擊角度講端游用 TCP 絕對比 Web Socket 合理)，
④服務間通信 RPC 首先 Ribbon，Feign 等并不是合適，因為都是基于 HTTP 的，用 HTTP 存在一個訊息亂序問題，
比如玩家出牌兩次，在 HTTP 就可能出現次序不一致，游戲服務器集群一般使用長連接互聯，可能需要用 Dubbo?(聽說是長連接)
⑤游戲邏輯服務器(比如斗地主服務器)，一般是不能用 Spring MVC 做的，因為執行緒模型完全不同，
多執行緒模型處理游戲性能差還非常復雜，一般都是使用單行程/執行緒 驅動固定數量房間的方式(這也是為何服務器一定有狀態，一定不能直接讀寫 MySQL)，一般就直接 Netty 了，
⑥自動擴容在游戲這邊叫做開服，早就有固定流程和工具和限流方式了，
⑦游戲很多操作不存在服務降級熔斷，不行就要直接報錯給用戶，
⑧大廳服務器登錄注冊等的確可以做微服務，但是其實也不是做微服務，就是幾個介面有自動水平擴容的方案即可，
服務注冊發現用處不大，開服都是確定的事情，還有一系列運營手段配合，關服也是絕對不能隨便關的，
⑨游戲處理的流量真的不算多，你在線 1 萬的棋牌游戲已經很賺錢了，10萬 就是個特別厲害的產品了，
⑩一些獨立的服務器比如充值之類的需要微服務化么?只能說這種服務器都需要微服務處理了，專案組做夢都能笑醒，
雖然上面說了很多點，但是其實也是可以考慮用 Spring Cloud 改造的，因為游戲集群一樣有注冊中心，需要服務發現，需要編排啟動順序，只是 Spring Cloud 沒有為了游戲設計而已，
比如至少要完全支持 Webflux吧(沒有仔細研究)，需要一個單執行緒的長連接最好支持 Protobuf RPC 框架吧(集成服務發現相關功能與介面)，
網關支持 TCP 或者至少封裝或者暴露一些 Netty 的 Decoder Encoder(或者允許注入)等等，
作者：hongjic93、brice
zhihu.com/question/359630395/answer/954452799
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/189487.html
標籤：Java