【3.工程開發】-仿真環境/流量回放/全鏈路壓測/故障注入

本文涉及工程中測試/穩定性相關的一些內容，全文見：https://segmentfault.com/a/11...
1.仿真環境是用線上流量轉發到下線環境作線下實驗。重點在於流量引入和數據/隊列/push,im服務的隔離
2.全鏈路壓測 是用大量與線上流量相似的流量請求到線上，檢測故障。重點在於大量數據與真實流量的模擬，壓測數據隔離
3.流量回放 能夠用來定位問題，將有問題請求百分百還原到線下機器，對控制讀寫接口返回用線上真實mock，可不斷重複。重點在於線下請求劫持到回放機器進行mock，和mock數據匹配。
4.故障注入也被叫防火平臺，用於故障主動注入演練服務保護有效性等。
由於都是公司未開源東西。這裏都會涉及到引流和數據隔離，先重點說下這兩個的通用解決，而後只簡單介紹四個的實現。

引流：

1.通訊框架實時引流：

• 方案：
  框架層根據包頭中的額外信息，判斷哪些流量須要轉發到仿真環境，只轉發須要轉發的流量，且實時轉發
  判斷轉發條件在配置平臺下發
  鏈接池，隔離目標server。
• 優勢：能夠按業務細粒度引流
• 缺點：沒法回放

2.收到請求後寫入MQ，引流系統消費

• 優勢：能夠重讀消費
• 缺點：請求密集度和線上不一致

3.日誌回放（全鏈路壓測）

• 方案：收集線上日誌，經過日誌還原請求
• 優勢：業務無侵入
• 缺點：日誌還原複雜

4.TCPCOPY

• 方案
  基於數據鏈路層/網絡層抓包回放
  tcpcopy經過libpcap(數據鏈路層)或rawsocket(IP層)抓包

  
  assistant server爲了截獲響應給TCPCopy，不會回給online server

• 優勢：業務無侵入
• 缺點：網絡層就沒法按照業務選擇

5.TCPDUMP流量（流量回放）

• 方案
  單獨機器採樣TCPDUMP錄製流量，編寫工具讀取並解析.cap文件，實現流量回放
• 優勢：能夠屢次回放請求
• 缺點：解析.cap文件+cap文件存儲+tcpdump對耗時稍有影響

數據隔離

1.所有單獨數據配置。

數據同步+大量機器

2.數據訪問流量劫持

寫本地或寫丟棄，讀線上。

• 本機訪問線上數據流量劫持方案：iptable
  原理
  Netfilter是Linux用於網絡數據包過濾的模塊，它有四個表五個鏈。Iptables是用於向這Netfilter添加規則的用戶空間程序。
  E.g.
  // 將本機發往9613的tcp包轉到100.90.160.37的9613端口
  iptables -t nat -A OUTPUT -p tcp --dport 9613 -j DNAT --to 100.90.160.37:9613
  // 將本機非root用戶發往beststg集羣3000端口的流量重定向到本機9001端口
  iptables -t nat -A OUTPUT -p tcp --dport 3000 -m set --match-set beatstg dst -m owner ! --uid-owner 0 -j REDIRECT --to 9001
  // 將本機發往100.69.238.129 9000端口的tcp流量丟棄
  iptables -A OUTPUT -p tcp -d 100.69.238.129 --dport 9000 -j DROP
• 須要數據劫持到單獨模塊
  redis
  mq topic、回調地址

須要考慮數據

redis,mq,mysql

仿真環境

• 通訊框架實時引流。
• 對數據iptable劫持
  1.redis:劫持到RedisRouter
  2.mq
  1）發出去的請求帶回調地址的（好比bridgemq），劫持到mqproxy。替換請求中的回調URL爲目標環境URL
  2）topic都改爲線下的，發送和的訂閱都改

全鏈路壓測

• 模擬數據：日誌回放。
  按照接口配置順序取高峯期幾小時數據。對請求中部分數據替換爲壓測
• 所有單獨數據配置：
  壓測用戶信息單獨存儲，單獨存儲。mysql，redis加註釋方式.mq的topic統一加前綴
• 施壓工具開發
  用的NIO
• 總體架構

  
  ultron-server：web控制檯，負責新建壓測計劃、壓測任務，調整壓測，修改壓測配置，查看壓測監控和性能數據等。
  daemon：遠程調起agent。ultron-server新建壓測任務只會在數據庫添加一條待運行的壓測任務記錄，並將空閒agent分配給壓測任務，ultron-server自己不負責發壓，而後daemon會從數據庫讀取待運行的任務以及給任務分配好的agent，而後經過shell命令遠程調起agent。
  datasource: 即數據源，全鏈路壓測時向agent提供司乘基本信息和路線信息，http日誌回放時向agent提供日誌日誌文件。datasource起了一個定時任務從redis(全鏈路壓測)或者日誌文件(http日誌回放)讀取數據，緩存到內存的隊列裏面，當壓測agent啓動後，從datasource的內存隊列裏面拉取壓測數據。
  redisfiller: 將匹配好的路線信息和司乘數據寫入redis，供datasource拉取數據用。

流量回放

• TCPDUMP流量
  由於mock方案，須要保證串行。http:nginx+lua; thrift:server改。選則一臺線上機器作串行到tcpdump機器便可
• 數據iptable劫持
  劫持到proxy轉發到mock機器。數據tcp級別的mock。配置白名單iptable不劫持放過
• mock匹配
  徹底串行。1s內單個請求全部子tcp都結束後才記錄下一個，直接用時間匹配（tcp級別好比訪問redis,mysql沒法用traceid等，用線程id各語言不通用）

故障注入

收益

降級預案的有效性：下游依賴出現故障時，預案能及時應對，將系統的 SLA 維持在相對較高的水平，不因下游故障引發當前服務可用性的故障
監控報警：校驗報警是否符合預期：是否報警、消息提示是否正確、報警的實效、收到報警的人是否預期
故障復現：故障覆盤的後續todo項落地效果如何，經過必定時間後對故障的重現和驗證，完成閉環
架構容災測試：主備切換、負載均衡、流量調度等容災手段健壯性如何，提早發現並修復可避免的重大問題
參數調優：限流策略、報警閾值、超時設置的調優
故障模型訓練：有針對性的製造一些故障，給故障定位系統製造數據

故障全景

1.依賴服務端：故障規則，依賴分析
依賴模型包括關係、流量、強弱三個組成部分：
依賴關係：定義依賴的方向，我依賴誰，誰依賴我
依賴流量：定義每一個應用、服務、方法調用的次數
依賴強弱：定義依賴的鬆緊程度
對依賴的治理就是持續穩定的拿到關係、流量、強弱的數據。
架構拓撲可視化：自動探測應用的拓撲結構，繪製組件間依賴關係和應用對基礎架構的依賴
2.依賴插件：
調用攔截，業務識別，注入
結果輸出：依賴報表，用例軌跡，插件管理等
https://help.aliyun.com/docum...
3.注入：

• 應用：外部超時/響應變慢等。接口，DB延遲/鏈接滿/熱點,redis緩存熱點,kafka，中間件的負載均衡/限流等
• 資源：cpu,內存，磁盤你，io。網絡延時等
• 程序：cpu,mem,iptable.
  流量劫持，解析，過濾，模擬丟棄和延時和放到目標ip(直接重建socket複製緩衝區),只能針對特定協議作延時和丟棄和轉發，和nginx功能差很少，看解析協議的能力了，好比http能夠到url的規則，redis能夠到命令，thrift能夠到xx。nginx增長響應時間插件。
  java:字節注入
• 注入方式
  隔離環境，複製流量和數據
  影響業務隔離：隻影響要發生故障的請求，其餘業務流量放過，用中間價擺脫對環境的依賴
  注意混部的影響

服務保護

降級、熔斷，服務（1.目前寫sdk在代碼中讀配置直接不發送就返回，分協議處理。2.統一劫持返回）和功能（開關配置）
限流，nginx改;統一入口流量劫持(目前thrift沒作，能夠和nginx同樣令牌桶)
預案管理，開關監控