1. 程式人生 > >在遊戲運維實戰中摸索前行的“異地雙活”架構

在遊戲運維實戰中摸索前行的“異地雙活”架構

1. 寫在前面

最近由於遊戲業務的迫切需求,我們需要啟用一套可靠的異活雙活方案,降低業務的單點。大世界型別遊戲的特點是元件模組化,戰鬥節點、資料節點、登入認證伺服器多為獨立部署,這樣的設計有利於高線上的承載能力。但問題來了,這樣的架構要求在同一個內網裡通訊,我們常規部署都是把所有伺服器集中在一個機房裡。這樣一來,一旦機房受到攻擊或者機房出口異常再加上國內骨幹網的間歇性抽風,這會對業務將帶來全域性的影響,嚴格來說存在一個非必然但不合理的單點。在經濟學裡有一句諺語“Don’t put all your eggs into the same basket!”——不要雞蛋全部放在一個籃子裡。

2. 異地雙活之演進

2.1 第一階段(偽異活)

由於大世界架構的遊戲有個很明顯的特徵,功能性的服區分比較明顯,例如有戰鬥節點server、日誌節點log、登入節點center、資料節點data、快取節點cache,其中有些功能服需使用資料庫,有些服不需要使用資料庫只承擔玩家的戰鬥功能。這些不同的功能服無論部署在南方機房還是北方機房都存在著以下2個比較嚴重的問題,具體如下:

資料庫

為了保障業務在單機房遭受DDOS攻擊、南北骨幹網抖動故障場景下的正常執行和穩定,於是我們構思出了如下方案:

我們採取用一些技術手段:

  • 南北兩地架設一條處於公網之外的專線,專線走伺服器的內網絡卡通訊,相比公網縮小了10ms的延遲。將大世界的入口節點分別部署在南北兩個機房,避免外網登入入口程式單點。
  • 南方機房利用反向代理通過內網專線全部轉發到業務所在的北方機房,內網專線斷開時反向代理服務自動切換到公網進行轉發,實現轉發過程中的高可用。
  • 玩家進入遊戲均通過域名+埠的形式,域名針對省級做智慧解析,達到玩家就近訪問的效果。
  • 應用D監控,如果檢測到域名解析故障時,切換解析到正常的另一方,形成自動故障轉移。

這個方案雖然在設計上顯得草根,但在線上正式應用後,已經取得了一些效果,最嚴重的情況就是專線中斷,這時我們的業務仍然可以保證正常的執行,由反向代理服務自動切換到公網轉發。當然我們只能稱它為“偽異地雙活方案”。如下圖所示:

架構

2.2 第二階段(理想的異活)

隨著業務的長久執行,第一階段的方案雖然能解決機房遭受DDOS攻擊、南北骨幹網抖動等故障場景,但也暴露了不少其他問題。例如:

DDOS

要解決“真正異地雙活”的問題,實際上主要是解決資料同步的問題,底層的資料要求強一致性同時實現多寫。而在我們的業務場景,資料有緩衝層資料、非緩衝層資料。緩衝層資料“雙活”我們計劃採用redis叢集+Sentinel的方案來實現。非緩衝層的資料“雙活”我們計劃採用MySQL叢集方案。那麼問題來了,業界上主流的MySQL叢集方案有MySQL ClusterPercona Xtradb Cluster

為什麼不是Mysql Replication或MySQL Group Replication?

因為無論是MR、MM、MGR架構都是基於Binlog同步原理,涉及Mysql Binlog複製機制的方案均有延時的可能性。因為我們需要實現多寫,如果無法保證資料實時一致性,業務將無法正常運作。

於是我們針對MySQL叢集選型採取了一些壓測,主要對比兩種叢集在高併發下寫場景下的吞吐量、資料一致性、平均操作延遲等情況。

我們來看看壓測結果:

單看測試結果,當資料量和併發數越大,mysql cluster叢集的插入吞吐量、平均操作延時都越優於percona xtradb cluster叢集。這一點也不意外,因為NDB引擎主要使用記憶體儲存資料,而PXC是需要落地磁碟的。但是NDB引擎有很多劣勢,例如巨耗記憶體、管理維護麻煩、容易崩潰出錯、容易丟資料等,Oracle MySQL官網也強調NDB不建議應用於生產環境。這點有些納悶…

PXC與傳統MySQL區別不大,大部份日常的維護是相同的,也比較貼合遊戲的應用場景。關於效能方面,我們可以用SSD來代替普通機械盤,提高IO效能。最終認為Percona Xtradb Cluster更適用於我們的業務場景。

因此,我們衍生出了第二階段的方案,具體實現的架構:

架構

基於第一階段之上,新增一些關鍵技術點:

  • PXC叢集通過內網專線連線,專線故障時能自動切換到公網通訊。
  • 非緩衝層資料通過PXC叢集保持資料一致。
  • 遊戲節點同時部署在南北機房,除了入口節點以外,任何一方的遊戲節點故障,程式可自動轉移。
  • 玩家進入遊戲均通過域名+埠的形式,域名針對省級做智慧解析,玩家就近訪問。
  • 入口節點通過D監控實現故障自動轉移。
  • 原反向代理服務僅用於使用者戰鬥節點的分配,不再作為全鏈路轉發。(由於南北戰鬥節點完全地理分離,原則上南北使用者不能在同一個戰鬥節點配對,這是策劃上不允許的,所以需要利用內部轉發讓南北使用者能夠同時連線上同一個戰鬥節點)

目前第二階段方案雖然僅是測試階段,但也通過了內部業務的測試,驗證了方案的可行性。我們也計劃在近期正式應用到線上。

期待第二階段 “理想的異地雙活”能給業務帶來真實的價值!

3. 參考資料

https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-linux-rpm.html

https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html

https://www.percona.com/doc/percona-xtradb-cluster/5.7/index.html

http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html

http://www.cnblogs.com/lizhi221/p/7325401.html

http://www.cnblogs.com/52php/p/5675374.html

原文來自微信公眾號:運維軍團