筆者最近去面試了家遊戲公司（有上市）。我問他，公司有沒有做微服務架構的打算及考量？他很驚訝的，我沒聽說過微服務耶，你可以解釋一下嗎？
我大概說了，方便測試，方便維護，方便公升級，服務之間松耦合，可多語言開發，自動擴容……之類的點。
然後他說遊戲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而已。
對方沒有聽說過微服務完全沒有問題，因為這本身就不是什麼高深的概念，反而對方聽你一說一下就知道微服務不適合遊戲，說明對方理解能力很強，對遊戲系統設計也了解足夠深。
做過棋牌遊戲（遊戲最簡單的一種），可以嘗試說幾個點：
微服務本身是為了應對業務邏輯的複雜，需要要的新的組織介面的方式。遊戲本身邏輯其實沒有這麼複雜，比如大廳就是一些基本功能，修改帳號，登入等。遊戲本身就是遊戲本身的邏輯。
遊戲邏輯伺服器本身（比如鬥地主等棋牌）因為網路響應效能要求問題（玩家對每個操作的反饋時長敏感度遠高於業務系統），所以遊戲伺服器都是有狀態的，狀態就存在記憶體，偶爾會接受redis，mysql等是絕對不可以的接受的，關係行資料庫僅用來定時非同步持久化資料，僅遊戲伺服器而言持久化在redis即可。
遊戲伺服器一般純需要主動推送，所以第一代微服務閘道器就沒辦法滿足需求， tcp的沒有閘道器用，spring cloud gateway的web socket也許可以用（但是從防攻擊角度講端游用tcp絕對比web socket合理）。
服務間通訊rpc首先ribbon，feign等並不是合適，因為都是基於http的，用http存在乙個訊息亂序問題，比如玩家出牌兩次，在http就可能出現次序不一致。遊戲伺服器集群一般使用長連線互聯。可能需要用dubbo？（聽說是長連線）
遊戲邏輯伺服器（比如鬥地主伺服器），一般是不能用spring mvc做的，因為執行緒模型完全不同。多執行緒模型處理遊戲效能差還非常複雜，一般都是使用單程序/執行緒 驅動固定數量房間的方式（這也是為何伺服器一定有狀態，一定不能直接讀寫mysql）。一般就直接netty了。
自動擴容在遊戲這邊叫做開服，早就有固定流程和工具和限流方式了。
遊戲很多操作不存在服務降級熔斷，不行就要直接報錯給使用者。
大廳伺服器登入註冊等的確可以做微服務，但是其實也不是做微服務，就是幾個介面有自動水平擴容的方案即可。服務註冊發現用處不大，開服都是確定的事情，還有一系列運營手段配合，關服也是絕對不能隨便關的。
一些獨立的伺服器比如充值之類的需要微服務化麼？只能說這種伺服器都需要微服務處理了，專案組做夢都能笑醒。
雖然上面說了很多點，但是其實也是可以考慮用spring cloud改造的，因為遊戲集群一樣有註冊中心，需要服務發現，需要編排啟動順序，只是spring cloud沒有為了遊戲設計而已，比如至少要完全支援webflux吧（沒有仔細研究），需要乙個單執行緒的長連線最好支援protobuf rpc框架吧（整合服務發現相關功能與介面），閘道器支援tcp或者至少封裝或者暴露一些netty的decoder encoder（或者允許注入）等等。
放浪者這樣回答到
。。。有些國民級moba遊戲的微服務化過程，可能有保密問題，我就不談了。
拿中年人喜聞樂見的wow來說，你們不知道有專門的排隊伺服器、場景伺服器、副本伺服器麼這些麼？你以為每次切換場景時的loading介面在做啥？就是完成service的切換啊。
你非要用web那一套來套在遊戲上面，那當然不行，那說明你對microservice的理解太狹隘了。microservice重點是業務邏輯的拆分和獨立，難道你以為這麼多mmorpg，是乙個巨大無比的monolithic的應用在跑？怎麼可能。
補充一點個人不保證正確的私貨：其實整個遊戲開發行業和網際網路行業的技術思維差異就在於stateful vs stateless，做習慣了遊戲開發的人（無論客戶端還是backend），習慣了直接在記憶體讀寫資料，不習慣從遠端讀寫（無論是redis還是db或者nosql或者啥），換句話說他們不太習慣原始資料不在本地機器上，而恰恰業務邏輯和資料分離是網際網路架構的重要指導思想。這使得遊戲開發程式設計師的技術思維很有些不一樣，我不能說不好，但是確實有點技能點的配置不同的感覺，這當實現非遊戲專案的時候是有障礙的。
一開始我說的國民級遊戲之一就是lol，搜了一下公開資料，，發現他們也略微談過一點他們後台微服務化的事情
不過他們也是比較含糊其辭的，沒談具體功能模組劃分，只含糊舉了些抽象例子。所以為了避免有些問題，我也就不提了。
微服務本身就是個模組化的概念，國內喜歡眉毛鬍子一把抓強調單機效能單機併發（實質是發懶），而要把單體應用的各種模組分拆出來，問題主要是團隊管理、服務治理、開發協調、部署、功能邊界和定義這些微服務本身的坑。至於很多人說的效能、響應速度等等，這些都是拆分時要考慮的因素之一罷了，並不是啥模組都要糾結這些的。
來自
為什麼遊戲會成為區塊鏈最先火爆的專案？
問題 為什麼遊戲會是區塊鏈中最先火爆起來的專案，而務實的應用，比如溯源 公證等專案卻會滯後呢？回答 區塊鏈技術的核心是分布式記賬，他的應用範圍並不廣闊，也不是萬能的。大家看到不少應用，其實都是偽需求。如何判斷乙個專案或者應用是否為偽需求？我給大家提供乙個思路 平行世界的理論。首先先區分三個世界 區塊...
Atari聯合創始人去世，為什麼遊戲對AI很重要？
那個花了250美元創辦atari 雅達利 的人，ted dabney，上個月去世了。ted dabney 全名samuel f.ted dabney 可能沒有與他一起創辦雅達利的諾蘭 布希內爾 nolan bushnell 出名，但當年風靡世界的經典遊戲pong，就是出自ted dabney等人之手...
為什麼遊戲行業一直是DDoS 攻擊的重災區
中國的遊戲市場已經進入繁榮發展期。不管是網遊 頁遊 端遊，還是手遊，尤其是手遊得到爆發式增長。伴隨遊戲行業的快速發展，隨之而來的難題就是ddos攻擊也越來越頻繁。遊戲行業ddos攻擊的主要原因是因為遊戲產品生命週期偏短，而ddos供給成本又不高，只要發起攻擊，企業為確保遊戲穩定運營而不得不快速做出讓...