為此，對應用的可用性程度一般衡量標準有三個9到五個9。

對於一個功能和資料量不斷增加的應用，要保持比較高的可用性並非易事。為了實現高可用，付錢拉從避免單點故障、保證應用自身的高可用、解決交易量增長等方面做了許多探索和實踐。

在不考慮外部依賴系統突發故障，如網路問題、三方支付和銀行的大面積不可用等情況下，付錢拉的服務能力可達99.999%。

本文重點討論如何提高應用自身的可用性。

為了提高應用的可用性，首先要做的就是儘可能避免應用出現故障，但要完全做到不出故障是不可能的。網際網路是個容易產生“蝴蝶效應”的地方，任何一個看似很小的、發生概率為0的事故都可能出現，然後被無限放大。

大家都知道RabbitMQ本身是非常穩定可靠的，付錢拉最開始也一直在使用單點RabbitMQ，並且從未出現執行故障，所以大家在心理上都認為這個東西不太可能出問題。

直到某天，這臺節點所在的物理主機硬體因為年久失修壞掉了，當時這臺RabbitMQ就無法提供服務，導致系統服務瞬間不可用。

故障發生了也不可怕，最重要的是及時發現並解決故障。付錢拉對自身系統的要求是，秒級發現故障，快速診斷和解決故障，從而降低故障帶來的負面影響。

首先簡單回顧一下我們曾經碰到的一些問題：

以史為鑑

1. 新來的開發同事在處理新接入的三方通道時，由於經驗不足忽視了設定超時時間的重要性。就是這樣一個小小的細節，導致這個三方佇列所在的交易全部堵塞，同時影響到其他通道的交易。

2. 系統是分散式部署的，並且支援灰度釋出，所以環境和部署模組非常多而且複雜。某次增加了一個新模組，由於存在多個環境，且每個環境都是雙節點，新模組上線後導致資料庫的連線數不夠用，從而影響其他模組功能。

3. 同樣是超時問題，一個三方的超時，導致耗盡了當前所配置的所有worker threads，以至於其他交易沒有可處理的執行緒。

4. A三方同時提供鑑權，支付等介面，其中一個介面因為我們的交易量突增，從而觸發A三方在網路運營商那邊的DDoS限制。通常機房的出口IP都是固定的，從而被網路運營商誤認為是來自這個出口IP的交易是流量攻擊，最終導致A三方鑑權和支付介面同時不可用。

5. 再說一個數據庫的問題，同樣是因為我們的交易量突增引發的。建立序列的同事給某個序列的上限是999，999，999，但資料庫存的這個欄位長度是32位，當交易量小的時候，系統產生的值和欄位32位是匹配的，序列不會升位。可是隨著交易量的增加，序列不知不覺的升位數了，結果導致32位就不夠存放。

類似這樣的問題對於網際網路系統非常常見，並且具有隱蔽性，所以如何避免就顯得非常重要了。

下面我們從三個方面來看我們所做的改變。

儘可能避免故障

設計可容錯的系統

比如重路由，對於使用者支付來說，使用者並不關心自己的錢具體是從哪個通道支付出去的，使用者只關心成功與否。付錢拉連線30多個通道，有可能A通道支付不成功，這個時候就需要動態重路由到B或者C通道，這樣就可以通過系統重路由避免使用者支付失敗，實現支付容錯。

還有針對OOM做容錯，像Tomcat一樣。系統記憶體總有發生用盡的情況，如果一開始就對應用本身預留一些記憶體，當系統發生OOM的時候，就可以catch住這個異常，從而避免這次OOM。

某些環節快速失敗“Fail fast原則”

Fail fast原則是當主流程的任何一步出現問題的時候，應該快速合理地結束整個流程，而不是等到出現負面影響才處理。

舉個幾個例子：

• 付錢拉啟動的時候需要載入一些佇列資訊和配置資訊到快取，如果載入失敗或者佇列配置不正確，會造成請求處理過程的失敗，對此最佳的處理方式是載入資料失敗，JVM直接退出，避免後續啟動不可用；

• 我們的實時類交易處理響應時間最長是40s，如果超過40s前置系統就不再等待，釋放執行緒，告知商戶正在處理中，後續有處理結果會以通知的方式或者業務線主動查詢的方式得到結果；

• 我們使用了redis做快取資料庫，用到的地方有實時報警埋點和驗重等功能。如果連線redis超過50ms，那麼這筆redis操作會自動放棄，在最壞的情況下這個操作帶給支付的影響也就是50ms，控制在系統允許的範圍內。

>>>>

設計具備自我保護能力的系統

系統一般都有第三方依賴，比如資料庫、三方介面等。系統開發的時候，需要對第三方保持懷疑，避免第三方出現問題時候的連鎖反應，導致宕機。

（1）拆分訊息佇列

我們提供各種各樣的支付介面給商戶，常用的就有快捷，個人網銀，企業網銀，退款，撤銷，批量代付，批量代扣，單筆代付，單筆代扣，語音支付，餘額查詢，身份證鑑權，銀行卡鑑權，卡密鑑權等。與其對應的支付通道有微信支付，ApplePay，支付寶等30多家支付通道，並且接入了幾百家商戶。在這三個維度下，如何確保不同業務、三方、商戶、以及支付型別互不影響，我們所做的就是拆分訊息佇列。下圖是部分業務訊息佇列拆分圖：

（2）限制資源的使用

對於資源使用的限制設計是高可用系統最重要的一點，也是容易被忽略的一點，資源相對有限，用的過多了，自然會導致應用宕機。為此我們做了以下功課：

• 限制連線數

隨著分散式的橫向擴充套件，需要考慮資料庫連線數，而不是無休止的最大化。資料庫的連線數是有限制的，需要全域性考量所有的模組，特別是橫向擴充套件帶來的增加。

• 限制記憶體的使用

記憶體使用過大，會導致頻繁的GC和OOM，記憶體的使用主要來自以下兩個方面： 

1. 集合容量過大； 

2. 未釋放已經不再引用的物件，比如放入ThreadLocal的物件一直會等到執行緒退出的時候回收。

• 限制執行緒建立

執行緒的無限制建立，最終導致其不可控，特別是隱藏在程式碼中的建立執行緒方法。
 

當系統的SY值過高時，表示linux需要花費更多的時間進行執行緒切換。Java造成這種現象的主要原因是建立的執行緒比較多，且這些執行緒都處於不斷的阻塞（鎖等待，IO等待）和執行狀態的變化過程中，這就產生了大量的上下文切換。

除此之外，Java應用在建立執行緒時會操作JVM堆外的實體記憶體，太多的執行緒也會使用過多的實體記憶體。對於執行緒的建立，最好通過執行緒池來實現，避免執行緒過多產生上下文切換。

• 限制併發

做過支付系統的應該清楚，部分三方支付公司是對商戶的併發有要求的。三方給開放幾個併發是根據實際交易量來評估的，所以如果不控制併發，所有的交易都發給三方，那麼三方只會回覆“請降低提交頻率”。

所以在系統設計階段和程式碼review階段都需要特別注意，將併發限制在三方允許的範圍內。

及時發現故障

故障就像鬼子進村，來的猝不及防。當預防的防線被衝破，如何及時拉起第二道防線，發現故障保證可用性，這時候報警監控系統的開始發揮作用了。一輛沒有儀表盤的汽車，是無法知道車速和油量，轉向燈是否亮，就算“老司機”水平再高也是相當危險的。同樣，系統也是需要監控的，最好是出現危險的時候提前報警，這樣可以在故障真正引發風險前解決。

實時報警系統

如果沒有實時報警，系統執行狀態的不確定性會造成無法量化的災難。我們的監控系統指標如下：

• 實時性：實現秒級監控；

• 全面性：覆蓋所有系統業務，確保無死角覆蓋；

• 實用性：預警分為多個級別，監控人員可以方便實用地根據預警嚴重程度做出精確的決策；

• 多樣性：預警方式提供推拉模式，包括簡訊，郵件，視覺化介面，方便監控人員及時發現問題

報警主要分為單機報警和叢集報警，而付錢拉屬於叢集部署。實時預警主要依靠各個業務系統實時埋點資料統計分析實現，因此難度主要在資料埋點和分析系統上。

埋點資料

要做到實時分析，又不影響交易系統的響應時間，我們在系統各個模組中通過redis實時做資料埋點，然後將埋點資料彙總到分析系統，分析系統根據規則進行分析報警。

分析系統

分析系統最難做的是業務報警點，例如哪些報警只要一出來就必須出警，哪些報警一出來只需要關注。下面我們對分析系統做一個詳細介紹：

1、系統執行架構

2、系統執行流程

3、系統業務監控點

我們的業務監控點都是在日常執行過程中一點一滴總結出來的，分為出警類和關注類兩大塊。

出警類：

• 網路異常預警；

• 單筆訂單超時未完成預警；

• 實時交易成功率預警；

• 異常狀態預警；

• 未回盤預警；

• 失敗通知預警；

• 異常失敗預警；

• 響應碼頻發預警；

• 核對不一致預警；

• 特殊狀態預警；

關注類：

• 交易量異常預警；

• 交易額超過500W預警；

• 簡訊回填超時預警；

• 非法IP預警；

4、非業務監控點

非業務監控點主要是指從運維角度的監控，包括網路，主機，儲存，日誌等。具體如下：

• 服務可用性監控：

使用JVM採集YoungGC/Full GC次數及時間、堆記憶體、耗時Top 10執行緒堆疊等資訊，包括快取buffer的長度。

• 流量監控：

通過Agent監控代理部署在各個伺服器上，實時採集流量情況。

• 外部系統監控：

通過間隙性探測來觀察三方或者網路是否穩定。

• 中介軟體監控：

針對MQ消費佇列，通過RabbitMQ指令碼探測，實時分析佇列深度；

針對資料庫部分，通過安裝外掛xdb，實時監控資料庫效能。

• 實時日誌監控：

通過rsyslog完成分散式日誌的歸集，然後通過系統分析處理，完成日誌實時監控和分析。最後，通過開發視覺化頁面展示給使用者。

• 系統資源監控：

通過Zabbix監控主機的CPU負載、記憶體使用率、各網絡卡的上下行流量、各磁碟讀寫速率、各磁碟讀寫次數(IOPS)、各磁碟空間使用率等。

以上就是我們實時監控系統所做的，主要分為業務點監控和運維監控兩方面，雖然系統是分散式部署，但是每個預警點都是秒級響應。除此之外，業務系統的報警點也有一個難點，那就是有些報警是少量報出來不一定有問題，大量報警就會有問題，也就是所謂的量變引起質變。

舉一個例子，拿網路異常來說，發生一筆可能是網路抖動，但是多筆發生就需要重視網路是否真的有問題，針對網路異常，我們的報警樣例如下：

•  單通道網路異常預警：1分鐘內A通道網路異常連續發生了12筆，觸發了預警閥值； 

• 多通道網路異常預警1: 10分鐘內，連續每分鐘內網路異常發生了3筆，涉及3個通道，觸發了預警閥值；

• 多通道網路異常預警2： 10分鐘內，總共發生網路異常25筆，涉及3個通道，觸發了預警閥值。

日誌記錄和分析系統

對於一個大型系統而言，每天記錄大量的日誌和分析日誌是有一定的難度的。付錢拉每天平均有200W筆訂單量，一筆交易經過十幾個模組流轉，假設一筆訂單記錄30條日誌，可想而知每天會有多麼巨大的日誌量。

我們日誌的分析有兩個作用，一個是實時日誌異常預警，另外一個是提供訂單軌跡給運營人員使用。

實時日誌預警

實時日誌預警是針對所有實時交易日誌，實時抓取帶有Exception或者Error的關鍵字然後報警。這樣的好處是，如果程式碼中有任何執行異常，都會第一時間發現。我們針對實時日誌預警的處理方式是，首先採用rsyslog完成日誌歸集，然後通過分析系統實時抓取，再做實時預警。

訂單軌跡

對於交易系統，非常有必要實時瞭解一筆訂單的狀態流轉。我們最初的做法是通過資料庫來記錄訂單軌跡，但是執行一段時間後，發現訂單量劇增導致資料庫表過大不利於維護。

我們現在的做法是，每個模組通過列印日誌軌跡，日誌軌跡列印的格式按照資料庫表結構的方式列印，列印好所有日誌後，rsyslog來完成日誌歸集，分析系統會實時抓取列印的規範日誌，進行解析然後按天存放到資料庫中，並展示給運營人員視覺化介面。

日誌列印規範如下：

簡要日誌視覺化軌跡如下：

日誌記錄和分析系統除了以上兩點，也提供了交易和響應報文的下載和檢視。

7*24小時監控室

以上的報警專案給操作人員提供推拉兩種方式，一種是簡訊和郵件推送，一種是報表展示。除此之外，由於支付系統相比網際網路其他系統本身的重要性，我們採用7*24小時的監控室保證系統的安全穩定。

及時處理故障

在故障發生之後，特別是生產環境，第一時間要做的不是尋找故障發生的原因，而是以最快速度處理故障，保障系統的可用性。我們常見的故障和處理措施如下：

自動修復

針對自動修復部分，我們常見的故障都是三方不穩定造成的，針對這種情況，就是上面說的系統會自動進行重路由。

服務降級

服務降級指在出現故障的情況下又無法快速修復的情況下，把某些功能關閉，以保證核心功能的使用。我們針對商戶促銷的時候，如果某個商戶交易量過大，會實時的調整這個商戶的流量，使此商戶服務降級，從而不會影響到其他商戶，類似這樣的場景還有很多，具體的服務降級功能會在後續系列介紹。