“支付故障之痛，雪崩教訓(xùn)深刻?！?在互聯(lián)網(wǎng)支付領(lǐng)域，系統(tǒng)穩(wěn)定至關(guān)重要。一次看似微小的問題，如何引發(fā)了災(zāi)難性的雪崩？我們又能從中吸取哪些教訓(xùn)，以保障支付系統(tǒng)的安全與可靠？

我是從傳統(tǒng)行業(yè)轉(zhuǎn)互聯(lián)網(wǎng)支付，剛進入支付行業(yè)那幾年，經(jīng)歷了很多線上故障。

除了上一篇說到的渠道短號導(dǎo)致資損幾十萬的故障，還有一個可以拖出去祭天的故障，導(dǎo)致的后果嚴(yán)重性遠超上一個：不但整個支付系統(tǒng)宕機，錯亂的數(shù)據(jù)就有幾十萬條，修數(shù)就修了四天三夜。

好在領(lǐng)導(dǎo)真的人好，保住我小命一條，但是領(lǐng)導(dǎo)自己的年終和晉升給祭天了。

故事從好些年前說起，那時分布式應(yīng)用已經(jīng)起來，但是微服務(wù)還沒有成氣候。

支付系統(tǒng)由臺服務(wù)器組成集群服務(wù)，每臺服務(wù)器都有完整的全應(yīng)用部署，包括收銀支付，收單，渠道網(wǎng)關(guān)，會員，商服等全部子應(yīng)用，從入口開始直到調(diào)用渠道，全部在一臺服務(wù)器內(nèi)部搞定，各子應(yīng)用之間的服務(wù)是獨立的，通過socket調(diào)用。

整體架構(gòu)如下圖所示。

那時還是直連銀行，日常沒有什么問題，經(jīng)過幾次大促的洗禮都平安度過。

直到有一次大促，流量特別高，大促開始沒幾分鐘，就有一家銀行出現(xiàn)慢處理問題，具體表現(xiàn)為平時1S就返回，變成了平均2到5分鐘才返回結(jié)果。

很不幸，當(dāng)前網(wǎng)關(guān)的配置有缺陷，導(dǎo)致配置的超時時間沒有生效，所有與這家銀行的請求平均耗時2到5分鐘才釋放，導(dǎo)致網(wǎng)關(guān)的線程耗盡。

悲劇由此拉開序幕。

首先是網(wǎng)關(guān)的線程耗盡，導(dǎo)致其它銀行的請求也得不到及時的處理。

然后是內(nèi)部各子應(yīng)用之間全部是同步調(diào)用，網(wǎng)關(guān)的問題快速蔓延到了上游應(yīng)用，上游各子應(yīng)用的線程數(shù)也被耗盡，雪崩出現(xiàn)，整個支付系統(tǒng)無法正常處理業(yè)務(wù)請求。

那也是我職業(yè)生涯中第一次聽說“雪崩”這個名詞可以用在技術(shù)領(lǐng)域。

如前面所說，當(dāng)時數(shù)據(jù)訂正就花了四天三夜，每天在公司的行軍床上躺2小時。

前車之鑒，后車之師。還是有一些教訓(xùn)可以總結(jié)一下。

強制設(shè)置合理的超時時間，并驗證有效。這里面包含2層意思：

合理的超時時間。比如不同的外部渠道以及同一渠道不同的接口，響應(yīng)時間都是不一樣的，需要統(tǒng)計90分位，95分位，98分位等多個時間。一般覆蓋95分位就差不多。

需要驗證有效。很多技術(shù)參數(shù)在表面上看是設(shè)置了，但是實際可能不是預(yù)期那樣。就拿http來說，就有連接超時，寫入超時，讀取超時等多個超時參數(shù)。一定需要模擬測試驗證，達到預(yù)期效果。

服務(wù)隔離。比如為不同的渠道做線程池隔離。一個渠道掛了不影響另外一個渠道。

健全的服務(wù)降級、熔斷、限流能力。現(xiàn)在的微服務(wù)框架基本都有自動化的服務(wù)降級、熔斷、限流能力，但是需要提前做好配置。提供有損服務(wù)好過完全無服務(wù)可用。

用好同步受理異步處理機制。比如最外部的渠道網(wǎng)關(guān)，因為外部渠道的耗時都比較長，就采用同步受理異步處理的模式：先把交易信息收下來，落庫，馬上返回給上游受理成功，然后再起異步線程把請求發(fā)出去。

這樣有兩個好處：

1）可以為網(wǎng)關(guān)單獨擴大線程池的最大線程配置。因為網(wǎng)關(guān)已經(jīng)變?yōu)镮O密集型應(yīng)用。

2）網(wǎng)關(guān)的慢處理（比如耗時2S），不影響上游，上游可以毫秒級就處理完自己的業(yè)務(wù)。

壓測和預(yù)案。前者是提前發(fā)現(xiàn)問題，后者是問題出現(xiàn)后可以指導(dǎo)快速響應(yīng)。

當(dāng)交易量足夠大，一個小小的問題也有可能被放大到無法承受之重。

無知的人，給平臺帶來的傷痛最深。