1、交易流程容災及測試策略什么是容災首先來梳理下什么是系統(tǒng)容災。互聯(lián)網(wǎng)上容災的概念解釋很多，我們來看看百度百科里的解釋：從其對系統(tǒng)的保護程度來分，可以將容災系統(tǒng)分為：數(shù)據(jù)容災和應用容災 。數(shù)據(jù)容災就是指建立一個異地的數(shù)據(jù)系統(tǒng)，該系統(tǒng)是本地關鍵應用數(shù)據(jù)的一個實時復制。應用容災是在數(shù)據(jù)容災的基礎上，在異地建立一套完整的與本地生產(chǎn)系統(tǒng)相當?shù)膫浞輵孟到y(tǒng)（可以是互 為備份），在災難情況下，遠程系統(tǒng)迅速接管業(yè)務運行。數(shù)據(jù)容災是抗御災難的保障，而應用容災則是容 災系統(tǒng)建設的目標。其實，上面指的容災已經(jīng)由我們的數(shù)據(jù)倉儲和運維團隊一直在很好的進行著。而且該容災工作的目的主要 是為了預防一些不可預料的意外，比如火災

2、、地震、緊急硬件故障等等。為了保障系統(tǒng)的穩(wěn)定性和可用性，作為業(yè)務團隊的我們，我們的容災主要做什么呢？谷歌了下一直沒有 找到和我們所做的事情相似的概念，索性自己取了個名字叫業(yè)務容災。這里只討論基于互聯(lián)網(wǎng)的web業(yè) 務系統(tǒng)，業(yè)務容災主要就是指使用一定的技術手段，在極端訪問量的情況下，犧牲一小部分非主要業(yè)務功 能或者一小部分用戶體驗，保障整體系統(tǒng)的穩(wěn)定以及提供的主要功能，以保障絕大部分的用戶需求和體驗 我們的容災工作，預防發(fā)生的場景是可以預見的，比如今年的雙11、雙12 大促。現(xiàn)在我們主要分析總結下我們的業(yè)務容災主要包括哪些內(nèi)容。業(yè)務容災手段目前在集市交易系統(tǒng)中使用的業(yè)務容災手段主要有以下幾種，下面

3、一一分析。需要說明的是，開關本身不 是一種容災方式，它只是容災手段中便于人為操作而使用的某種方式，大部分容災的手段都可以使用開關 來達到目的。業(yè)務降級1、提前降級：在極端訪問的情況下，為了減少對系統(tǒng)的壓力，對于一些用戶量很小或者對用戶體驗影響極小的業(yè)務可以 進行提前關閉。可以使用到時間點自動關閉的方式實現(xiàn)，也可以使用開關提前人為的關閉。這里如果選擇 使用開關進行人為關閉，需要考慮到不同應用系統(tǒng)之間對同一個業(yè)務的協(xié)調(diào)和時間差，盡可能做到平穩(wěn)的 過渡，讓用戶完全沒有感知。2、應急降級： 應急降級主要是針對重要性稍低的業(yè)務提前完成預備降級的工作，并提供開關以備不時之需。在系統(tǒng)穩(wěn)定 的情況下正常提供功

4、能，緊急情況下可以人為臨時關閉，以保障系統(tǒng)最高優(yōu)先級的核心功能的可用性和系 統(tǒng)整體的穩(wěn)定性。數(shù)據(jù)備份為了解決數(shù)據(jù)讀取的問題，我們可以對數(shù)據(jù)進行提前備份，并在當老數(shù)據(jù)讀取出現(xiàn)異常的緊急情況下，臨 時切換到新的存儲系統(tǒng)進行讀取。需要完成的研發(fā)功能有：新存儲的數(shù)據(jù)備份功能；緊急切換開關；歷史 數(shù)據(jù)的復制。自動流控/限流自動流控主要是指，當系統(tǒng)中對某些二方應用系統(tǒng)訪問的線程數(shù)超過一定閥值的時候，進行自動限流，防 止因為二方應用響應超時太多，拖垮我們的應用。 實現(xiàn)上可以直接拋異常，用戶會感覺某功能不可用；也 可以直接忽略，讓流程繼續(xù)往下走，用戶不會有任何感知。當然，限流后是應該拋異常還是直接忽略，這個不

5、能直接憑用戶體驗來，不是說用戶感知不到就一定是最 好的。這里一定要根據(jù)具體功能點的設計來決定。比如如果查詢庫存的線程被限流了，那么就一定要拋異 常讓下單失敗，否則會引起寶貝超賣，這個對于賣家是絕對不能接受的。對于不同應用請求的流控的閥值的設置也需要再三斟酌，設置高了可能會導致極端情況下流控還沒生效， 我們的系統(tǒng)已經(jīng)被拖跨了；設置低了可能會資源浪費，導致系統(tǒng)還未達到自己的最大承受臨界點之前就已 經(jīng)犧牲了部分功能和用戶體驗。所以流控閥值的設置，需要平時在生產(chǎn)系統(tǒng)多觀察，不斷調(diào)整閥值以求達 到一個最合適的值。并提供閥值調(diào)整開關以備不時之需。備注：系統(tǒng)中不是對所有的二方應用的訪問都有自動流控，這個是需

6、要單獨添加的。對于一些重要性非常 高的應用一般不做自動流控請求攔截請求攔截是指當我們的系統(tǒng)壓力比較大的時候， 犧牲掉對我們系統(tǒng)訪問的一部分重要性稍低的請求，直接 對請求進行攔截，減少系統(tǒng)壓力，保障系統(tǒng)的穩(wěn)定性。具體攔截哪些業(yè)務方的請求，什么接口，或者接口 允許訪問的最大QPS是多少，這些最好能做成可配置化，在緊急情況下可以靈活調(diào)整。強弱依賴設計在系統(tǒng)設計時，需要考慮所有系統(tǒng)內(nèi)部訪問的其他系統(tǒng)接口為強依賴還是弱依賴。比如對于某個功能點，內(nèi)部需要調(diào)用其他系統(tǒng)的接口 A和B,如果A出現(xiàn)異常則該功能不可用，而B出現(xiàn)異常，不會影響該功能的整體可用性，那么我們需要將A設計為強依賴，B設計為弱依賴。強弱依賴

7、的設計對于系統(tǒng)整體的可用性非常重要，特別是在極端訪問量的情況下。我們要盡可能的保證系 統(tǒng)功能不受弱依賴系統(tǒng)的影響。 并且強弱依賴需要獨立的測試場景來持續(xù)保障，以防強弱依賴的設計因為 代碼的不斷改動而發(fā)生意料之外的改變。容災測試方法業(yè)務降級、數(shù)據(jù)備份、以及請求的攔截這類的容災場景一般都會有自己獨立的業(yè)務測試方法，也會有對應 的開關去控制，只需將開關設置到對應狀態(tài)，使用和普通業(yè)務測試相同的方法即可。對于自動流控的測試，可以將閥值調(diào)整的開關設置為最低值，即等同于業(yè)務的降級測試；也可以將閥值設 置為一個較低的值，并模擬依賴系統(tǒng)的請求變慢，再進行業(yè)務測試來達到觸發(fā)流控的條件。對于強弱依賴的測試可以直接模

8、擬和依賴系統(tǒng)之間的網(wǎng)絡不通，或者網(wǎng)絡變慢，從而模擬依賴系統(tǒng)返回的請求超時或者變慢的場景，再進行業(yè)務測試觀察系統(tǒng)各功能點的可用性。具體模擬網(wǎng)絡不通或者變慢超時 的方式如下：模擬網(wǎng)絡不通1、使用 iptbables 直接模擬系統(tǒng)和某系統(tǒng)之間的網(wǎng)絡不通：sudo iptables -A OUTPUT -o eth0 -d 依賴系統(tǒng)的 IP -j DROP這個命令需要在我們被測系統(tǒng)上執(zhí)行，并且將需要模擬的依賴系統(tǒng)的IP替換掉。它的主要作用是將我們被 測機器往依賴系統(tǒng)這個IP上發(fā)送的所有的網(wǎng)絡包給丟棄掉，依賴系統(tǒng)接收不到任何我們發(fā)送的包，自然也 不會做任何回應。相當于系統(tǒng)接口的調(diào)用沒有返回。2、使用 i

9、ptables 直接模擬系統(tǒng)的某個端口不通sudo iptables -A OUTPUT -o eth0 -p tcp -dport 端口號 -j DROP這個命令同樣需要在被測系統(tǒng)上執(zhí)行。它的主要作用是將我們被測機器通過這個端口發(fā)送的所有的包給丟 棄掉。3、清除所有設置的iptables規(guī)則：iptables -F4、查看當前設置的所有iptables規(guī)則：iptables -L模擬應用變慢和超時添加對某個依賴系統(tǒng)的流量控制，下面的命令需要按照順序執(zhí)行：1、使用 ifconfig 查看默認的網(wǎng)卡信息，一般默認為 eth02、使用 tc 流量控制命令將 eth0 網(wǎng)口過來的數(shù)據(jù)包延遲 1000

10、ms sudo tc qdisc add dev eth0 root handle 1: priosudo tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 20kbit buffer 1600 limit 3000sudo tc qdisc add dev eth0 parent 30:1 handle 31: netem delay 1000ms 10ms distribution normal3、添加從某 ip 過來的流控規(guī)則（替換*.*.*.*為需要流控的 ip）sudo tc filter add dev eth0 protoc

11、ol ip parent 1:0 prio 3 u32 match ip dst *.*.*.*/32 flowid 1:3 查看已經(jīng)設置的限流規(guī)則: sudo tc filter list dev eth0 parent 1:0 刪除已經(jīng)設置的所有的限流規(guī)則: sudo tc filter del dev eth0 parent 1:0 prio 3 u32刪除已經(jīng)設置的從某ip過來的流控規(guī)則（直接替換添加流控規(guī)則命令中的add為del即可）：sudo tc filter del dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst

12、*.*.*.*/32 flowid 1:3注：linux tc流量控制是個非常復雜的工具，這次容災測試也只是粗淺的了解。希望深入了解的同學可以進入這里進一步學習： HYPERLINK /post/2011-11-13/15494559 /post/2011-11-13/15494559 容災項目特點1、項目需求無法提前計劃：所有容災的設計都是在不斷優(yōu)化和測試的過程中不斷發(fā)現(xiàn)新的需求。2、項目研發(fā)涉及到的業(yè)務場景覆蓋廣，涉及研發(fā)人員多，測試數(shù)據(jù)準備工作量大3、項目測試環(huán)境依賴多，復雜度高4、容災測試點相互交錯復雜，并行測試難度高，測試效率低5、測試難度較其他普通業(yè)務項目要求高，需要同步根據(jù)日志定

13、位所有的測試場景出現(xiàn)原因 容災項目測試策略 針對以上容災項目獨立的特點，測試也需要一定的測試策略來應對容災的測試工作 1、測試計劃的敏捷安排 容災項目測試因為需求不確定、涉及業(yè)務廣等原因?qū)е虑捌跍y試計劃較難做，需要有個非常敏捷的流程來應對各種需求的測試。 我們需要能夠在項目期間的任意一個時間點隨意的添加刪減測試人員，這就要求我們能夠有一個人能通盤全局了解所有的容災點，在任何時候能夠?qū)π氯诉M行測試指導，并幫助容災測試同 學排除所有的外在干擾，讓測試同學能夠快速的開始具體的容災測試。同時考慮容災業(yè)務涉及廣，為了避 免業(yè)務測試場景上的遺漏，我們需要采取一人協(xié)調(diào)，多業(yè)務測試專員配合的模式來開展容災測試

14、。他們各 自的職責有：【總協(xié)調(diào)人員/測試 PTM】：- 配合開發(fā)人員，對系統(tǒng)整體的容災點進行梳理和匯總- 協(xié)調(diào)不同的業(yè)務測試同學進行各容災點的測試- 容災測試的技術指導和工作 review- 各容災測試環(huán)境的協(xié)調(diào)- 幫助業(yè)務測試同學排除所有的外在干擾【容災測試執(zhí)行人員】：- 根據(jù)已梳理好的容災點完成容災測試- Bug 錄入和跟進，并定時匯總給總協(xié)調(diào)人員2、容災測試的需求文檔管理容災項目測試的需求一般會系統(tǒng)不斷的優(yōu)化、測試以及火花的碰撞而不斷增加，涉及到的團隊和人員也非 常廣，所以非常需要一個共享的方式來管理需求。本次容災項目中，我們在中后期采取了百科共享的方式 來管理所有的待做事項和容災點，并

15、進行了統(tǒng)一的分類，大大提高了溝通的效率。3、容災測試的數(shù)據(jù)準備容災測試的數(shù)據(jù)準備一定要全，不全的數(shù)據(jù)非常容易遺漏測試場景。可以結合不同的業(yè)務測試同學分別準 備，既可以保證數(shù)據(jù)的準確和完整性，也保證了效率。4、測試環(huán)境的協(xié)調(diào)容災項目的測試無法和普通的業(yè)務測試共用一套環(huán)境，需要準備獨立的環(huán)境來進行。不同的測試同學在共 用這一套環(huán)境時，切換不同的容災開關需要及時知會到所有人，以防對他人造成影響。當然，如果條件允 許，多備幾套容災測試環(huán)境自然更好，那樣大家就可以完完全全的并行測試了。5、容災測試和普通業(yè)務項目測試的不同以及注意事項- 測試容災點時，需要同步分析日志。因為容災一般都是測試的異常場景，我們

16、的測試環(huán)境經(jīng)常不穩(wěn)定， 出現(xiàn)各種異常，所以測試時一定要仔細結合日志分析，確認當前展示的結果是否是由于我們的容災代碼生 效而出現(xiàn)的。- 對于開發(fā)新增的業(yè)務代碼要尤其注意，重視并配合開發(fā)一起做好新代碼的容災工作- 不同系統(tǒng)之間的容災設計、以及同一個系統(tǒng)中的不同容災場景的設計需要仔細評估，對潛在可能相互關 聯(lián)的容災點要重點測試，預防互相影響，導致在極端情況下，出現(xiàn)無法預料的結果。6、代碼 review容災項目的代碼review非常重要。因為測試工作量大，涉及點多且咋，測試會重點關注已知的容災點測試， 對于未知的場景，只有通過代碼review來發(fā)現(xiàn)。比如本次的容災項目中，研發(fā)同學通過代碼review發(fā)

17、現(xiàn) 了我們的流控攔截代碼將不該攔截的業(yè)務代碼也給攔截了，而這個如果期望依靠測試來發(fā)現(xiàn)，成本將會高 很多很多。7、容災測試的自動化容災測試的自動化工作是勢在必行的。各種大促活動不斷的涌入，每次大量的人力成本投入容災測試著實 一種資源浪費。思考了一下后期自動化開展的方式和問題，有待實踐論證，這里簡單列一下：業(yè)務降級/數(shù)據(jù)備份/請求攔截/自動流控：可以直接選擇Ruby自動化或者接口測試來實現(xiàn)，只需提前將對 應的開關設置為相應狀態(tài)即可。但是需要一套獨立的環(huán)境，不能和正常的業(yè)務測試環(huán)境共用一套，會相互 干擾。強弱依賴設計：需要提前配置一套正確的環(huán)境，對環(huán)境要求非常高。并且不同的容災場景無法連續(xù)執(zhí)行， 需要手工在機器上執(zhí)行不同的命令以模擬斷網(wǎng)或者流量控制。實現(xiàn)難度較大。遠程執(zhí)行腳本也許可以解決 這個問題，有待具體實踐。8、容災線上演練容災線上演練是容災項目中特有的一個流程，在前期準備和演練過程中需要注意以下幾點：提前準備好所有的生產(chǎn)環(huán)境測試數(shù)據(jù)。因為演練一般從夜里凌晨開始，短短的幾個小時時間需要演練較 多的開關，測試數(shù)據(jù)