這種針對生產的持續流量生成叫什麼？
我們服務的流量並非完全可預測。為了幫助保持服務略微過度配置，並提前警告因流量增加而導致的任何性能下降，我們維護了一種“連續緩衝負載生成器”。這會在使用者流量之上對我們的生產 API 產生持續的負載。如果我們發現服務正在降級，它會自動關閉，理想情況下，我們有一點時間來找出問題並在自然使用者流量與導致服務降級的增強流量相匹配之前擴大規模。一旦服務再次穩定，緩衝負載就會重新打開。
雖然我們一直將這種持續的流量生成稱為“持續負載測試”，但這似乎是令人困惑的措辭，並且很難與“實際”負載測試（這就是我稱之為具有定義的開始和結束的實驗，載入模式，以及最後的二進制通過/失敗結果）。我幾乎想將其稱為“金絲雀流量”，因為我們會發送額外的流量以在使用者遇到問題之前警告我們，但這與業內對金絲雀含義的一般理解不符.
這是在負載平衡、自動縮放等之上的附加策略。我們不會嘗試在這裡替換任何行業標準的流量管理步驟。
我懷疑這是不知道Google正確用詞的情況，所以：
- 如果這是其他地方使用的模式，它叫什麼？
- 或者，如果沒有其他人這樣做，為什麼不呢？我完全願意相信通過其他類型的測試或監控可以更好地獲得這個結果。
合成或主動監控是模擬應用程序實際執行的人工負載的術語。在測量應用程序性能的情況下。
模擬您的實際負載非常棒。但是，在生產中消耗相當大一部分資源的效率並不高，它會消耗資源。更重要的是，自動禁用機制對於保持良好的性能變得至關重要。取而代之的是，始終將油門降低到最低水平，並繼續測量響應時間和錯誤率。永遠不要停止測量，因為降級會顯示事件對使用者的影響。
現實的負載生成器有利於測試和容量規劃。在測試環境中配置不同的計算實例大小，並推動負載直到它崩潰。作為高可用性測試或滾動升級的一部分，臨時添加一些負載以驗證原本空閒的系統。
確定響應時間目標是什麼。了解每秒多少請求是安全的。將自動縮放或警報設置為可操作的門檻值。
衡量服務水平目標以及了解限制將為您提供進行適當容量規劃的工具。無需人為地消耗您的緩衝容量。