21 | 流量回放：保障業務技術升級的神器

什麼是流量回放？

流量就是指在某個時間段內的所有請求，我們通過某種手段把發送到A應用的所有請求錄製下來，然後把這些請求統一轉發到B應用，讓B應用接收到的請求參數和A應用保持一致，從而實現A接收到的請求在B應用裡面重新請求了一遍，這個過程，我們稱為“流量回放”。

當我們對應用邏輯有改動，但在做了單元測試和回歸測試之後，因為線上環境更加複雜，為了降低出錯的概率，可以嘗試使用流量回放。

傳統QA測試不能滿足要求的根本原因就是在於改造後的應用在上線後出現跟應用上線前不一致的行為。我們測試的目的就是為了保證改造後的應用跟改造前應用的行為一致，我們測試Case也應該儘力去模擬應用線上上的行為，這時最好的方式就是用線上流量來驗證，但是又不能把新的應用直接上線，所以我們可以考慮流量回放。也就是說我們可以把線上一段時間內的請求參數和響應結果保存下來，然後把這些請求參數在新改造的應用裡面重新請求一遍，對比一下改造前後的響應結果是否一致，這樣就間接達到了使用線上流量進行測試的效果。

我們常用的流量回放方案包括TcpCopy、Nginx等。

在RPC框架中，因為所有的請求都經過RPC，我們可以在RPC中拿到這些請求參數，將這些參數旁錄下來，並將旁錄結果用非同步的方式發送到一個固定的地方保存起來，這樣就完成了流量錄製功能。

在完成錄製功能後，我們需要模擬一個應用調用方，將錄製好的請求參數重新發送一遍到要回歸測試的應用裡面，然後對比錄製拿到的請求結果和新請求的結果，這樣就完成了請求回放的過程。

流量回放不是RPC框架的核心功能，但是有了這個功能以後，用戶可以更放心的升級自己的應用了。

使用流量回放，對請求有一些限制：

1. 請求是否依賴底層數據，如果依賴，那麼需要保證底層數據是一致的。
2. 請求是否與當前系統狀態或者系統時間有關係，如果相關，那麼相關依賴也需要保持一致。
3. 請求所執行的方法是否冪等，如果不冪等，很可能會影響驗證結果。

實現流量回放的設計思路：

1. 使用動態代理，切麵攔截對應的方法，獲取出入參。
2. 把攔截信息非同步轉存到線上驗證系統。
3. 通過線上驗證系統調用待驗證的防範。
4. 收集結果對比信息，設置報警功能。

22 | 動態分組：超高效實現秒級擴縮容

我們之前學習過服務分組，在調用方複雜的情況下，如果讓所有調用方都調用同一個集群，那麼很可能會因為非核心業務調用量的突增，造成整個集群都不可用了，為了避免這種情況，我們需要把整個打擊群根據不同的調用方劃分出不同的小集群，從而實現調用方流量隔離的效果，保證不同業務之間不會相互影響。

在給集群分組的時候，我們一般會選擇性的合併一些調用方到同一個分組裡，至於如何合併，並沒有統一標準，一般來說，我們可以按照應用的重要級別來劃分，讓非核心業務應用和核心業務應用不要共用一個分組，並且非核心應用之間也最好別用一個分組。

那麼我們如何為每個分組配置合適的機器數量呢？一般會通過壓測來評估服務提供方單台機器所能承受的QPS，然後再計算出每個分組裡面的所有調用方的調用總量，考慮到可能的不確定性因素，我們可以在現有調用總量的基礎上，添加一個百分比作為buffer，這個百分比一般來自經驗總結。

我們計算每個分組所需要的機器數量時，會額外增加一些機器，這樣讓每個小集群可以有一定的抗壓能力，而抗壓能力取決於預留機器的數量，這就需要在成本和可用性之間做權衡。

當某個分組的調用方流量突增，而分組所預留的空間不能滿足當前流量要求時，我們可以看一下其他分組的服務提供方是否有富餘能力來幫忙處理請求，這也就是動態分組的含義。

因為服務提供方的分組信息以及機器節點都保存在註冊中心裡面，我們可以在註冊中心裡面將部分實例的別名改成我們想要的別名，然後通過服務發現進而影響到不同調用方能夠調用的服務提供方實例集合，換句話說，我們可以通過控制註冊中心，來管理服務調用方可以觸達的服務提供方以及分組節點的信息。

通過直接修改註冊中心數據，我們可以讓任何一個分組瞬間擁有不同規模的集群能力。我們不僅可以實現把某個實例的分組名改成另一個分組名，還可以讓某個實例分組名變成多個分組名，這就是我們在動態分組裡面最常見的兩種動作：追加和替換。

我們還可以利用動態分組解決分組後的每個分組預留機器冗餘的問題，我們沒有必要把所有冗餘的機器都分配到分組裡面，我們可以把這些機器做成一個共用的池子，從而減少整理預留的實例數量。