導語

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

水滴後臺架構

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

水滴實時風控平臺系統主要由配置處理模組和資料處理模組兩部分組成。

配置處理模組主要由前端 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分鐘。

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