轉轉支付通道監控系統的搭建

來源：轉轉技術

• 1 背景介紹

• 2 設計目標

• 3 技術選型

• 3.1 熔斷器

• 3.2 時序資料庫

• 4 架構設計

• 5 實現細節

• 5.1 資料結構

• 5.2 核心演算法

• 5.3 小流量的處理

• 6 最終效果

• 7 未來規劃

1 背景介紹

為了滿足不斷增長的業務需求，轉轉逐步接入了大量的支付通道，而第三方系統的穩定性參差不齊，通道故障時有發生。當三方通道發生異常時我們的感知比較後置，比如大量的系統告警，甚至需要等業務或使用者反饋才能感知到異常。作為承接全公司支付業務的核心繫統，想要建立一個能給上游提供穩定服務的系統，僅依靠人工維護是遠遠不夠的，因此建立一個完善的支付通道自動化管理系統就提上了日程。

2 設計目標

結合轉轉自身業務的特點，我們整理了支付通道自動化管理系統重點需要解決的問題：

1. 多通道、多主體的通道監控能力；
2. 故障快速發現，快速定位異常原因；
3. 儘量做到無誤報、無漏報；
4. 通道故障自動化切換的能力；

3 技術選型

基於以上背景，再來看下技術方案的選型：

3.1 熔斷器

提到故障的熔斷和降級，首先想到的是市面上成熟的元件是否能夠滿足，比如 Hystrix，結合轉轉當前的業務場景來看，有以下幾點無法滿足訴求：

1. 熔斷器的降級熔斷是基於介面的，無法滿足通道和商戶號維度的降級；
2. 流量回切時可能異常仍未恢復，無法自定義探測流量的範圍，比如回切時指定使用者或業務，容易造成二次事故；

3.2 時序資料庫

熔斷器無法滿足目標後，我們就將目標轉向了自研，首先想做一個監控系統，底層一般都是選用時序資料庫來儲存，以下是熱門時序資料庫的排名：

結合轉轉目前的現狀，我們最終將範圍鎖定在了 Prometheus 和基於 Redis 自研：

準確性方面： 由於 Prometheus 在設計上就放棄了一部分資料準確性，放棄一點準確性得到的是更高的可靠性，架構簡單、資料簡單、運維簡單、節約機器成本與人力成本。

通常對於監控系統，資料擁有少量的誤差是可以接受的，而對於自動切換通道這種高敏感場景並不適用：

• 比如在兩次取樣的間隔 （15s) 中有一個瞬時小尖峰，那麼這次小尖峰是觀察不到的
• 再比如 QPS、RT、P95、P99 這些值都是估算值，無法和日誌、資料庫一樣做到 100% 準確

接入和學習成本方面： Prometheus 對於業務研發來講還是有一定的學習成本的，也不便於後期的維護，而 Redis 對於 Java 後端開發者來說再熟悉不過了，無論是前期的學習成本還是後期的維護成本都比較低。

結合以上幾個方面考量，最終決定基於 Redis 自研 “時序資料庫” 來滿足當前的訴求。

4 架構設計

收款和付款時會先透過各自的通道路由，篩選出可用的支付通道列表，獲取到通道之後呼叫閘道器下單或打款，再由閘道器來向三方發起請求，請求結束後將三方返回的結果透過 MQ 上報到通道監控系統。

監控系統在監聽到訊息後，將監控的資料儲存到 Redis，再由資料計算模組拉取 Redis 的資料進行篩選過濾後，彙總計算各通道的失敗率，最後根據各通道配置的告警規則觸發通道異常告警。

Redis 中的資料會定期向 MySQL 備份，以便後續故障分析使用，同時會有離線任務定時清理 Redis 中的資料，避免 Redis 中儲存的資料量過大。

同時為了更直觀的觀察各通道資料指標的變化，將收集到的資料指標上報到了 Prometheus，透過 Grafana 資料看板來觀察通道健康度。

通道自動上下線是比較敏感的操作，嚴格依賴演算法的準確性，所以系統上線初期，我們只上線了手動上下線的能力，需要在收集大量樣本後，不斷完善演算法，提高監控的準確性和靈敏度，再逐步切換至基於監控的通道自動化管理。

5 實現細節

5.1 資料結構

再來看下基於 Redis 的資料儲存是如何儲存的，雖然沒有使用時序資料庫，但是在資料結構選擇上也是結合了時序資料庫的儲存思想來設計的，下面就以最熱門的  InfluxDB 來對比看下：

• tags 標籤：記錄監控的維度，相對應的在 Redis 中選用的是 set 來儲存，利用 set 去重的特性，剛好可以記錄需要監控的指標。
• tims 時間：記錄發生的時間，相對應的在 Redis 中選用的是 zset 來儲存，在監控時需要根據時間範圍進行查詢，且要求是按照時間排序的，剛好可以利用 zset 的按照 score 來排序和查詢的特性，用於記錄監控點位的時間戳，為了避免資料量過大，這裡記錄的單位是秒，也就一秒一個點位。
• fields 資料：儲存具體的監控資料，相對應的在 Redis 中選用的是 hash 來儲存，利用 hash 中儲存 key、value 的特性，來記錄請求結果資料，記錄一個點位內（1 秒）的成功與失敗的情況，並記錄失敗的具體原因，key 用來儲存請求結果，value 用來記錄對應結果 1 秒內發生的次數。

最終 Redis 中儲存的結構樣例如下：

1.set
儲存已統計的維度，具體到商戶號
key: routeAlarm:alarmitems
value: 微信-打款-100000111
       微信-打款-100000112
       微信-打款-100000113
       .......

2.zset
儲存指定商戶號請求的時間戳（秒），同一秒的資料會覆蓋儲存
key: routeAlarm:alarmitem:timeStore:微信-打款-100000111
      score: 1657164225 value: 1657164225
      score: 1657164226 value: 1657164226
      score: 1657164227 value: 1657164227
      .......

3.hash
儲存指定商戶號1秒內的請求結果, 每秒彙總一份結果
key: routeAlarm:alarmitem:fieldStore:微信-打款-100000111:1657164225
      key: success             value: 10 (次數)
      key: fail                value: 5
      key: balance_not_enough  value: 3
      key: thrid_error         value: 2
      .......   

5.2 核心演算法

為了避免兩次監控間的小高峰被忽略，確保不漏報，我們的演算法採用的是區域性 計數法 加上整體 滑動視窗 的方式來實現的，每秒一個計數的點位，記錄成功和失敗的數量，監控時會計算整個視窗時間範圍內的成功失敗數，最終得出每個通道的失敗率，比如：視窗時間是1分鐘，監控頻率 10秒/次。

那麼監控頻率是多少、時間視窗範圍如何設定，這都會影響我們最終監控的準確性。如果監控頻率過小，就會導致我們的取數樣本太少，結果也沒有參考意義。如果監控頻率過大，兩次視窗之間的小高峰就可能存在漏報的情況，這些都是影響告警準確性的因素，這就需要透過對各個通道單據量級如：每天、每小時單量、下單頻率等指標進行分析而確定。

5.3 小流量的處理

小流量的通道和時間段要如何處理

• 從通道維度看，小流量的通道如何處理
• 從時間維度看，底峰時間段如何處理

比如轉轉接入的某一通道，每天總量只有幾單，或者凌晨的單量就是很少，針對這種小流量的處理方式是，在監控時間視窗內只有 1 單且失敗，則會擴大時間視窗，比如我們正常時間視窗是 1 分鐘，那麼擴大 1 倍後，時間視窗則變更為 2 分鐘，1-10 倍逐級增加，擴大到 10 倍之後如果還是高於預警閥值則會觸發告警，此時我們認為這種也是需要關注的異常。

6 最終效果

1. 通道異常告警，快速定位問題

2. 合併重複告警項

3. 通道異常恢復

7 未來規劃

目前的支付通道自動化管理系統還需要在以下幾個方面進行最佳化和升級：

1. 持續最佳化監控演算法，提升告警準確率到99%以上；
2. 與監控系統配合，實現通道故障時自動下線的能力；
3. 與監控系統配合，實現故障恢復探測及通道自動上線的能力；

關於作者：
張丹，轉轉支付結算技術部研發工程師，主要負責清結算方向的研發工作