作者：鄧軍

引言

在國內遊戲版號限制的大背景下，很多中國遊戲公司開始了海外“掘金”之路。海外遊戲運營根據不同題材或者遊戲型別，多會進行跨地區、跨平臺、甚至是全球同服的部署方案。這其中如MMO《原神》、SLG《萬國覺醒》、MOBA《無盡對決》、TPS《Free Fire》等遊戲的作品，給國內遊戲研發及發行公司帶來了不小的啟發。

一、背景概況

在全球化、多地域遊戲架構設計中，籠統的劃分有前端和後端兩類架構組建。其中前端有遊戲匹配服、閘道器服、遊戲平臺服、遊戲（戰鬥服）伺服器等；後端伺服器一般有遊戲資料庫（關係型資料庫、NoSQL 資料庫等）、資料分析等。

本節內容將以遊戲前端架構中常見的跨區域玩家匹配架構、Google Play\App Store訊息推送、支付驗證、SDK訪問等全球動態加速場景進行闡述和解決方案設計。

海外遊戲發行中拿SLG這種輕量遊戲來說，一般會選取覆蓋核心發行區域的地域作為中心節點，其他區域作為邊緣服。如以北美、歐洲為中心服，其他非核心區域如東南亞、日韓、港澳臺等地區作為邊緣服。在此架構中一般邊緣服只會部署輕量前端業務，不會部署過重的平臺業務邏輯和後端業務邏輯。那麼解決邊緣服到中心服的SDK加速，提高使用者登入、支付的等遊戲體驗，就需要有全球或區域動態加速來解決問題。

二、方案設計及架構

針對上述情況中，我們一般會採用CDN廠商的動態加速，或者如AWS、Aliyun等廠商的GA產品解決問題。但是如果想要充分利用GCP全球優質網路資源，且源站不在Google Cloud的情況下，我們推薦使用NLB+自建Nginx伺服器的方式來解決。具體架構如下：

三、關鍵技術說明

（1） GCP NLB TCP Proxy(即外部 TCP/UDP 網路負載平衡)，TCP 代理負載平衡是一種反向代理負載平衡器，它將來自網際網路的 TCP 流量分配到 Google Cloud VPC 網路中的虛擬機器例項。使用 TCP 代理負載平衡時，經由 TCP 連線傳輸的流量會在負載平衡層終止，然後使用 TCP 或 SSL 轉發到最近的可用後端。備註：NLB不限制TCP埠而GLB會有固定埠限制，如果動態加速為Http協議則選擇GLB，同時Http協議也不適用於本方案，可以直接採用GLB+NEG的方式進行動態加速。

TCP 代理負載平衡為全球所有使用者使用一個 Anycast IP 地址。TCP 代理負載平衡器可以自動將流量路由到離使用者最近的後端。同時它是一種直通式負載均衡器，因此它不會替換來自客戶端的源地址。

（2）Nginx Server（即Google Compute Engine），建議使用E2機型， E2 虛擬機器提供 2 到 32 個 vCPU 的大小，並且記憶體比率如下：標準虛擬機器為每 vCPU 0.5 GB 到 8 GB，共享核心 E2 虛擬機器為 0.25 個到 1 個 vCPU 及 0.5 GB 到 8 GB 記憶體。它們有 Intel 和 AMD EPYC Rome 處理器可選。在建立虛擬機器時選擇處理器。E2 虛擬機器在所有區域和可用區中均可用，最多支援 32 個 vCPU 和 128 GB 記憶體。

（3）Instance Group例項組，是可以作為單個實體進行管理的虛擬機器 (VM) 例項的集合。Compute Engine 提供了兩種虛擬機器例項組，即託管例項組和非託管例項組：

• 託管例項組 (MIG) 可以在多個相同的虛擬機器上執行應用。利用自動化 MIG 服務讓您的工作負載具有可擴縮性和高可用性，這些服務包括自動擴縮、自動修復、區域（多地區）部署和自動更新。備註：本方案建議使用託管例項組。

• 非託管例項組可跨一組自行管理的虛擬機器實現負載平衡。

四、詳細實施步驟

4.1 建立Nginx Server託管例項組

在Compute Engine導航中找到Instance Groups，選擇建立。備註：建議建立例項組之前先根據業務需求建立例項模板（instancetemplate）。

建立instance gourp,建議選擇stateful例項組，選擇例項模板（instance template），選擇一個靠近源站的可用區（本方案以外部源站在東京為例，所以選擇Single Zone，東京的可用區B。如果考慮跨區域容災的高可用性，可以選擇Multiple Zones。）

4.2 建立NLB負載均衡

在“建立負載均衡器”頁面選擇“TCP負載均衡”

選擇單個區域（NLB僅支援單個區域、但根據測試可以建立Anycast IP）

前端配置，網路服務層級建議選用“高階”網路層級，IP建議“建立IP地址”（該步驟會生成一個靜態Anycast IP地址），埠根據業務需要自定義設定即可。

後端配置，選擇現有例項組

4.3 配置外部源站動態加速

1.注意nginx編譯時需要加上stream模組及stream_realip_module模組;一個用來四層負載，一個用來獲取客戶端真實IP

2.開啟透傳功能proxy_protocol on，用於將連線資訊從請求連線的源傳遞到請求連線到的目標。

詳情請參考：https://blog.csdn.net/LL845876425/article/details/108352761

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream

五、補充說明

5.1 Google Cloud 負載平衡器的底層技術

• Google 前端 (GFE) 是位於 Google 入網點 (PoP) 的軟體定義分散式系統，可與其他系統和控制層面協同執行全球負載平衡。

• Andromeda 是 Google Cloud 的軟體定義網路虛擬化堆疊。

• Maglev 是用於網路負載均衡的分散式系統。

• Envoy 代理是專為雲原生應用設計的開源邊緣和服務代理。

5.2 代理負載均衡和直通式負載均衡

• 代理負載均衡器會終止傳入的客戶端連線，並開啟從負載均衡器到後端的新連線。區域外部 HTTP(S) 負載均衡器和內部 HTTP(S) 負載均衡器是基於開源 Envoy 代理的代管式服務。

全域性外部 HTTP(S) 負載均衡器使用全球的 Google Front End (GFE) 代理終結客戶端連線。此外，具有高階流量管理功能的全域性外部 HTTP(S) 負載均衡器使用 Envoy 代理來實現加權流量拆分、離群值檢測和流量映象等功能。

• 直通式負載均衡器不會終止客戶端連線。後端虛擬機器會接收經過負載均衡的資料包，並且資料包的來源、目的地和埠資訊（如果適用）保持不變。然後，後端虛擬機器終止連線。來自後端虛擬機器的響應直接傳送到客戶端，而不是透過負載均衡器返回。其術語稱為直接伺服器返回。如果您需要保留客戶端資料包資訊，請使用直通式負載均衡器。外部 TCP/UDP 網路負載均衡器和內部 TCP/UDP 負載均衡器是直通式負載均衡器。

5.3 NEG網路端點組簡介

網路端點組 (NEG) 是一個配置物件，用於指定一組後端端點或服務。此配置的一個常見使用場景是在容器中部署服務。同時也可以將流量精細地分配給在後端例項上執行的應用，如將 NEG 用作某些負載均衡器和 Traffic Director 的後端。

GCP的NEG的型別有如下幾種：

• 區域 NEG（一個或多個解析為 Compute Engine 虛擬機器例項或 GKE Pod 的內部 IP 地址端點。）

• 網際網路 NEG（在 Google Cloud 外部託管的單個透過網際網路路由的端點。只有全域性外部 HTTP(S) 負載均衡器（經典版）支援）

• 無伺服器 NEG（Google 網路內解析為 App Engine、Cloud Functions 或 Cloud Run 的單個端點。）

• 混合連線 NEG（一個或多個解析為本地服務、其他雲中的伺服器應用以及 Google Cloud 外部其他可透過網際網路訪問的服務的端點。）

• Private Service Connect NEG（解析為 Google 管理的服務端點的單個端點）

5.4 Google CLoud網路層級

GCP的網路層級分為優質層級和標準層級，優質層級透過 Google 的優質骨幹網提供流量，而標準層級則使用常規 ISP 網路。

優質層級利用 Google 高度可靠的低延遲全球網路，將來自外部系統的流量傳輸到 Google Cloud 資源。此網路由一個大型專用光纖網路組成，在全球有 100 多個接入點 (PoP)。此網路經過專門設計，可承受多處故障和中斷，同時仍能傳輸流量。

對於虛擬機器例項和負載平衡器，優質層級既支援地區級外部 IP 地址，又支援全球級外部 IP 地址。所有全球外部 IP 地址都必須使用優質層級。如果應用對效能和可用性的要求很高（例如，應用需要將帶有後端的 HTTP(S)、TCP 代理和 SSL 代理負載平衡器用於多個地區），則需要使用優質層級。對於使用者遍佈於全球多個位置的客戶，如果需要出色的網路效能和可靠性，則非常適合使用優質層級。