資源利用率提高67%，騰訊實時風控平台雲原生容器化之路

導語

隨着部門在業務安全領域的不斷拓展，圍繞着驗證碼、金融廣告等服務場景，騰訊水滴作為支撐業務安全對抗的實時風控系統，上線的任務實時性要求越來越高，需要支撐的業務請求量也隨之增加。對於業務快速上線和資源快速擴縮容的需求，且公司自研上雲項目往全面容器化上雲方向推進，水滴風控平台開始進行自研上雲的改造。本文主要針對騰訊水滴平台上雲過程中的實踐總結，希望對其他業務遷移上雲有一定參考價值。

水滴后台架構

水滴平台主要是用於業務安全對抗的高可用、高性能、低延時的實時風控策略平台，提供一系列的基礎組件給策略人員進行構建策略模型，能夠幫忙策略人員快速地完成策略模型的構建和測試驗證。
水滴系統架構如下圖所示：

水滴實時風控平台系統主要由配置處理模塊和數據處理模塊兩部分組成。

配置處理模塊主要由前端 web 頁面、cgi 、mc_srv 和 Zookeeper 等組成。策略開發人員通過在水滴前端頁面進行策略模型的編輯、策略任務的創建、上線和更新操作，構建完成的策略模型信息以 json 格式通過 cgi 和 mc_srv 接口存儲到 Zookeeper 數據中心，數據處理模塊通過 agent 拉取 Zookeeper 上不同業務對應的策略信息。

數據處理模塊主要由 access、engine 和外部系統等構成，核心處理邏輯為 engine 模塊。不同業務啟動獨立的 engine 實例以確保業務間的隔離，業務數據請求通過發送到指定北極星服務地址或者 ip:port 地址，由 access 接入層接收請求數據后根據任務號轉發到對應任務的 engine 實例上，存在外部系統訪問組件的情況下 engine 會將請求數據查詢外部系統。

自研上雲實踐

在水滴平台改造上雲過程中，先對 TKE(Tencent Kubernetes Engine) 平台進行了特性熟悉和測試驗證，並梳理出影響服務上雲的關鍵問題點：

1. Monitor 監控系統與 TKE 未打通，繼續采用 Monitor 指標監控系統的話將需要大量的人工介入；
2. 應對突發流量情況需要人為進行擴縮容，過於麻煩且不及時；
3. TKE 支持北極星規則，原有 CL5(Cloud Load Balance 99.999%) 存在部分問題；

針對上述自研上雲的關鍵問題點，我們分別從指標改造、容器化改造、流量分發優化等方面進行改造優化以保障業務服務上雲順利。

指標監控改造

騰訊水滴平台采用 Monitor 監控系統進行系統指標視圖查看和告警管理，但遷移上雲過程中發現 Monitor 監控指標系統存在不少影響上雲的問題點，為了解決原有 Monitor 指標監控系統存在的問題，我們將指標監控系統由 Monitor 監控系統改造為智研監控系統。

Monitor 監控系統問題

1. TKE 未與 Monitor 監控系統打通，雲上實例 ip 地址發生變化時需人工添加對應容器實例 IP 到 Monitor 系統中，且雲場景下實例 IP 頻繁變動難於維護
2. Monitor 指標針對 NAT 網絡模式下的容器實例指標無法實例級別的區分，NAT 網絡模式下相同屬性指標，不利於實例級別的指標查看
3. Monitor 監控系統靈活性較差，有新的屬性增加時需要申請屬性 ID 並調整更新代碼實現

智研指標改造過程

Monitor 監控指標系統的指標上報主要是屬性 ID 和屬性指標值，針對不同指標需要預先申請屬性 ID ，在平台系統實現過程中集成 Monitor SDK 進行不同屬性ID的埋點調用。如：不同任務請求量指標需要預先申請屬性 ID

在使用智研指標改造過程中，我們平台系統實現中集成了智研 Golang SDK ，將原有的 Monitor 指標上報進行了智研調用改造，智研指標改造過程中最重要的是從 Monitor 系統的單屬性指標思路需要轉換到多維度指標下，需要對智研維度和指標概念有一定的理解和指標設計。

如：設置任務維度，任務取值通過調用上報實現

智研指標和維度設計：
智研的指標在實現改造過程中，最主要是理解指標和維度的含義。

指標： 作為一種度量字段，是用來做聚合或者相關計算的。

維度： 是指標數據的屬性，通常用例過濾指標數據的不同屬性。
維度屬性采用指標數據中能夠進行統一抽象的特性，如實例 IP、任務號、組件 ID、指標狀態等維度，無法抽象成維度的屬性則作為指標屬性。智研指標改造前期，未進行合理的維度設計，導致指標和維度選擇過於混亂，不便於后續的增加和維護。

智研告警通知優化

智研指標改造完成后，我們對平台側和業務側的指標告警進行區分，將業務側相關的指標告警通過告警回調方式直接轉發給業務側，及時通知業務側進行異常情況的處理，提高了業務側接收異常的及時性且降低了平台側處理業務側告警的干擾。

優化智研指標視圖 Dashboard 展示，將常用的智研指標視圖整合到智研 DashBoard 頁面，方便運營人員快速了解關鍵指標情況。

路由分發優化

路由分發問題

1.CL5 首次查詢某一個 SID 的節點時，容易遇到以下-9998的問題

2.CL5 SDK 無法進行 NAT 網絡模式下的就近訪問，在異地服務情況下數據請求容易出現超時情況

遷移北極星(騰訊服務發現治理平台)改造

采用 CL5 進行請求路由情況下，當容器實例采用 NAT 模式時，使用 CL5 接口無法獲取到物理機 ip 地址，從而導致請求數據就近訪問失敗。將負載均衡 API 接口由 CL5 調整為北極星服務接口后，采用北極星接口能夠正常獲取 NAT 網絡模型下容器實例所在物理機 IP 信息，從而能夠實現就近訪問。

CL5 遷移北極星過程中，將原有的 CL5 SDK 替換成北極星 polaris-go(Golang 版本 SDK)
北極星 polaris-go 使用示例：

//***********************獲取服務實例***************************
// 構造單個服務的請求對象
getInstancesReq = &api.GetOneInstanceRequest{}
getInstancesReq.FlowID = atomic.AddUint64(&flowId, 1)
getInstancesReq.Namespace = papi.Namespace
getInstancesReq.Service = name
// 進行服務發現，獲取單一服務實例
getInstResp, err := consumer.GetOneInstance(getInstancesReq)
if nil != err {
   return nil, err
}
targetInstance := getInstResp.Instances[0]
//************************服務調用上報*************************
// 構造請求，進行服務調用結果上報
svcCallResult := &api.ServiceCallResult{}
// 設置被調的實例信息
svcCallResult.SetCalledInstance(targetInstance)
// 設置服務調用結果，枚舉，成功或者失敗
if result >= 0 {
   svcCallResult.SetRetStatus(api.RetSuccess)
} else {
   svcCallResult.SetRetStatus(api.RetFail)
}
// 設置服務調用返回碼
svcCallResult.SetRetCode(result)
// 設置服務調用時延信息
svcCallResult.SetDelay(time.Duration(usetime))
// 執行調用結果上報
consumer.UpdateServiceCallResult(svcCallResult)

容器化改造

根據水滴平台架構圖可知，業務方在水滴平台創建不同的任務后，水滴平台上會啟動不同的 engine 實例進行對應任務的計算操作，水滴平台任務與水滴任務 engine 實例呈1：N 關系，任務越多需要部署上線的 engine 實例越多。為了快速地上線不同的水滴任務 engine 實例，我們需要能夠確保任務對應的 engine 實例快速的部署上線，因此 engine 實例模塊進行容器化和自研上雲能夠提升運營效率。

水滴平台數據處理模塊隨着請求量的變化，需要對 access 實例和 engine 實例進行擴縮容操作，因此對 access 和 engine 實例會進行頻繁地擴縮容操作。
水滴數據處理模塊架構圖：

物理機部署情況

1. 任務創建：新增加任務情況時，需要申請新任務對應的北極星名稱服務地址，將任務的 engine 進程部署在不同的物理機上啟動，並手動將 engine 實例與北極星名稱服務綁定，需要人工手動進行進程的啟動和管理、添加和修改對應的負載均衡服務，管理復雜，運維成本高

   

2. 任務升級：任務程序升級過程，需要將任務對應的所有 engine 進程程序進行更新，並重啟所有相關的 engine 進程

   

3. 任務擴縮容：任務進行擴容過程，需要進行在物理機上部署並啟動新的 engine 進程，再將新進程實例加入到對應的北極星名稱服務中；任務進行縮容過程，需要將縮容進程先從北極星名稱服務中剔除，再對相應 engine 進程進行暫停。服務擴縮容流程類似於服務升級過程。

TKE 平台部署情況

1. 任務創建：新增加任務情況時，需要申請新任務對應的北極星名稱服務地址，再在 TKE 平台進行任務對應 engine 應用實例創建

   

2. 任務升級：任務程序升級過程，更新任務對應 engine 實例鏡像版本即可

   

3. 任務擴縮容：任務進行擴縮容過程，在 TKE 平台頁面通過設置 HPA(Horizontal Pod Autoscaler) 自動調應用實例的擴縮容

   

雲原生成熟度提升經驗

1.對不同的業務類型進行服務划分，CPU 密集型服務創建核數大的 Pod 服務，IO 密集型服務(目前主要應對瞬時流量業務情況，網絡緩沖區易成為瓶頸)創建核數偏小的 Pod 服務， 如 CPU 密集型業務單 Pod 取4核，而瞬時突發流量服務單 Pod 取0.25核或0.5核。

2.容器服務采用 HPA 機制，業務接入時根據業務請求量預估所需的 CPU 和內存資源，由預估的 CPU 和內存資源設置 Pod 服務的 Request 值，通常保持 Request 值為 Limit 值的50%左右。

自研上雲效果

水滴平台在進行遷移上雲過程中，自研平台遷移到 TKE 雲上后帶來了不少的效率提升。
上雲后帶來的效率提升主要有以下方面：

1. 上雲資源申請流程更加簡單快速，上雲前機器申領搬遷、虛擬 IP 申請、機器轉移等流程周期一周左右，上雲后資源申請周期縮短為小時級別
2. 機器資源利用率提高67%，上雲前 CPU 利用率約36%，上雲后 CPU 利用率59.9%.
3. 應對突發流量無需人工進行擴縮容操作，通過 HPA 機制可完成擴縮容，從人工擴縮容周期15分鍾左右縮短到一兩分鍾。
4. 業務策略部署上線周期可由2小時縮短至10分鍾。

【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！