一、流量比對提出背景
我們在進行程式碼重構以及需求迭代時，在上線之前需要進行一輪、二輪以及迴歸測試，如果業務場景比較複雜，那麼就會存在以下幾個方面的問題：
（1）測試的週期就會相應的拉的比較長；
（2）隨著業務功能的不斷迭代，測試案例不一定能夠覆蓋全，一些冷門的隱藏比較深的問題不一定可以及時發現，迴歸測試難度逐漸增大；
（3）影響釋出頻率；
（4）開發以及測試人員消耗在測試階段時間比較長，不利於騰出時間進行下一步的業務迭代、技術改造等工作；
（5）程式碼質量很多時候依賴人為的code review，迭代程式碼行較多，code review佔用時間較多；
為此，我們能否解決這些痛點，使得我們的工作效率得到一定的提升，以及我們程式碼的質量得到一定的保證，是我們需要思考的一個問題。業內的做法一幫將線上的流量引入對比機器，將生產結果和對比機器進行實時對比，及時暴露問題，開發和測試能夠及時發現並進行修改。
二、和流量回放平臺的對比
目前業內的流量回放平臺基本都是基於流量的錄製，將流量引到測試環境進行回放，回放後分析系統存在的問題，在一定程度上只能釋放一些迴歸測試的資源，並不能使我們開發中存在的問題在提測之前可以及時暴露，提前讓開發人員解決問題，提高程式碼提測的質量，我們的目標是要做到即使沒有測試參與，也要保證我們的程式碼質量，如果對線上存量業務的有影響，能夠及時得到反饋，形成一個閉環處理，一個實時性的比對方案是很有必要的。
三、流量比對方案
對於一般的業務系統，我們比對的維度一般包括資料庫落地資料、mq訊息、介面呼叫請求引數以及輸出四個維度，一般情況下在對比流量是整個生產流量50%情況下，基本可以覆蓋生產案例場景，在此基礎上針對這三個維度對比結果一致率接近100%，那麼我們的上線的迭代版本對存量業務的影響是可以得到保證的。主要思路是構建請求報文，執行請求再到分析比對結果。
（1）整體架構
當生產應用處理完對應請求時，所有涉及介面的呼叫，mq訊息的傳送等埋點資訊都會被記錄到ES（鑑於ES是分散式、高擴充套件、高實時的搜尋和資料分析引擎，通過其提供的介面，可以很方便的獲取埋點資訊），這時候會發出一條mq訊息，對比工具監聽mq訊息進行消費，根據對應的訂單資訊，查詢生產訂單資料並進行mock，然後呼叫對比應用，對比工具延遲一定時間後，根據需要對比的內容進行對比，將比對結果傳送ES，可以根據ES對比結果埋點檢視對比一致率以及不一致的具體原因。
注：生產應用：實際的生產應用叢集
對比應用：我們的迭代版本部署叢集
對比工具：單獨專門用來跑對比的一個應用
（2）資料埋點
資料買點是比對的前提，包括介面請求的埋點、q訊息的埋點，輸入請求的埋點，後續對比工具讀取資料進行比對
（3）資料mock
對比應用不能實際操作db以及和上下游系統進行互動，所有資料需要進行mock，mock的資料主要是呼叫下游介面的應答資料，mock的資料可以寫入redis，對比應用在處理業務邏輯時，可以直接讀取redis相應的mock資料作為返回。
（4）對比配置+資料對比
對比配置一般配置在配置中心，可以根據實際對比的維度進行配置化管理,對比表欄位的對比，比如一些時間，可以配置成忽略欄位，介面和mq裡面的一些引數也可以進行配置化忽略對比，比如訂單號、傳送時間之類。
（5）結果一致率分析
對比工具可以將對比結果傳送至ES，我們可以通過ES根據具體的埋點actionType篩選對應的比對結果，一致率和不一致原因。
四、總結
線上流量對比方案總體是基於基本的業務埋點，對一個業務流程裡面所涉及到的具體介面，mq訊息都需要有一個全面的梳理，需要指出的是，想要真正利用實時對比方案提前知道迭代風險的前提時，我們可以隨時釋出對比應用，這一點上面應該不要做限制。 我們的願景是在即使沒有測試參與的情況下，開發也可以保證上線程式碼的安全性，開發自己可以形成閉環。此對比方案存在一些優缺點如下：
優點
（1）可以及時發現程式碼重構以及版本迭代改動中存在的問題，並及時修復，不必等到提測之後再由測試發現，潛在問題可以提前暴露。不必過度依賴測試來發現問題；
（2）一定程度上釋放回歸測試的資源；
（3）保證整個研發過程的質量；
（4）可以提升釋出頻率；
（5）對比應用不需要單獨搭建一套對比資料庫用於對比，降低對比成本；
（6）對比應用和對比工具作為非核心應用，隨改隨發，有一定的靈活性；
（7）對比內容靈活化配置；
缺點
（1）對程式碼有一定程度的入侵，需要發出一個對比的mq訊息
（2）對於增量業務，因為其沒有對比參考物件，目前還沒有有效的方式確保程式碼質量，只有通過ut單元測試、程式碼code review等手段進行輔助。
文/HUZHIMIN
關注得物技術，做最潮技術人！