2018-5-8 博博
下圖所示線上故障，你的產品線是否曾經中招或者正在中招？同樣的問題總是在不同產品線甚至相同產品線不同系統重復上演，這些故障有個共同特點，就是線下常規測試很難發現，即便線上驗證也不易暴露。但是總是在“無變更安全日”悄然爆發，嚴重影響系統穩定性指標。
面對這些看似并無規律的故障，Case by case的分析無疑是低效而且不系統的，無法全面掃除穩定性測試盲區，也無法阻止悲劇在其他產品線再一次發生。為此筆者把問題聚類，根據問題特點尋求通用測試手段，并在產品線各個系統落地驗證，效果顯著，現把個人經驗融合前輩經驗產出，供大家參考，有則改之，無則加勉。
首先，為了讓大家更好了解這些故障對業務系統穩定性的影響程度，需了解下何為穩定性，衡量指標就是系統可用性= MTBF / (MTBF + MTTR) ， 其中MTBF， Mean Time Between Failure， 是平均無故障時間， 而MTTR， Mean Time To Repair，是平均修復時間，參考下表更加直觀。
從如上數字看，5個9的故障時間月故障時間只有25s，3個9的可用性月故障時間也只有40多分鐘，回想我們平時處理過的線上問題，開發和測試質量把控不過關，然后再把期望寄托在半人肉處理故障的運維團隊，顯然無法達到線上產品穩定性要求。
為了保障系統穩定性，提前消除風險勢在必行。產品質量風險類型很多，產品研發流程的各個階段都可能引入和存在風險，每個階段的風險的類型和發現手段都不盡相同，為此產出如下風險模型。按照風險發生的階段及原因，風險類型可分為：架構設計風險、編碼風險、安全風險、流程規范風險、運維風險和監控風險。
本文主要講解架構設計風險，接下來介紹的每個風險都會說明風險定義，影響，以及通過什么技術手段來進行風險識別，最后總結風險消除方案。另外每個風險都會有具體的例子來講解，這些例子都是發生在百度內部的真實故事。
架構設計風險是QA最容易忽略的，該類風險出現在研發階段的早期，我們都知道缺陷越早的暴露后期研發的維護成本越低，而且一旦架構設計上出現了問題，影響面是涉及整個模塊甚至系統的，修復代價必然非常高，因此對于架構設計的風險更要提前了解和避免。
根據既往經驗，架構設計風險大概可以分為以下幾個維度：交互、依賴、耦合。
交互類常見風險：重復交互、高頻交互、冗余/無用交互、接口不可重用、超時重試設置不合理、IP直連、跨機房等。
依賴類常見風險：不合理強弱依賴、無效依賴、忽略第三方依賴、緩存依賴失效等。
耦合類常見風險：架構耦合不合理、緩存耦合不合理等。
2、風險影響
重復交互增加接口耗時，降低接口性能，當重復的是跨機房交互會使得性能急劇下降影響系統穩定性，增加對下游服務的壓力（模塊壓力增加一倍，下游服務壓力增加幾倍）。
3、風險識別
如果兩個交互具有完全相同的請求服務對象（尤其是mysql、redis、memcache這類數據存儲服務）、請求數據、返回數據，那么這兩個交互就判定為重復交互；對于獲取不到交互數據時也可以通過數據包size進行初判。這里可以借助開源trace系統，采集業務測試時的調用鏈信息，根據上面的判斷規則進行風險自動識別。
4、風險消除
在對實時性要求可控的前提下，將第一次查詢信息緩存下來。
真實案例一：系統間重復交互。11次重復請求session，對于前端一次請求就要對session模塊產生幾十倍的流量沖擊，所有這些交互都是完全重復的，極大的降低的了接口性能和session的負載能力。
真實案例二：mysql/redis重復交互。mysql/redis作為系統中性能瓶頸，這樣的重復請求無疑加速了其性能瓶頸的到達。
1、風險定義
一次用戶發起的請求，如果在模塊之間的交互次數完全依賴于后端返回的數據條數，會給下游造成極大壓力的同時，也降低了系統的穩定性。相同業務請求的模塊交互次數多少不一，原因通常是代碼中循環操作內部存在網絡交互，總交互次數受到循環迭代的次數影響。這樣的情況在模塊上線初期，可能因為數據量比較小、pv比較小很容易被人忽視，當某天上線一些大數據、大客戶，將會給予致命一擊。
2、風險影響
循環請求次數過多會導致下游壓力倍增（前端pv增加一倍，后端pv增加幾十倍），接口性能不穩定，降低系統處理能力。系統穩定性完全依賴于數據的代碼邏輯非常脆弱，當遇到某一個大數據時將會出現模塊假死、系統雪崩、功能失敗。
3、風險識別
基于上游傳來的數據或某個子請求返回的數據量（通常是一個數組），針對每個數組元素進行網絡請求，遍歷并沒有錯，但是要對這個遍歷的數組元素個數有限制，否則循環遍歷的次數就完全依賴于數據。這里也可以借助開源trace系統，采集業務測試時的調用鏈信息，根據上面的判斷規則進行風險自動識別。
4、風險消除
數據量要可控，結合產品業務需求，比如請求返回結果要有上限；批量請求替代逐個請求。
真實案例：查詢某商戶物料詳情，當該商戶擁有大量物料，就出現了如下場景，用戶的一次查詢就造成服務與db之間156次交互，那該接口的性能就可想而知了，平均耗時都在3s+，用戶體驗極差。
1、風險定義
交互依賴的數據已出現異常，還繼續執行后續交互，使得后續的交互是沒有任何意義的冗余交互。這些依賴的數據，可能是上游傳遞而來，也可能是與下游模塊請求得來。
2、風險影響
冗余交互會占用系統資源，降低接口性能，從而影響系統穩定性和性能。
3、風險識別
如果交互A依賴數據B（比如交互A的請求數據中需要傳入B），在B異常（比如數據為空、null、false等）情況下，還是發生了交互A，那么就認為A是冗余交互；如果操作A依賴于操作B的成功執行，當B異常時，還是發生了操作A，那么A也認為是冗余交互。可以借助開源trace系統，采集業務測試時的調用鏈信息，根據上面的判斷規則進行風險自動識別。
4、風險消除
代碼中增加異常邏輯判斷：當交互依賴的數據異常時不進行該交互。
真實案例：如下調用鏈正常場景是先查詢團單list，然后用團單list去查詢每個團單的優惠。但是當查詢團單列表為空時，就沒有必要再調用marketing查詢團單的優惠信息了，應該立即返回錯誤碼。這里增加無效交互無疑降低了接口性能。
1、風險定義
相同請求發給模塊再次處理，不能保證結果一致，符合預期。
2、風險識別
相同請求，模塊返回結果不一致亦或重復寫操作產生臟數據。這里可以利用錄制工具，重放請求，驗證結果正確性。
3、風險消除
對于防重入可總結三點，前端加入防重復點擊設置，接口層加入鎖機制，db層需要加入唯一鍵設置。
真實案例
在商家會員卡充值購買的流程中，nmq故障情況下，購買結果頁顯示充值失敗，但是卡中余額卻一直在直線增加，原因是充值接口沒有做到可重入，這個case幸好在線下及時發現，否則后果不堪設想。
商家會員卡涉及到的購買流程如右下圖所示：
用戶提交訂單并且錢包處理完成后，錢包回調交易模塊的payresult接口，交易模塊驗證通過之后，會調用商家會員卡的rechargemoney接口給商家會員卡充值。為了提高充值接口的可用性，與交易模塊有個約定了一個機制：若調用rechargemoney返回的errno不為0 ，則投入nmq重試三分鐘，三分鐘之內的重試均沒有成功，才觸發自動退款。商家會員卡模塊的充值接口rechargemoney的流程圖如下圖所示：
在rechargemoney接口處理過程中，有一個防頻繁重入的判定redis鎖過程，expireTime設置時間為10s，10s內會攔截過來的重復請求，直接返回。
上述過程可以看到，前端是有無限重試策略的，因此可以認為前端無防重入，那么看接口層鎖機制，重試時間3min明顯大于鎖有效時間10s，因此相同請求10s后鎖機制也失效，再看db層，插入order_id和其他營銷信息，數據庫中并沒有設置order_id為唯一鍵，因此該接口徹底失守，沒有做到可重入，相同訂單可以重復插入成功，從而導致業務表現為同一訂單多次重復充值。
對于該案例，改進方案是首先將鎖有效時間設置大于一切來源的重試時間，其次在db充值記錄表中將orderid設置為主鍵，雙重保護該接口做到可重入。
1、風險定義
顧名思義，就是超時并沒有根據系統真實表現科學的設置。
2、風險影響
就像下圖化學反應一樣，不合理的超時實際設置并不會產生真正影響，但是遇到網絡故障，依賴超時時，后果不堪設想。
模塊交互必設超時，這是基本要求，但是超時設置過長、過短可能會適得其反。不合理超時設置主要表現為①交互超時時間設置過長，比如5s甚至10s的超時②下游超時時間大于上游超時時間。
交互超時重試時間過長，在下游偶爾出現網絡抖動時連接被hang住，接口耗時增加，并且降級模塊處理能力。下游超時>上游超時，上游超時后斷開連接引發重試，下游還在繼續上次運算（此時已經沒有意義），下游負載增加N倍（取決于重試次數設置和發生重試的層數），使得系統性能急劇下降甚至雪崩。
3、風險識別
①超時時間設置過長（比如數據庫connect超時1s，模塊讀寫超時5s）
②下游超時時間大于上游超時時間。
4、風險消除
從系統整體考慮，并且結合重試和本模塊計算時間的影響。下游超時<上游超時；超時時間不宜過長，根據下游接口性能設置；對于弱依賴的服務交互，超時時間更不能過長，以免弱依賴阻塞主流程。
真實案例：如下圖，該接口調用redis超時時間超過2s，然而Redis性能極好，單線程阻塞性server，這種長耗時會阻塞其他請求，很容易引起系統雪崩，應該把redis連接超時時間修改適當小。
1、風險定義
顧名思義，就是重試并沒有根據系統真實表現科學的設置。
2、風險影響
任何網絡交互都可能失敗，為了保證最終交互成功，通常交互失敗/超時、數據錯誤后再次與該模塊交互，即發生了重試。重試的次數設置不當，輕者交互成功率不達標，業務失敗率增高，嚴重者引發系統雪崩。
3、風險識別
查看框架配置文件中重試次數配置，是否簡單粗暴的經驗值設定重試次數，比如一律重試3次，查看代碼中邏輯控制的重試限制（這種很隱蔽）。
4、風險消除
相對于固定的重試序列，隨機重試序列也可能給系統帶來風險，例如可能會降低下游模塊的cache命中率，降低系統性能，甚至引起雪崩。
評估重試機制：
1) 真的需要在每一層都努力重試嗎？
2) 真的需要這么多次重試嗎？
3) 真的需要在連接，寫，讀這三者失敗后都重試嗎？
按照業務需求和模塊性能設置重試次數
弱依賴不用重試也可以
下游模塊性能好，基本不會超時，也可以不重試
大部分情況下，重試次數為1已經足夠
真實案例
如圖為某產品線的架構，整個系統中，上游模塊對下游模塊所有的交互，重試次數都是設成3次，交互失敗包括連接失敗，寫失敗，讀失敗這三種情形。如果是寫和讀失敗，那么要關閉當前連接，再重新發起連接。
如果一臺bs假死，到該bs的請求會超時。（注意區分模塊假死和真死，假死情況下，模塊端口打開，能夠接收上游連接，但是由于各種原因（如連接隊列滿，工作線程耗盡，陷入死循環等），不會返回任何應答，上游模塊必須等待超時才知道失敗，連接超時，寫超時和讀超時都有可能。而在真死情況下，模塊端口關閉，或者干脆程序退出，上游模塊連接它會很快得到失敗返回碼，這個返回碼由下游模塊的操作系統協議棧返回的，如ECONNREFUSED錯誤碼代表端口不存在，連接被拒絕。）
那么as有1/3的概率需要重試，as重試的過程中，ui可能早就認為as已經超時了，所以ui也開始重試，ui重試的過程中，webserver可能認為ui已經超時了，所以webserver也開始重試……就這樣，整個系統的負載急劇增加，到達bs的qps會是平時的27倍，直到系統崩潰為止。
1、風險定義
A,B兩個系統交互，B系統分布式部署，A-B連接是通過配置B系統所有IP方式。
2、風險影響
當B系統分布式服務中某一臺掛掉時，不能做到failover，導致故障影響擴大。
3、風險消除
通過bns或者組的方式進行連接。
真實案例
某產品線依賴服務redis調用均采用ip列表的方式，如果redis proxy出現單機故障，需要人工介入進行切流量止損。單機發單重啟修復周期有時會達小時級別，因此線上服務在故障期間會長時間處于切流量狀態，高峰期單機房容量會存在風險。如同時有其他機房服務異常，則無法執行既定預案止損。并且如想下掉故障proxy，只能采用發上線單修改線上配置的方式。止損操作復雜，周期長，效率低下，具體case如下:
(1)用戶中心redisproxy單機故障，人工切流量止損，恢復服務花費2小時，期間線上處于切流量狀態。
(2)商品中心redis proxy單機故障，會存在扣除庫存失敗的風險。恢復服務花費半小時，后續又再次發生宕機，發單下掉故障proxy。
如上對應前面講的故障時間，該服務sla月可用性已不足3個9。
1、風險定義
交互的兩個模塊分別部署在不同機房。
2、風險影響
跨機房交互由于存在網絡延時，嚴重影響接口性能、請求成功率，極大的降低了系統穩定性。
3、風險識別
①配置錯誤（ODP框架）ral-service中配置的服務后端IP的Tag不能為空（在ral中，會將Tag為空的也認為是本機房）②上游傳入idc錯誤，Idc是完全匹配，nj和nj02就不相同，因此如果上游傳入nj02，當前模塊的idc是nj，就會找不到對應的Tag而只能使用default。
4、風險消除
主要關注配置是否合理，由于線上配置很難在線下驗證正確性，肉眼排查難免遺漏，因此可通過線上機房流量切換演練驗證。
1、風險定義
所謂強依賴就是，請求鏈路中某個服務失敗/結果異常/無結果后，核心邏輯必失敗，否則就認為是弱依賴。不合理的強弱依賴有兩類，本應該是弱依賴的設置為強依賴，本應該是強依賴的設置為弱依賴。
2、風險影響
系統穩定性取決于調用鏈中所有依賴穩定性最差的依賴，如果將穩定性較差的服務作為強依賴將嚴重影響穩定性
3、風險識別
強弱依賴的合理性是需要結合業務判斷的，如果業務返回結果不可或缺該依賴，那么就該設置強依賴；如何判斷該依賴是否為強依賴可以通過故障模擬驗證，如果模擬該依賴異常時導致調用異常，則判斷其為強依賴。
4、風險消除
①調整不合理的強弱依賴關系，將業務非強依賴服務降級；②通過系統優化及運維優化等手段提高強依賴的穩定性。③對強依賴結果進行全面校驗，保證強依賴故障能夠及時被發現。
真實案例
用戶下單請求到trade模塊，是通過消息隊列nmq保證下單后的商戶通知功能，通知商戶是借助公共服務云推送，這里云推送被實現成了強依賴，也就是當云推送如果失敗，返回給本次請求失敗。
某次下單高峰期時，云推送出現故障，無法給ios用戶推送消息，nmq收到請求失敗后，會持續不斷的重發，nmq的通道堵塞之后也影響了trade模塊向nmq的請求故障不斷往上層蔓延，最后用戶無法下單。
對于如上案例，工程師最后去掉對云推送強依賴代碼，服務才慢慢恢復，但已造成非常大的損失。
1、風險定義
服務啟動流程中與該依賴建立了連接，但是整個邏輯處理過程中無需依賴該服務，無任何業務關聯性。
2、風險影響
其實該風險是不合理依賴的一個特例，無業務關聯性的依賴應該及時去除，否則會影響整體服務穩定性。
3、風險識別
與依賴服務只有一次鏈接交互，無其他交互，就可以初步判斷該依賴為無效依賴，為了準確評估可再結合代碼排查。
真實案例
某產品線由于配置管理較亂，有個服務每次啟動都會判斷多個與業務完全不依賴的服務啟動情況，這幾個依賴服務處于無人維護狀態，非常不穩定，從而導致該服務啟動失敗率非常高。
1、風險定義
請求的完成，需要依賴產品外的其他服務，都稱之為第三方（tp）依賴，按照公司又分為公司外第三方，比如糯米酒店依賴攜程服務；公司內第三方，比如passport相對于手百。
2、風險影響
第三方服務的性能，正確性，穩定性直接影響自身服務，尤其是第三方強依賴，當第三方依賴出現異常，很可能導致自身產品受到損失；公司外第三方依賴有些是小型公司，技術和運維能力有限，其服務的性能，正確性、穩定性不是很高。
3、風險識別
第三方依賴的可靠性是不可控的也是我們系統建設中不可避免的，那么只能盡量降低第三方依賴不穩定對自身的影響。
4、風險消除：
盡量避免第三方強依賴；
超時設置，重試設置結合第三方容量，平均響應時間，部署情況；
增加第三方依賴掛掉，假死，接口變更的校驗及容錯降級處理，從架構和云微商做到各個TP方與自身業務的解耦；
運維上，提高第三方依賴可靠性，使用內網bns，vip請求，且避免跨機房交互。
真實案例
某產品線依賴A,B,C三個tp方數據進行匯總展示，每次都需要調用三方都有結果時再進行聚合，否則認為整個流程失敗，而三個tp方穩定性不盡相同，其中B是個小公司，經常出現故障，導致自身服務經常故障。
對此工程師對各個TP方加上了全面校驗，當驗證故障后自動調用降級操作，去掉該tp依賴。從此服務穩定性大大提升。
1、風險定義
前端請求一個肯定不存在的key，導致每次請求都會請求后端原始數據，使得緩存被“穿透”，當該類請求高并發時，那么后端壓力凸顯。
2、風險影響
緩存穿透后，每個請求都會到達后端服務，對后端服務壓力突增；當緩存穿透的并發較高（尤其是惡意攻擊），后端服務很可能被壓垮，導致整個系統癱瘓。
3、風險原因
一種可能是對于主從分離系統，緩存失效時間小于主從延遲時間，尤其是跨機房的主從分離，主從延遲在某些時候會達到數秒甚至數十秒，這是如果緩存時間設置過小，就會導致所有緩存讀寫記過均為失效結果，進而請求后端服務獲取新的數據。另一種可能是查詢結果為空的情況。
4、風險消除
對于查詢結果為空的情況也進行緩存，緩存時間設置短一點，或者該key對應的數據insert了之后清理緩存；
對于一定不存在的key進行過濾，把這些key放到一個大的bitmap上；
設計的時候考慮，當緩存失效時，系統服務的情況及應對措施。
1、風險定義
大量緩存同時過期失效，前端請求同時到達后端服務。
2、風險影響
當并發量足夠大（比如秒殺，搶購），后端服務很可能被壓垮，導致整個系統雪崩。
3、風險識別
緩存設置時間相同，失效周期也相同，導致多個緩存同時失效。
4、風險消除
不同的key，設置不同的過期時間，讓緩存失效的時間點盡量散列均勻；
在緩存試下后，通過加鎖或者隊列來控制讀數據庫讀寫緩存的線程數量（比如對某個key只允許一個線程查詢和寫緩存，其他線程等待）；
做二級緩存，A為原始緩存，A2位拷貝緩存，A1失效時，可以訪問A2，A1緩存失效設置為較短，A2設置為長期。
真實案例
某產品線監控發現機器A機器的8688端口掛掉了，經追查發現一個廣告配置下發的接口（/api/v1/ipid）掛掉了，據統計，前一天23點到當日9點之間，該接口被訪問了400萬+次，正常來講，這種廣告配置下發的接口一天最多幾百個請求量。
經查，客戶端有一個零點定時觸發策略，零點會同時啟動很多服務，平時并發請求會命中緩存，不會造成太大壓力，可是當時正趕上緩存時間到期，大量請求將服務接口壓死，端口掛掉。
對此臨時方案是在接入層nginx配置文件中加入了流量控制機制，用lua腳本來將零點的請求屏蔽掉，長期方案是避免這種緩存集體失效的情況。
1、風險定義
系統架構和設計上存在著耦合，包括模塊耦合、接口耦合、消息隊列耦合。具體體現在，主次不分的功能在一個模塊或者接口中實現，nmq中不同重要性的命令耦合在同一個module中。
2、風險影響
整個系統穩定性<最不穩定的功能穩定性，不重要的功能可能拖垮重要功能
3、風險消除
整體思路就是，重要與不重要拆分，實時與非實時拆分，在線與離線拆分，根本上解決就是架構解耦，但是系統發展到一定階段再拆分代碼成本很高，這里可以通過運維方法控制解耦，具體見如下案例。
真實案例
某產品線的一級服務和二級服務共同依賴一個基礎服務，由于二級服務的一個bug拖垮基礎服務，從而導致一級服務不可用，對此解決方案是通過運維將不同上游流量分開。
思想同2.1.14這里不再贅述。
本文給出了常見的15種架構設計風險，希望大家能夠在實際工作中參考審視自己系統是否也存在同樣的風險，盡早消除，提高穩定性！