網易遊戲運維實踐：服務架構及全球通服－AWS峰會演講實錄

導讀：AWS作為網易遊戲海外發行的重要選擇之一，為網易遊戲在全球運營過程中提供極大便利，在4月27日AWS遊戲開發者大會深圳站上，網易遊戲資深雲解決方案工程師Bruce代表網易團隊帶來了《網易遊戲海外AWS實踐分享》。

上一期，學院君推送了Bruce分享的網易遊戲在《陰陽師》《荒野行動》《第五人格》《明日之後》等多款遊戲出海運營過程中積累的實踐經驗。

本次，Bruce將為大家介紹網易遊戲在AWS上面的一些運維實踐。

以下是分享實錄：


之前提到，我們基於海外發行和國內發行的差異和挑戰，會從基礎架構層面出發，建立起一套標準化的雲評測體系，來評估一個遊戲是否能發行到公有云，以及哪個雲能夠滿足需求標準。

我們在經過評測之後AWS是一個符合業務需求的選擇，因為AWS有廣泛的全球基礎設施，在計算儲存網路等方面都有高效能的方案，所以很自然AWS成為我們海外發行比較重要的選擇之一，接下來我會介紹一下網易遊戲在AWS上面的一些運維實踐。

大概分兩部分介紹：第一是服務層面的架構。第二是全球通服的實踐。

一、服務層面的架構

在AWS服務層面我們可能不會用到非常多或者複雜的服務，主要是依賴AWS比較底層的基礎服務。比如說EC2，VPC，ELB，S3還有CloudFront，這些核心服務承載了主要業務，當然也會用到安全或者是監控方面的周邊服務，以及貫穿始終的Support支援體系。


接下來為大家介紹我們在VPC層面做的業務網路架構實踐以及我們中間遇到的問題和改進的方案：

首先On Premise是指網易會有自建的機房或者是一些其它其他的第三方的供應商，這個可以認為是非亞馬遜的基礎設施。

舉個例子我需要在AWS Virginia的Region部署一個遊戲服，通常來說我們會為一個遊戲單獨分配一個獨立的VPC，這是為了做網路三層的隔離。

一開始我們的架構是比較簡單粗暴的，比如說我劃分一個public subnet部署遊戲服，再劃分一個private subnet給我的純內網業務，例如資料庫之類的服務部署，public subnet通過Internet gateway訪問Internet，這個也是比較通用的做法。


然後VPC內的例項通過Endpoint訪問AWS S3等服務。

這裡需要注意private subnet內的例項也是需要訪問公網的，比如說我一個資料庫的應用雖然不需要對外提供服務，但它也需要更新軟體包或者是做一些DNS查詢等，我們抽取出一個vnf gateway來實現，它是一個虛擬的閘道器，其實就是拉一臺虛擬機器專做網路的轉發和聯通。

這裡大家可能有一個疑問：我們為什麼不用像Cloud NAT這種比較原生的方式，後面大家就會明白為什麼我們需要這麼做。

接下來需要把我自建的資料中心，或者是其它第三方的資料中心跟AWS的VPC網路進行打通，因為有一些資料是需要做互通的，這時候我們引入了Transit VPC，在每個地區專門拉一個VPC做中轉，同region的VPC之間可以直接通過Peering互聯。

而Transit VPC跟我的業務VPC以及跟我on premise的資料中心之間互聯，就是通過剛才提到的VNF gateway以及在Transit VPC裡面加的VNF router這些VNF的例項實現。

我們通過gre+ipsec協議做隧道和安全加密，跟其它地區的互聯也通過這一條VNF gateway跟VNF router做互通的，當時設計這個方案的時候AWS的跨Region的Peering還沒有支援，所以我們當時跨Region之間如果要訪問內網其實是要走一條比較長的鏈路的。

問題和侷限

隨著遊戲越來越多，遊戲的規模越來越大，這個方案出現了一些問題和侷限性，在這裡列舉幾個比較典型的案例給大家分享；

第一點就是我剛才提到的跨region訪問內網需要繞region1 vnf gateway->region1 vnf router->region2 vpf router->region2 vnf gw這樣一條長長的鏈路，中間鏈路越多故障率越高，而且我們知道跨az、跨region的流量都是要收費的，這個方案的成本也比較高；

第二點是由於每一個遊戲VPC都需要劃分一個單獨的私有子網放資料庫之類的內部服務，隨著遊戲越來越多，每一個遊戲都要規劃這些內部服務用的子網、AZ，對於遊戲來說它的接入成本越來越高，而且對內部SAAS團隊來說也是個問題。

對於DBA來說，如果說這些網路都是在業務的VPC下面的話它的管理也有很大的問題，無法統一去規劃，所以說這個隨著規模的擴大有比較大的侷限性。

第三點是由於我們用gre協議打隧道互聯，用ipsec做加密。這一套方案經過線上實際執行下來經常會出現丟包斷線，而且一旦出問題排查起來比較麻煩。另外就是gre這個協議有些雲或第三方機房並是不支援的，所以它的穩定性和通用性不佳；

方案優化

針對這些問題我們做了一些優化：

首先我們做的就是把公共內部的SaaS服務抽出獨立的大VPC來承載，假設資料庫的業務我們就會單獨為它畫一個比較大的VPC，比如說用一個20位的cidr，下面分az去劃分子網。

這樣的一個好處就是DBA團隊可以統一的規劃好VPC的網路，subnet和az的關係，統一做到高可用，且許可權規則清晰，方便做自動化的部署，業務的VPC跟SAAS服務的VPC還是通過Peering來互通(這一點其實也會引發新的坑，先在這裡賣個關子)

針對剛才提到的gre+ipsec容易出現丟包斷線的情況，我們後來引入了uu加速器的ure自研協議，它是基於UDP的協議，基本上是所有的雲平臺和機房都支援的，而且它自帶加密，通過引入這個協議可以提升混合架構互聯的質量。

最後一點就是跨Region的互聯，AWS是去年推出了跨Region peering，我們毫不猶豫的引入這個特性，就不要繞一圈的VNF gateway實現跨region的內網互聯；


通過這一套VPC的架構，我可以實現互聯，一個是跨大洲的互聯，第二個混合架構互聯，比如說雲和第三方專線的互聯，這些所有的互聯都為全球通服打下了一個網路的基礎。

二、全球通服務實踐

第二部分簡單介紹下我們在全球通服上面做的一些實踐，我這裡舉一個最直接簡單的例子：

可能最早的時候全球通服是一個非常簡單的架構，比如說遊戲服全部跑在一箇中心的機房，全球玩家都連過來，假設就部署在新加坡，那美國的玩家，歐洲的玩家直連新加坡的網路可能是沒辦法得到保證的。

因為我們剛才通過玩家網路的評測跨大洲的玩家來直連這個網路的質量其實不一定滿足需求。那可能玩家先通過美國加州的入口，比如就是AWS加州的Region，然後把它轉發到新加坡的Region。

大家知道AWS本身跨大洲之間都是有backbone專線互聯的，這樣的話玩家先就近的連到本地的Region，然後再通過AWS本身的專線轉化到中心機房去，這樣可以提升玩家跨Region訪問的穩定性；


但是這個方案有一個侷限性就是延遲，比如說美國到新加坡的穩定性由於目前的物理極限，至少需要100ms，有些實戰類的遊戲對延遲比較高的話就無法滿足需求了。

這時候我們可能就會去各地部署相應的戰鬥服，這一套架構本身確實是目前業界比較主流的方案。

但是需要注意一點，就是是否需要去當地部署一個服有一個前提是當地的DAU作支撐，否則玩家比較少體驗不佳，可能要把幾個地區綜合起來決策部署，比如美服一個，歐服一個，亞太服一個，這是在實踐全球通服時需要注意的地方。


關於網易遊戲在AWS上的實踐就介紹到這裡，其實我們從14年底到現在走過了好幾年海外上雲的歷程，在運維與基礎架構層面，我們一開始是接到了業務的需求，然後針對這些需求去展開雲的評測，評測完了之後可能會輸出一個解決方案給到業務。

在這個解決方案的基礎上進行實踐，在實踐的過程中我們又會遇到新的問題或者新的業務需求，針對新的業務需求再去做這一套整個的上雲評估和實踐，總結下來海外上雲實踐是這樣的一個閉環。


三、下一步計劃

隨著網易遊戲海外發行數量和規模的不斷增長，業務複雜度也越來越高，現在我們也遇到了一些新的挑戰，接下來分享一下我們後續計劃做的一些優化或者是準備引入的AWS新技術。


第一是在新技術方面我們也會在積極調研測試AWS釋出的新服務，比如說arm系列新例項，全球加速器，VPC TGW等；

第二是關於容器化，遊戲是比較特別的業務，有些業務已經開始做一些微服務化的改造，這也是我們接下來會嘗試的一個方向；

第三是成本優化，隨著體量上去之後整個的資源利用率需要我們提升的，另外預留例項在我們這邊變成了一件比較複雜的事情，因為很多遊戲都做了動態的伸縮，預留例項如何採購也成了新的挑戰。

以上就是我的分享，希望對大家有所啟發。

提問環節

提問：老師你好，剛才你提到VPC有一個是做網路加速的，請問網易主要是在哪些方面做網路加速呢？

Bruce：網路加速其實就是我剛才提到的，AWS本身當然是有很強大的基礎設施的，可能在某些點上我們還會引入一些加速。

比如說我剛才提到的從美國的使用者訪問新加坡的服，那預設的情況下它是不是會只連新加坡，那這時候我們就讓它先就近連到美國當地的AWS Region，然後轉發到新加坡實際的遊戲服上面，這是其中優化的一個點。這樣避免美國的玩家直連新加坡會出現一些不穩定的情況，如果說先連到美國的AWS入口再到新加坡的話就可以直接享受到AWS本身的骨幹網。

提問：我想問一下你們有沒有評測過通過AWS的加速。

Bruce：這個問題問的非常好，到底走這一條鏈路是不是能帶來優化？這個東西其實是我們在客戶端SDK有專門的探針，探測玩家直連新加坡跟我玩家先到美國的AWS再到新加坡的AWS這之間做一個實時探測的比較，在連之前探測一下哪條鏈路最優，然後去pick其中的一條鏈路，這是在遊戲客戶端的SDK中整合實現的。

提問：那你這邊用的是AWCDN還是用全球網路加速那一塊？

Bruce：CDN雖然說有邊緣計算，但是它的邊緣計算暫時來說還沒辦法執行我們目前的網路加速的業務邏輯，所以更多的是利用AWS的資料中心。第二個就是說我們可能會考慮一些第三方的專線，當然了AWS的Lambda其實我們最近也在做一些調研了，希望能借助這些新服務優化加速的服務。

來源：網易遊戲學院
原地址：https://mp.weixin.qq.com/s/UjuuOZHJZZ-MzqpJ5Jaw0A