王者榮耀為什么不使用微服務(wù)架構(gòu)？
今天，在知乎上看到這樣一個問題：“為什么游戲公司的server不愿意微服務(wù)化?”
背景介紹
筆者最近去面試了家游戲公司(有上市)。我問他，公司有沒有做微服務(wù)架構(gòu)的打算及考量?他很驚訝的說，我沒聽說過微服務(wù)耶，你可以解釋一下嗎?
我大概說了，方便測試，方便維護，方便升級，服務(wù)之間松耦合，可多語言開發(fā)，自動擴容……之類的點。
然后他說游戲server不太需要微服務(wù)，因為要求real time，做微服務(wù)會影響效能，分模組來開發(fā)就好了。
我也不確定，但微服務(wù)不是趨勢嗎?特別是大公司，游戲server的服務(wù)應(yīng)該很容易拆分吧?。
陳宏基是這樣回答的
比如MOBA類游戲/王者榮耀/LOL，就看王者榮耀的客戶端吧，想象一下。
賬號系統(tǒng)，符文系統(tǒng)，英雄系統(tǒng)，皮膚系統(tǒng)，好友系統(tǒng)，好友之間messaging，這些都是常規(guī)操作，如果流量足夠大，當然可以用微服務(wù)的架構(gòu)去做。
不過這不是這個游戲的核心，核心是MOBA：Multiplayer online battle arena。特性是什么?
10個人之間各種游戲事件的高速多向通訊streaming/broadcast/multicast/pubsub各種通訊模式。
所以游戲的核心在于小規(guī)模群體之間的高速網(wǎng)絡(luò)通信。就是對方說的realtime。多了一個10ms的延遲玩家就要罵娘了。
- 微服務(wù)為了把業(yè)務(wù)完美拆解，把原來的同一個進程里的模塊拆分成不同的服務(wù)，顯著增加額外的網(wǎng)絡(luò)開銷。更別說什么Service Mesh，各種Gateway，Proxy，Sidecar簡直就是擔(dān)心延遲太低。
- 微服務(wù)基本只有request/response的模式。做不了streaming?微服務(wù)通常要求應(yīng)用是無狀態(tài)的才能做到水平擴展。streaming本身就是加入了狀態(tài)
- 我可以想像，為了提高通訊的性能，一場英雄聯(lián)盟游戲很可能會使用同一個服務(wù)器負責(zé)這10個玩家之間的通訊，這樣就使得數(shù)據(jù)可以在本地交換，性能最大化。這對客戶端或者說服務(wù)端統(tǒng)一網(wǎng)關(guān)的要求是必須支持sticky routing。假設(shè)客戶端連接斷了，接下來的必須重連之前的同一個服務(wù)器。微服務(wù)的stateless，水瓶擴展要求本身就是反sticky routing的，因為sticky routing本身就是狀態(tài)。
- 對服務(wù)端集群來說，同時有無數(shù)個王者榮耀的比賽在進行，每個都可以看成一個沙盒，每個沙盒都處于一個不同的狀態(tài)：塔被推了幾個了，你被殺了幾次了，對面幾個超神了，20分鐘到了沒。
這些都是長時間存在的狀態(tài)，直到游戲結(jié)束，服務(wù)端才可以清理一場游戲的狀態(tài)。所以雖然不用把這些狀態(tài)寫進持久性存儲，但是必然會在內(nèi)存中存在很長時間。
都是狀態(tài)，反正有狀態(tài)，就別想用微服務(wù)。除非你說把這些狀態(tài)都移到redis里去，那么在服務(wù)器在信息流傳輸?shù)揭话脒€要做一個remote request，一來一回，延遲就上升了。
總之怎樣都不好。(比如想象對方在A你的水晶，每一次A的操作都是一個event，被streaming到服務(wù)端的沙盒中，沙盒中有一個流處理器，每次接收到一個你水晶被A的event都會計算一下你水晶爆了沒。這個計算需要極快，你是不可能把你水晶生命值的數(shù)據(jù)存在遠端的)。
像這類游戲，都是對網(wǎng)絡(luò)，內(nèi)存，CPU的優(yōu)化需求很高，整個游戲進行過程中，幾乎不存在什么RPC call，真的需要remote data，也應(yīng)該是prefetch，就是在游戲剛開始的時候加載好。
微服務(wù)不是什么銀彈，也就是方便拆解一下原來的CRUD應(yīng)用罷了而已，一沒觸及高級的交互方式，二沒觸及分布式系統(tǒng)真正的難點：狀態(tài)，其實沒有大家想的那么有用。之所以感覺上好像微服務(wù)改變了互聯(lián)網(wǎng)，只不過90%的互聯(lián)網(wǎng)應(yīng)用都只是簡單小規(guī)模的CRUD而已。
對方?jīng)]有聽說過微服務(wù)完全沒有問題，因為這本身就不是什么高深的概念，反而對方聽你一說一下就知道微服務(wù)不適合游戲，說明對方理解能力很強，對游戲系統(tǒng)設(shè)計也了解足夠深。
brice 是這樣回答到
做過棋牌游戲(游戲最簡單的一種)，可以嘗試說幾個點：
- 微服務(wù)本身是為了應(yīng)對業(yè)務(wù)邏輯的復(fù)雜，需要要的新的組織接口的方式。游戲本身邏輯其實沒有這么復(fù)雜，比如大廳就是一些基本功能，修改帳號，登錄等。游戲本身就是游戲本身的邏輯。
- 游戲邏輯服務(wù)器本身(比如斗地主等棋牌)因為網(wǎng)絡(luò)響應(yīng)性能要求問題(玩家對每個操作的反饋時長敏感度遠高于業(yè)務(wù)系統(tǒng))，所以游戲服務(wù)器都是有狀態(tài)的，狀態(tài)就存在內(nèi)存，偶爾會接受Redis，MySQL等是絕對不可以的接受的，關(guān)系行數(shù)據(jù)庫僅用來定時異步持久化數(shù)據(jù)，僅游戲服務(wù)器而言持久化在Redis即可。
- 游戲服務(wù)器一般純需要主動推送，所以第一代微服務(wù)網(wǎng)關(guān)就沒辦法滿足需求， TCP的沒有網(wǎng)關(guān)用，Spring Cloud Gateway的Web socket也許可以用(但是從防攻擊角度講端游用TCP絕對比Web socket合理)。
- 服務(wù)間通信RPC首先Ribbon，F(xiàn)eign等并不是合適，因為都是基于http的，用http存在一個消息亂序問題，比如玩家出牌兩次，在http就可能出現(xiàn)次序不一致。游戲服務(wù)器集群一般使用長連接互聯(lián)。可能需要用Dubbo?(聽說是長連接)
- 游戲邏輯服務(wù)器(比如斗地主服務(wù)器)，一般是不能用Spring MVC做的，因為線程模型完全不同。多線程模型處理游戲性能差還非常復(fù)雜，一般都是使用單進程/線程 驅(qū)動固定數(shù)量房間的方式(這也是為何服務(wù)器一定有狀態(tài)，一定不能直接讀寫MySQL)。一般就直接Netty了。
- 自動擴容在游戲這邊叫做開服，早就有固定流程和工具和限流方式了。
- 游戲很多操作不存在服務(wù)降級熔斷，不行就要直接報錯給用戶。
- 大廳服務(wù)器登錄注冊等的確可以做微服務(wù)，但是其實也不是做微服務(wù)，就是幾個接口有自動水平擴容的方案即可。服務(wù)注冊發(fā)現(xiàn)用處不大，開服都是確定的事情，還有一系列運營手段配合，關(guān)服也是絕對不能隨便關(guān)的。
- 游戲處理的流量真的不算多，你在線1萬的棋牌游戲已經(jīng)很賺錢了，10W就是個特別厲害的產(chǎn)品了。
- 一些獨立的服務(wù)器比如充值之類的需要微服務(wù)化么?只能說這種服務(wù)器都需要微服務(wù)處理了，項目組做夢都能笑醒。
雖然上面說了很多點，但是其實也是可以考慮用Spring Cloud改造的，因為游戲集群一樣有注冊中心，需要服務(wù)發(fā)現(xiàn)，需要編排啟動順序，只是Spring Cloud沒有為了游戲設(shè)計而已，比如至少要完全支持WebFlux吧(沒有仔細研究)，需要一個單線程的長連接最好支持Protobuf RPC框架吧(集成服務(wù)發(fā)現(xiàn)相關(guān)功能與接口)，網(wǎng)關(guān)支持TCP或者至少封裝或者暴露一些Netty的Decoder Encoder(或者允許注入)等等。
