今天在知乎上看到這樣一個問題："爲何遊戲公司的server不肯意微服務化？"mysql
背景介紹：web
筆者最近去面試了家遊戲公司。面試
最近面試了一家遊戲公司（滿大間的，有上市）redis
我問他，公司有沒有作微服務架構的打算及考量？spring
他很驚訝的說，我沒據說過微服務耶，你能夠解釋一下嗎？sql
我大概說了，方便測試，方便維護，方便升級，服務之間鬆耦合，可多語言開發，自動擴容…之類的點數據庫
而後他說遊戲server不太須要微服務，由於要求real time，作微服務會影響效能，分模組來開發就行了服務器
我也不肯定，但微服務不是趨勢嗎？特別是大公司，遊戲server的服務應該很容易拆分吧？微信
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（或者容許注入）等等
內容來源：知乎衆網友，整理自：Java版web項目 zhihu.com/question/359630395/answer/954452799 
歡迎關注個人微信公衆號「碼農突圍」，分享Python、Java、大數據、機器學習、人工智能等技術，關注碼農技術提高•職場突圍•思惟躍遷，20萬+碼農成長充電第一站，陪有夢想的你一塊兒成長