作者:二周目赤

出處:https://www.cnblogs.com/cr1719/p/13866841.html

我們最開始做的游戲框架，多數都是client—>server—>db的模式，但是隨著玩家數量的增加，一個server進程就會扛不住，需要多個進程服務于多個玩家。但是給定了不同進程的玩家，有可能需要交互，這就導致了client與server端的連接，有可能是o(1)，但也可能是o(n)連接，o(n)的擴展性非常差，不容易維護，因此可以剔除了。但是如果只保持o(1)，那必然要引入新的抽象服務，網關也就登場了。下圖是一個簡單的網關部署架構：

網關的引入，有哪些改變呢？

• 內外網解耦，在保持客外網客戶端不變的情況下，可以通過這個中間層調整內網服務的實現
• 規范化，由于請求是網關統一接受和分發的，會直接促使客戶端在發送和接受請求時規范化
• 安全，由于網關具有收口作用，所有的安全問題都可以在這里解決，保護內網，比如反爬，認證等功能
• 限流熔斷，在網關上實現限流，避免內網被突發流量壓垮
• 統一的監控告警平臺

有了網關后，開始在下游增加業務邏輯，可能我們會把所有的業務都耦合成一個service，比如聊天掛了，派系掛了，場景掛了，都可能會對有戲本身產生影響；基于此，不得不考慮拆分進程，之前的游戲service服務，可能會被拆分為多個服務，但是對于大多數的游戲開發人員來說，基于服務的開發，比基于進程的開發，也難的多，如果不是領導推進，也不會有人愿意把聊天做成一個單獨的服務。

對于游戲來說，服務拆分最最極端的情況，就是一個消息cmd對應了一個service，但是這種情況會導致service越來越多，無法維護的程度，實際上游戲拆分也確實沒有必要。不過服務service越來越多，某個service甚至處于內存，cpu瓶頸的狀態，應該如何解決呢？這時候rpc的服務治理派上了用場。我們對上面的圖示做下改動：

game-rpc的引入，解決了哪些問題呢？

• 開發人員不再需要關注內部通信機制，減少項目開發時間，降低成本
• 強大的集群容錯，負載均衡能力等，保證每次調用都能路由到合適的節點

service與service做成了集群，每個service啟動后，往zk或nacos注冊中心注冊自己的url。gateway在啟動后，訂閱zk注冊中心的service列表，依托于rpc本身強大的集群，負載等功能，可以自動實現service的切換。

在針對rpg等長連接游戲類型時，玩家在場景中的移動都需要同步，廣播給周圍的玩家，但是rpc是單通道的，不能回傳，這應該如何處理呢？

有借于此，game-rpc增加了全雙工的概念，不僅僅是client對service的請求，同時service也可以根據uniqueId，進行主動推送。于是上面的流程圖變成了下面這樣：

一切看上去都很完美，似乎沒有問題了，然而新的問題隨之出現。

我們知道，優秀的架構體系中，單點問題是不能容忍的，很不幸，我們的gateway，就出現了單點。隨著玩家數量的增加，整個服務都會處于不可用的狀態。于是網關需要拆成集群的模式，新的架構圖顯示如下：

網關拆分后，gate1和gate2的玩家是兩個tcp長連狀態的服務，無法交互，這應該怎么辦？

我們參照了現行市面上比較常用的tcp網關做法，消息下行通知的解決方案，目前框架支持了兩種方式：

• MQ廣播機制，當某臺網關服務器收到廣播消息后，MQ通知給集群內的所有gate server，每個gate在收到消息后，判斷要推送端的消息是否是當前gate所持有的會話，如果在當前服務，則進行推送，否則拋棄

• redis session共享，針對MQ的廣播機制，如果以后游戲火爆，同時有百萬玩家在線，那么gate集群里的機器，可能會達到上百臺不等，如果每個消息都需要MQ廣播，有可能會導致信號風暴，于是我們調整了最后一種解決方案。玩家在登錄網關，認證成功后，把玩家id作為key，當前連接的網關uniqueId作為value，存儲到redis集群中。網關隨后把消息路由到具體某個service，service從redis集群里獲取到需要廣播的玩家對應的gate服務，service通過rpc消息下行，直接推送到具體的gate，再由gate轉發到client

說明：這種架構，更適用于全區全服類型的游戲。目前我們已經有多款線上游戲使用。

作者:二周目赤

出處:https://www.cnblogs.com/cr1719/p/13866841.html

總結

以上是生活随笔為你收集整理的realtek audio console无法连接rpc服务_RPC服务在游戏中的简单运用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。