背景介紹
容器化遷移目的
隨著易盾反垃圾業務的迅速發展，業務叢集的規模也在急劇增長，傳統的透過物理機來部署的方式在靈活度上越來越達不到要求，主要痛點包括但不限於：資源利用率低、叢集擴容/縮容成本高、業務叢集混合部署導致故障不隔離等，因此，急需一種更好的方式來提升運維和環境管理的效率。時至今日，容器化的手段已經非常成熟，並且可擴充套件性、敏捷性、故障隔離等方面正是容器化的優勢。同時，網易集團的雲端計算部門基於 K8S 研發的輕舟平臺與運維團隊研發的諾亞平臺為此提供了強大的底層支援技術，易盾業務叢集容器化可謂水到渠成。
容器化遷移架構
遷移的架構如下圖所示，上層 nginx 分為杭州和建德兩個叢集，方便在不影響客戶使用的情況下進行整體功能迴歸。業務服務全部遷移，涉及應用叢集 100+。底層中介軟體、ddb 和 es 公用同一叢集，保證資料的一致性。
容器化遷移流程
整個遷移流程一共分為方案設計、模組部署、功能測試、效能測試、故障演練、流量對比、灰度切流、DNS 切換等八個步驟，下面我們主要圍繞流量對比這個步驟進行展開。
痛點與困境
驅使我們去做流量對比的原因一共有四個。
• 第一，遷移模組多、風險高，反垃圾的檢測鏈路很長，中間涉及到很多模組，中間任何一個模組出問題都會影響最終返回給客戶的檢測結果，我們的保障覆蓋範圍需要包括整個鏈路。
• 第二，補充線上迴歸用例覆蓋不到的場景，目前線上迴歸用例透過 Goapi 維護，覆蓋了所有業務以及檢測器，但是做不到百分百覆蓋到所有的線上邏輯。需要額外的手段去做補充。
• 第三，開發側的訴求，在遷移方案的評審階段，開發就提出訴求，上線前希望能透過某種方式比對新老叢集的流量，用大資料量去儘量覆蓋到所有場景。
• 最後一個原因缺乏效果測試手段，希望透過這個流量對比做到對效果測試的迴歸。
流量對比實踐
方案選型
引流平臺
引流平臺是一個基於使用者實際使用行為和使用資料，作為測試用例和資料的全自動介面效能工具。平臺透過將線上使用者的真實流量複製並運用於自動化迴歸測試當中，期間透過創新的 Mock 機制，可以使用線上資料在測試環境實現增刪改查所有型別的介面測試。使用海量使用者資料，實現業務邏輯的高覆蓋和精準覆蓋，是現有介面測試手段一種有效增益手段。引流平臺不僅能夠實現低成本的日常自動化迴歸，同時能透過它提供的擴充套件能力支援系統重構升級的自動迴歸。
引流平臺的優勢：
• 不需要額外的開發成本；
• 能獲取到使用者真實流量；
• 視覺化操作、功能全面；
引流平臺的劣勢&風險點：
• 程式碼增強後應用響應時間增大、TPS 降低（易盾客戶對響應時間非常敏感）；
• 只支援單應用流量錄製，不支援全鏈路；
• 不支援根據條件獲取指定流量；
考慮到對應用效能影響以及不支援全鏈路，沒有選擇引流的方案，但是這種思路值得我們去借鑑。
自研工具
- 確定目標
P0需求：
• 不影響線上應用效能、RT、TPS 等；
• 支援全鏈路流量對比；
• 支援歷史流量回放；
• 支援指定流量獲取；
P1需求：
•儘量低的開發成本；
•支援結果報告；
2. 功能拆分&流程設計
功能拆分為四個模組，分別是資料獲取、資料傳送、結果比對和報告生成，各模組之間的互動流程如下圖所示：
功能實現
樣本獲取
- 樣本來源
為了保證樣本資料的真實有效並且能保持資料的新鮮度，直接把線上資料作為來源之一。QA 的音影片倉庫也是資料來源之一，倉庫裡面儲存了構造的各種格式和時長的音影片資料。除此之外還支援 EXCEL 上傳的方法，上傳以及標記好的 Case。
- 樣本篩選
想要獲取指定型別的資料，可以透過不同欄位的組合設定，在獲取資料的時候，會根據欄位屬性進行篩選，保證獲取線上樣本豐富度。譬如：
targetId=8544&hitType=10&spamType=100&requestRegion=cn-beijing
指定了獲取業務 ID 為 8544 從北京傳送的資料且命中了規則檢測器且垃圾型別為色情的資料，最後獲取的樣本都符合上述條件。
- 樣本處理
由於原始資料的欄位很多，有一些欄位不影響檢測效果，譬如 callback、publishTime 等。這些抽取的樣本會存資料庫，為了減少樣本大小，需要將這些額外欄位處理掉。有些場景需要和樣本歷史命中結果做比對，因此這裡我們還要把原來的命中資訊作為驗證欄位存起來，後面用來做比對。
- 模組流程設計
資料傳送
方案選型
傳送資料就是透過什麼方式把什麼資料往哪裡發，資料我們透過上面樣本獲取的模組已經拿到了，接下來就是解決傳送方式和傳送地址的問題，這個功能正好是 Goapi 所具備的，秉承著不重複造輪子的理念，在評估過自研和直接用 Goapi 的優劣，我們直接透過 Goapi 的 OpenApi 介面來完成資料傳送的操作。
互動流程
平臺與 Goapi 互動流程大致分為 6 個步驟：
• Goapi 建立資料驅動的場景用例/單用例，後面資料傳送都是基於此用例；
• 獲取用例 ID，在平臺新增此用例（後端會根據 ID 呼叫 Goapi 介面查詢用例資訊）；
• 更新資料驅動資料（步驟 3~6 是迴圈，直到所有樣本跑完）；
• 觸發用例執行；
• 輪詢任務執行狀態；
• 獲取執行結果並儲存；
詳細互動流程如下圖：
結果比對
多環境結果比對
樣本在多個環境執行完成以後，彙總執行結果根據樣本 ID 和執行域名進行分組，隨後根據匹配模式和匹配欄位進行匹配，最後生成比對的結果存在資料庫中。多環境比對的方式適用於機器資源多，環境部署方便，底層依賴的中介軟體是同一套場景。
歷史結果執行比對
樣本執行完成以後，獲取原始樣本的預期結果，將最新結果和預期結果做對比，最後生成比對的結果存在資料庫中。歷史結果比對的方式適用於環境只有一套但是樣本的預期結果比較穩定的場景。
遇到的問題
GOAPI
• GOAPI 資料驅動只支援上傳 EXCEL 更新資料 => 推動平臺支援介面方式更新資料；
• 資料驅動的執行方式是序列、耗時太高 => 推動平臺可以設定執行併發數；
樣本提取
- 提取樣本資料部分欄位不存在導致執行串資料 => 增加樣本欄位補全邏輯；
- 反垃圾圖片樣本失效的情況=> 增加判斷圖片失效邏輯；
- 文字特殊字元導致 GOAPI 加密有問題 => 增加特殊字元過濾邏輯；
任務執行
- 失敗 case 重跑流程複雜 => 增加一鍵重跑；
- 減少人為操作帶來誤差 => 多個環境交替執行，可人工設定驗證數量；
- 任務觸發無法中斷 => 增加中止操作；
收益和產出
• 兩個專案進行落地（反垃圾&反外掛）；
• 反垃圾建德容器化遷移回歸發現兩個問題：
1.【建德遷移】文字建德/線上對比迴歸部分 case 不一致，文字分類模型版本不一致導致；
2.【建德遷移】規則 scheduler 沒有部署（怕影響線上），導致修改規則沒重新整理 。
未來規劃
• 最佳化非同步介面的流程；
• 最佳化場景用例存在上下文依賴導致並行執行串資料的問題；
• 探索在反垃圾測試迴歸和線上迴歸落地；
• 支援更多匹配方式；
• 持續最佳化執行慢的問題。