為什麼遊戲公司的伺服器不願意微服務化？

賬號系統、符文系統、英雄系統、皮膚系統、好友系統、好友之間的交流，這些都是日常操作。 如果流量夠大，當然可以用

微服務架構來完成。

但這不是這款遊戲的核心，它是 MOBA：多人線上戰鬥競技場。

有什麼特點？ 高速多向通訊流/廣播/組播/10人之間釋出和訂閱各種遊戲活動的各種通訊模式

所以遊戲的核心是小團體之間的高速網路通訊。 是對方所說的真實時間。 如果有額外的 10ms 延遲，玩家將被詛咒。

微服務為了完美拆解業務，將同一程式中的原有模組拆分為不同的服務，顯著增加了額外的網路開銷。 更不用說服務網格、

各種閘道器、代理和邊車，只需要擔心低延遲。

微服務基本上只有一種請求/響應模式。 不能做流媒體？ 微服務通常要求應用程式是無狀態的，以便水平擴充套件。 流式傳輸本

身被新增到狀態中。 可以想象，為了提高通訊效能，一款英雄聯盟遊戲很可能會使用同一個伺服器來進行這10名玩家之間

的通訊，這樣就可以在本地交換資料，從而最大限度地提高效能。 . 客戶端或伺服器端統一閘道器的要求是支援粘性路由。 

假設客戶端斷開連線，下一個客戶端必須像以前一樣重新連線到同一臺伺服器。 微服務的無狀態、水瓶擴充套件需求本質上是

反粘性路由，因為粘性路由本身就是狀態。

對於一個伺服器叢集來說，同時進行的LOL遊戲數不勝數，每一局都可以看成一個沙盒，每個沙盒都處於不同的狀態：推了

多少塔，殺了多少？ 這是第二次。 對面有多少個超神，20分鐘就到了？ 這些是長期存在的狀態，直到遊戲結束才能被服務

器清除。 因此，雖然這些狀態不需要寫入持久儲存，但它們不可避免地會在記憶體中保留很長時間。 他們都是州。 無論如何，

如果你有狀態，甚至不要考慮使用微服務。 除非您正在談論將所有這些狀態轉移到 redis，否則伺服器將不得不在流的中途

發出遠端請求，並且隨著您來回移動，延遲會增加。 無論如何都不好。 （比如，假設對方在你A的水晶中，A的每一次操作

都是到伺服器沙箱的一個事件流。沙箱中有一個流處理器來計算你的水晶是否爆炸。這個計算需要很 快，你不能遠端儲存你

的水晶健康資料）

這類遊戲對網路、記憶體、CPU最佳化的要求很高。 整個遊戲過程中，幾乎沒有RPC呼叫，確實需要遠端資料，也應該是prefetch

，也就是遊戲剛開始的時候。 載入。

微服務不是靈丹妙藥，也就是說，它們只是為了輕鬆拆解原始 CRUD 應用程式。 一是不涉及高階互動方式，二是不涉及分

布式系統真正的難點：狀態，其實並沒有大家想象的那麼好用。 感覺微服務改變了網際網路的原因是因為 90% 的網際網路應用

程式只是小規模的 CRUD。

對方沒聽說過微服務是沒有問題的，因為它本身並不是一個深奧的概念。 相反，對方聽了你的話，就會知道微服務不適

合遊戲，說明對方理解能力強，對遊戲系統設計有足夠的瞭解深的。