## 作者
張路，運營開發專家工程師，現負責遊戲知幾 AI 助手後臺架構設計和最佳化工作。

## 遊戲知幾

隨著業務不斷的擴充，遊戲知幾AI智慧問答機器人業務已經覆蓋了自研遊戲、二方、海外的多款遊戲。遊戲知幾研發團隊主動擁抱雲原生，推動後臺業務全量上雲，服務累計核心1w+。

透過雲上的容器化部署、自動擴縮容、健康檢查、可觀測性等手段，提高了知幾專案的持續交付能力和穩定性，形成了一套適合遊戲知幾自身的上雲實踐方案。本文將會介紹遊戲知幾專案中遇到的痛點以及探索出的一套可靠的上雲實踐方案。

### 知幾專案背景

[遊戲知幾](https://gbot.qq.com/#/home "遊戲知幾")是一款遊戲智慧AI產品和運營解決方案，它基於自然語言處理、知識圖譜、深度學習等前沿技術，為遊戲玩家提供一站式服務，包括遊戲內外實時智慧問答、遊戲語音陪伴、自助流水查詢、遊戲內外資料互通、主動關懷防流失、產品合規保護等多種能力，目前已經接入包括王者榮耀、和平精英、PUBG mobile、天刀手遊等六星遊戲在內的80+款遊戲，為海內外數以億計的遊戲使用者提供服務，獲得眾多遊戲專案和廣大使用者的持續好評。

同時遊戲知幾還提供了簡便易用、效能良好的客戶端 SDK 和功能完備的運營平臺系統，支援模組化接入，顯著降低了使用者運營中的人力成本，提升了玩家的互動體驗。

![](https://qcloudimg.tencent-cloud.cn/raw/2bb369c74027faacf68abd6a02d00701.png)

隨著知幾業務的不斷髮展，知幾的部署架構也在不斷的演進，逐步從最初的 IDC 部署架構遷移到當前的雲原生部署架構，實現了業務服務的全面上雲。

## 上雲前的知幾

### docker 部署方案

知幾在最初採用 docker 部署的方案來部署服務，服務的 CI/CD 透過夸克平臺實現，平臺將編譯打包好的服務推送到 docker 機進行部署。為了實現機器的水平擴容，運維同學會將 docker 環境整體打包成基準映象，包括 IDC 的機器環境所依賴的環境，比如 CL5 agent，gse agent 等。當需要擴容時，將基準環境釋出到擴容機器上進行擴容操作。

知幾整體的部署架構如下圖所示：
1. 外部請求統一透過 stgw 接入，rs 到後臺服務的 vip 上，通常會區分移動、聯通、電信和小流量運營商；
2. vip 下掛載的機器IP、埠透過tgw平臺配置，請求透過一定的負載均衡策略傳送到IDC機器的後臺服務上；
3. 服務的 CI/CD 透過夸克平臺操作，完成服務的編譯、打包、釋出等操作，也支援操作回滾，程式監控等；
4. 監控告警、日誌系統接入的是mo監控平臺和駿鷹。

![](https://qcloudimg.tencent-cloud.cn/raw/3cd962cec4a0be0aac1c2d5bde9a7847.png)

### 服務遇到的問題

知幾專案會對接 IEG 下的眾多遊戲，伴隨著遊戲接入的增多，流量也變得越來越大，知幾專案的流量狀況有以下特點：

1. 平時流量平穩，節假日流量隨遊戲流量增大，通常達到3倍以上；

2. 主動關懷類的訊息推送，運營活動會透過知幾直接觸達給玩家，帶來可觀的突發流量，極端情況10倍以上；

因此，知幾對服務的穩定性、可觀測性以及服務治理的能力有很高的要求，需保證專案在流量突發的情況下能夠正常執行，故障時能及時發現。

![](https://qcloudimg.tencent-cloud.cn/raw/1ad46d00c6225b0ba9182025219ac70c.png)

在 docker 部署的架構下，很難做到快速的自動擴縮容，主要問題有以下幾個方面：

1. 擴容前的機器申請、環境準備很耗時，突發流量的情況下這個準備時間難以接受，提前準備好機器平時又會造成資源的浪費；

2. 運維製作的基準映象通常不是最新的版本，需要釋出最新版本才能擴容；

3. 依賴的許可權（mysql 等）需要申請；

4. 平臺操作繁瑣，容易出錯；

5. 需要人工完成運營活動後機器的縮容操作。

這些問題都會造成服務在擴容時的不及時，從而帶來服務穩定性的隱患，同時也帶來了業務同學的運維負擔。除此之外，每年一次的機器裁撤也很痛苦，涉及機器確認、服務遷移、環境梳理等方方面面的操作。

因此，我們希望透過上雲遷移，利用雲原生的 HPA 能力來解決服務穩定性、裁撤等問題。

----------------------
## 上雲遷移

### 知幾雲原生方案

針對以上問題，當前知幾實踐了一套基於雲原生的多機房部署方案。具體方案如下：

- 引入 tapisix 統一閘道器，藉助限流等閘道器外掛管理南北流量，stgw 接入 tapisix 閘道器的 ingress；

- 服務分南京一區和南京二區進行部署，各區服務透過 ingress 暴露外網流量，tapisix閘道器混連線入一區、二區服務的 ingress；

- 新增上海災備叢集，極端情況下可快速接入；

- CI/CD 方面透過藍盾流水線實現，打包服務映象推送到映象倉庫，在STKE上進行部署。

![](https://qcloudimg.tencent-cloud.cn/raw/dcacf959e5bf6a20e0e1f29213a96455.png)

![](https://qcloudimg.tencent-cloud.cn/raw/fd7f01e4379062985e438390040d1373.png)

基於上述的部署方案，利用雲原生的自動擴縮容能力可以方便的解決上述問題：

1. STKE 提供的定時 HPA 和動態擴縮容能力，可以很好的解決節假日、運營活動的流量突增帶來的服務穩定性問題，且流量平穩後的自動縮容可以有效的節約資源；

2. STKE 提供自動鑑權流程，可以解決依賴許可權申請的問題，通常鑑權流程的耗時在分鐘級；

3. 引入 tapsix 統一閘道器，接入分割槽流量，可以對流量進行快速切換，當一個區的服務有問題時，可以透過 tapsix 的路由快速切換到另外一個區；

### 遷移方案

知幾服務的上雲遷移設計外網和內網的眾多服務，外網服務遷移的過程可透過運營商逐步對流量進行灰度：

1. 首先在 stke 叢集新部署服務進行測試，提供移動、聯通、電信 和CAP 四類公網 CLB；

2. 先灰度 CAP 小運營商流量，服務穩定後再透過 gslb 逐步灰度其他運營商；

3. 回滾則透過 gslb 快速切換回 IDC 服務的VIP；

內網服務的遷移則透過 STKE 支援的北極星、CL5 serivce 自動將 pod ip 注入到老服務的負載均衡當中，首先透過一個 pod 進行灰度，再逐步增加 pod 完成放量，最後摘除 IDC 的機器即可。透過這種方式，我們在三個月內完成了所有外網服務和後臺服務的全量上雲，並保證了遷移的平穩進行。

![](https://qcloudimg.tencent-cloud.cn/raw/546701d58813e10ce93a40efaeae4e5c.png)

## 上雲實踐

### 標準化部署實踐

業務上雲基礎的點就是考慮怎麼做標準化的容器部署和彈性的服務。知幾服務主要有三類，業務服務通常是 Go 服務，演算法服務為 C++ 服務，需要考慮模型載入的問題，平臺服務主要為 PHP 服務。在容器的標準化上，我們採用的是單容器模式，這樣做的好處是每個 container 間互不影響，程式是作為容器的一號程式存在，一旦有問題 k8s 會自動把服務拉起，另外也便於資源的複用。富容器的模式是把所有的程式都放在一個容器內，這樣看似方便，能實現業務的無縫平滑的快速上雲，但無論從未來的維護效率、安全還是健康檢查、服務彈性上看都有問題，是中間態，違反了容器單一功能原則，也不符合雲原生的理念。

![](https://qcloudimg.tencent-cloud.cn/raw/6ac8867e0d37c5d5aa3506b3c570571a.png)

- PHP 的服務將 nginx，pfp-fpm，業務程式碼都打成了獨立的 container，程式碼透過檔案共享的形式共享給 php-fpm 的 container 實現。

- Go 服務較簡單，採用常規的應用 container + sidecar 的標準化容器。

- 演算法服務主要是模型，模型檔案掛載到 cephfs 上，共享給 C++ 服務的容器使用。

知幾在服務部署的過程中，積累了一些實踐經驗，透過雲原生的對資源利用的優勢，提升資源的利用率，降低運營成本。針對不同場景最小例項的配置如下：

- 測試環境、預釋出環境流量較少，統一0.1核0.25G，1例項。

- 生產環境，業務後臺服務採用1核2G，2例項。

- 生產環境，演算法後臺服務採用8核16G（個別如線上推理服務會採用32核以上的機器）。

透過降低單 pod 的 CPU，MEM request，滿足日常運營需求，流量高峰期則透過 stke 的 HPA 能力來滿足業務的需要，使日常 CPU 利用率能達到40%。由於 HPA 會導致業務容器的擴縮容，如果流量在服務未完成啟動時接入或者流量還在訪問時接銷燬 pod，會導致流量的損失，因此需要開啟就緒檢測和 prestop 配置。

這裡需要注意的是，就緒檢查的啟動延時設定不易過短，這樣系統會認為 pod 啟動失敗而不斷重啟，導致服務無法正常啟動。

![](https://qcloudimg.tencent-cloud.cn/raw/582d345bf33420e4baa172e8b87b95c9.png)

![](https://qcloudimg.tencent-cloud.cn/raw/4da2996778eed2c90cb0dd38a1fd11a6.png)

此外，stke提供的其他特性可以很好的滿足知幾的業務需求：

- 提供鑑權流程，可以在 pod 拉起時，動態的申請 mysql 等依賴的許可權，規避繁瑣的許可權申請流程。

- configmap 可解決配置服務配置更新的問題。

- 可對核心進行調優，業務可根據服務、流量的特點針對性的對核心引數進行最佳化，如 net.core.somaxconn, net.ipv4.tcp_tw_reuse 等等。

當前知幾線上上部署了超過 1w 核，支撐知幾 Sdk，第五人等多個應用服務，整體的利用率在40%左右。

### HPA

STKE 提供的 HPA 能力能夠很好的滿足知幾對擴縮容的需求，知幾同時使用了定時 HPA 和動態 HAP 滿足不同的場景：

- 針對突發流量， 知幾採用 CPU request 和記憶體 request 作為觸發擴容的條件
- 節假日和週五、六晚未成年人遊戲上線，知幾採用周定時 HPA 提前擴容

![](https://qcloudimg.tencent-cloud.cn/raw/867df1c29dedfd86467874f97b82243f.png)

這樣很大程度上減少了開發、運維同學面對運營活動和突發流量時的心智負擔，提高了服務穩定性。特別是定時 HPA，可以很方便的滿足知幾在未成年人保護方面對擴縮容的要求，系統可以在特定時間段完成系統容量的擴容和縮容，在保證系統平穩應對流量的同時也不會造成對資源的浪費。遷移上雲後，知幾透過這種方式保證了週末時段和線上多場運營活動的平穩進行。

![](https://qcloudimg.tencent-cloud.cn/raw/3081489ba3093eb5c5385bc50d7e0dfd.png)

### 可觀測性

系統的可觀測效能夠讓開發同學根據系統輸出快速監控、定位問題。可觀測性可以從 Metrics、Log、Trace 三個方面來看。
 - Metrics，知幾服務大部分對接的是 Monitor 系統，透過自定義 metircs 上報實現模調資訊、服務狀態、業務等指標的監控，知幾封裝了 Monitor 的標準庫實現指標模板的標準化和上報。Monitor 上報需要透過 http 請求獲取上報的 ip 再將資料透過 tcp 形式傳送到 Monitor 側，這種形式的上報對業務並不友好，Monitor 當前也已不再接入新的業務，目前知幾正逐步將 Metrics 遷移到智研監控系統，trpc 提供外掛接入智研監控能力。
 - Log，早期知几上雲時採用的 filebeat 採集日誌，現在 stke 提供了統一的日誌資料解決方案 CLS ，可以方便的進行日誌採集、儲存、檢索，運維成本較低，體驗較好。
 - Trace，知幾接入天機閣來對請求做 traceing，記錄系統的請求鏈路等上下文資訊。透過 traceId 對請求進行標記染色很大程度上提升了問題定位的效率。在此基礎上，知幾同時也在嘗試 [dapr](https://github.com/dapr "dapr") 這類新的分散式應用開發元件，dapr 提供的可觀測性的無感知接入，相比天機閣等侵入式的接入方式，成本更低。

![](https://qcloudimg.tencent-cloud.cn/raw/d93a2794491a4cef21f7762e41c9e7c6.png)

## 總結

知幾整個上雲遷移的過程隨著公司雲原生體系的基礎設施的完善在不斷的完善和最佳化，公司在相關領域的共建使得業務在實施過程中有了更多的選擇。希望知幾的實踐能給更多的業務團隊帶來價值。未來在雲原生的深入實踐方面，團隊還會在雲原生標準化方向上（mecha 理念）做出更多的嘗試。

## 關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

#### 福利：

①公眾號後臺回覆【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號後臺回覆【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 效能最佳化實踐、最佳實踐等系列。

③公眾號後臺回覆【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》

④公眾號後臺回覆【光速入門】，可獲得騰訊雲專家5萬字精華教程，光速入門Prometheus和Grafana。

最佳案例 | 遊戲知幾 AI 助手的雲原生容器化之路

相關文章