服务端技术进阶(三)从架构到监控报警，支付系统的设计如何步步为营
文章目錄
- 一、前言
- 二、支付系統(tǒng)架構
- 2.1 支付業(yè)務流程
- 2.2 支付的典型架構
- 三、支付系統(tǒng)的監(jiān)控與報警
- 3.1 系統(tǒng)監(jiān)控
- 3.2 JVM監(jiān)控
- 3.3 服務監(jiān)控
- 3.4 數(shù)據(jù)庫監(jiān)控
- 3.5 調(diào)用鏈監(jiān)控
- 3.6 業(yè)務監(jiān)控
- 四、監(jiān)控架構
- 4.1 日志收集
- 4.2 日志數(shù)據(jù)流
- 4.3 日志分析
- 4.4 日志系統(tǒng)與日志框架
- 4.5 日志系統(tǒng)選型
- 4.6 日志高能預警
一、前言
企業(yè)所處發(fā)展階段不同，對支付系統(tǒng)的定位和架構也不盡相同。整體上來說，可以把一個公司的支付系統(tǒng)發(fā)展分為三個階段：
- 支付系統(tǒng)：支付作為一個封閉、獨立的應用系統(tǒng)，為各系統(tǒng)提供支付功能支持。一般來說，這個系統(tǒng)僅限于為公司內(nèi)部的業(yè)務提供支付支持，并且和業(yè)務緊密耦合。
- 支付服務：支付作為一個開發(fā)的系統(tǒng)，為公司內(nèi)外部系統(tǒng)、各種業(yè)務提供支付服務。支付服務本身應該是和具體的業(yè)務解耦合的。
- 支付平臺：支付作為一個可擴展的平臺， 公司內(nèi)外部用戶可以在此基礎上定制開發(fā)自己的服務。
這個劃分有點勉強。簡單說，支付系統(tǒng)是僅供內(nèi)部使用的，支付服務是支持公司內(nèi)外部來調(diào)用的，支付平臺是可以在服務的基礎上定制各種場景支持的。
二、支付系統(tǒng)架構
2.1 支付業(yè)務流程
區(qū)分兩個概念：支付和交易。支付是交易的一部分。一個簡單的交易過程包括：客戶下訂單，客戶完成支付，商家接收訂單，商家出貨。這里僅考慮下訂單的流程。從軟件工程的角度， 首先需要明確下幾個參與者：
- 電商系統(tǒng)，指提供在線購物服務的系統(tǒng)，用戶在這個系統(tǒng)中完成交易。
- 支付系統(tǒng)，可以是電商系統(tǒng)的一個模塊，或者是個獨立的系統(tǒng)。這是本文的主角，用來完成支付過程。
- 用戶，在電商系統(tǒng)中敗家的那位。如果使用銀行卡做交易，那也被稱為持卡人。
- 用戶使用銀行卡交易時，發(fā)行這個銀行卡的機構稱為發(fā)卡行，或者發(fā)卡機構。
- 商家也需要一張卡，就是大家在淘寶開網(wǎng)店的時候要登記的銀行卡，最終需要把用戶給的錢打到這張卡上。
- 和發(fā)卡機構相對應的，大家聽到最多的是收單機構。如支付寶，微信等第三方支付公司，介紹業(yè)務的時候總少不了互聯(lián)網(wǎng)收單的工作。它們把用戶訂單收起來，找發(fā)卡行要錢，就有了收單業(yè)務。
主演都有了，下面就是如何演出支付這場大戲了。正常的流程應該是這樣：
比如100塊錢的商品，用戶支付了100塊錢（運費、打折等另算），這100塊錢，還要刨去電商系統(tǒng)的傭金、支付通道的手續(xù)費，才能最終落到商家手里。
這是個Happy流程，一切看起來都很美好，但實際上步步都是坑，一旦有地方考慮不周全，輕者掉單頻發(fā)，重者接口被盜刷，損失慘重。
如何避免攻擊者修改支付接口參數(shù)， 比如100塊錢的東西，改成10塊錢？
調(diào)用收單接口來執(zhí)行最終實際支付時，如果支付失敗了，比如卡上沒錢了，怎么辦？
收單接口把賬戶上的錢扣走了，但是通知支付系統(tǒng)的時候出錯了（比如網(wǎng)絡閃斷，或者支付系統(tǒng)重啟了），支付系統(tǒng)不知道這筆交易已經(jīng)達成了，怎么處理？還有好多問題……
和錢打交道，在任何公司，都跑不掉財務部門。 那財務部門會關注哪些內(nèi)容？當然，最重要的是賬務信息。所有的交易都要記賬，按要求公司都需要定期做審計，每一筆帳都不能出錯。這當然不能等到審計的時候再去核對，而是每天都需要對賬，確保所有的交易支出相抵，也就是所說的把賬給平了。這就有三種情況：電商系統(tǒng)和商家對賬；電商系統(tǒng)和支付系統(tǒng)對賬；支付系統(tǒng)和收單機構對賬。作為支付系統(tǒng)，我們僅關注后兩者的情況。
從軟件開發(fā)角度，還有一些非功能性需求需要實現(xiàn)：
- 性能：特別是秒殺的時候，如何滿足高頻率的支付需求？
- 可靠性：不用說，系統(tǒng)能達到幾個9，是衡量軟件設計功力的重要指標。 99%是基礎，99.999%是目標，更多的9那就是神了。
- 易用性：支付中多一個步驟，就會流失至少2%的用戶。產(chǎn)品經(jīng)理都在削尖腦袋想想怎么讓用戶趕緊掏錢。
- 可擴展性：近年來支付業(yè)務創(chuàng)新產(chǎn)品多，一元購、紅包、打賞等，還有各種的支付場景。怎么能夠快速滿足產(chǎn)品經(jīng)理的需求，盡快上線來搶占市場，可擴展性對支付系統(tǒng)設計也是一個挑戰(zhàn)。
- 可伸縮性：為了支持公司業(yè)務，搞一些促銷活動是必須的。那促銷帶來的爆發(fā)流量，最佳應對方法就是加機器了。平時流量低，用不了那么多機器，該釋放的就釋放掉了，給公司省點錢。
2.2 支付的典型架構
所以支付的坑還不少，先看看互聯(lián)網(wǎng)的頭牌們是如何設計支付系統(tǒng)的？ 先看看某團的：
再看某Q旅游公司的：
對比下某東金融的：
最后看看業(yè)界最強的某金服金融的：
整體上來說，從分層的角度，支付系統(tǒng)和普通的業(yè)務系統(tǒng)并沒有本質(zhì)的區(qū)別，也是應用、服務、接口、引擎、存儲等分層。
在應用層，支付系統(tǒng)一般會提供如下子系統(tǒng)：
- 支付應用和產(chǎn)品(應用層)：這是針對各端（PC Web端、android、IOS)的應用和產(chǎn)品。為各個業(yè)務系統(tǒng)提供收銀臺支持，同時支付作為一個獨立的模塊，可以提供諸如銀行卡管理、理財、零錢、虛擬幣管理、交易記錄查閱、卡券等功能；
- 支付運營系統(tǒng)(應用層)：支付系統(tǒng)從安全的角度來說，有一個重要的要求是：懂代碼的不碰線上，管運營的不碰代碼。這對運營系統(tǒng)的要求就很高，要求基本上所有線上的問題，都可以通過運營系統(tǒng)來解決。
- 支付BI系統(tǒng)(應用層): 支付中產(chǎn)生大量的數(shù)據(jù)，對這些數(shù)據(jù)進行分析，有助于公司老板們了解運營狀況，進行決策支持。
- 風控系統(tǒng)(應用層)：這是合規(guī)要求的風險控制、反洗錢合規(guī)等。
- 信用信息管理系統(tǒng)(應用層)：用來支持對信用算法做配置，對用戶的信用信息做管理。
其他各層功能：
- 支付服務層：為上述各端系統(tǒng)提供API。這些API也可以提供給業(yè)務系統(tǒng)直接使用。
- 接口層：和各相關系統(tǒng)對接的接口，其中最重要的是和支付渠道對接的支付網(wǎng)關。
- 引擎層：包括統(tǒng)計分析、風控、反洗錢、信用評估等在后臺運行的各個系統(tǒng)。
- 存儲層：各種持久化的數(shù)據(jù)庫支持。
這其實也是普通互聯(lián)網(wǎng)應用系統(tǒng)架構，沒有什么特別之處。比如微服務如何體現(xiàn)，如何滿足性能需求等，在這個視圖中無法體現(xiàn)出來。這只是個軟件角度的高層視圖，后續(xù)我們對各個主要模塊進行分解，從分解視圖中可以知道如何滿足非功能性需求。
三、支付系統(tǒng)的監(jiān)控與報警
關于監(jiān)控，在各個技術網(wǎng)站，幾乎都是一搜一大把。幾個大的互聯(lián)網(wǎng)公司，也都有開發(fā)自己的監(jiān)控系統(tǒng)。關于這方面也有不少分享。這里介紹針對支付系統(tǒng)的監(jiān)控和報警，但大部分內(nèi)容，應該來說，對其他系統(tǒng)也是通用的。
現(xiàn)在基本上Zabbix成為監(jiān)控的標配了。一個常規(guī)的Zabbix監(jiān)控實現(xiàn)，是在被監(jiān)控的機器上部署Zabbix Agent，從日志中收集所需要的數(shù)據(jù)，分析出監(jiān)控指標，發(fā)送到zabbix服務器上。zabbix監(jiān)控這種方式要求每個機器上部署Zabbix客戶端，并配置數(shù)據(jù)收集腳本。Zabbix的部署可以作為必裝軟件隨操作系統(tǒng)一起安裝。
3.1 系統(tǒng)監(jiān)控
先說相對比較簡單的系統(tǒng)監(jiān)控，一般系統(tǒng)監(jiān)控關注如下指標：
- CPU負載
- 內(nèi)存使用率
- 磁盤使用率
- 網(wǎng)絡帶寬占用
這些指標在Zabbix agent中會提供默認實現(xiàn)，通過簡單配置即可激活。裝機時可以考慮統(tǒng)一配置這些監(jiān)控。
3.2 JVM監(jiān)控
JMX提供了關于JVM的大部分核心信息，啟動時設置參數(shù)，支持遠程訪問JMX，之后即可通過接入JMX來實時讀取JVM的CPU、內(nèi)存等信息。Zabbix也支持通過JMX來獲取信息。
3.3 服務監(jiān)控
服務監(jiān)控主要指接口的狀態(tài)監(jiān)控。服務監(jiān)控關注如下指標：
- QPS：每秒請求數(shù)，對于使用容器的系統(tǒng)，包括Apache Tomcat,Resin,JBoss等，可以從Access Log中采集到每個接口的QPS。沒輸出Access Log的系統(tǒng)，考慮通過Annotation來規(guī)范輸出訪問計數(shù)。當然，這個指標還可以細分為每秒成功請求數(shù)、失敗請求數(shù)、總請求數(shù)等。
- 請求響應時間：在服務器端監(jiān)控每個接口的響應時間。簡單做法是在方法執(zhí)行前后打時間戳計算，對于HTTP請求，也可以從access log中獲取接口執(zhí)行時間。當然也可以用annotation來實現(xiàn)統(tǒng)一的執(zhí)行時間監(jiān)控。
- 執(zhí)行異常數(shù)：指程序運行過程中發(fā)生的未捕獲處理的異常，一般是對場景考慮不周導致的異常發(fā)生，比如空指針、錯誤參數(shù)、數(shù)據(jù)訪問等的異常。這些異常一旦發(fā)現(xiàn)，需要修復代碼邏輯。異常在應用日志中一般都會把錯誤堆棧打印出來。
3.4 數(shù)據(jù)庫監(jiān)控
數(shù)據(jù)庫是大部分應用的核心和瓶頸，對其監(jiān)控尤其必要。監(jiān)控可以在應用側執(zhí)行，也可以在數(shù)據(jù)庫服務器上做。前者通過應用代碼中打印日志來實現(xiàn)，或者直接override 鏈接池中相關方法來統(tǒng)一輸出日志。
在數(shù)據(jù)庫服務器上執(zhí)行監(jiān)控，需要根據(jù)數(shù)據(jù)庫的特點分別設計方案。以MySQL為例，可以通過監(jiān)控其bin log來獲取執(zhí)行的sql語句以及執(zhí)行時間。使用Alibaba Canal來對接MySQL的BinLog， 接收到BinLog消息后，解析消息數(shù)據(jù)，可以獲取請求的SQL、參數(shù)、執(zhí)行時間、錯誤代碼等信息。
數(shù)據(jù)庫監(jiān)控重點關注如下指標：
- 每秒請求數(shù)QPS
- 慢查詢處理數(shù)
- SQL語句執(zhí)行時間
3.5 調(diào)用鏈監(jiān)控
調(diào)用鏈監(jiān)控指在微服務系統(tǒng)中，跟蹤一個請求從發(fā)起到返回，在各個相關系統(tǒng)中的調(diào)用情況。
調(diào)用鏈監(jiān)控是跨系統(tǒng)的監(jiān)控，需要在請求發(fā)起時分配一個可以唯一識別本次調(diào)用請求（或者成為事務）的ID，這個ID會被分發(fā)到每個調(diào)用上。之后在調(diào)用日志中輸出該ID。當所有日志都匯總起來后，可以從日志中分析本次調(diào)用的流程。對于HTTP/HTTPS請求，可以考慮將ID放到Header里面，這樣不會影響接口邏輯。
3.6 業(yè)務監(jiān)控
業(yè)務監(jiān)控是一個復雜的話題。這里以支付為例，說明業(yè)務監(jiān)控的架構和實現(xiàn)。
支付業(yè)務監(jiān)控
每個支付通道監(jiān)控包括如下內(nèi)容：
- 支付通道接口請求數(shù)：如果一段時間內(nèi)接口請求環(huán)比大幅度下降，可能是該接口出現(xiàn)問題了。
- 支付通道接口請求失敗數(shù)，即調(diào)用接口失敗的數(shù)量。
- 支付通道接口請求延遲。
- 支付通道支付失敗率。每個通道支付有一定的失敗率，如果給定時間內(nèi)突然有超過這個失敗率的情況出現(xiàn)，則可能是通道出現(xiàn)問題了。
- 支付通道同步、異步調(diào)用次數(shù)。
支付接口，如支付、提現(xiàn)、退款、簽約、訂閱等，監(jiān)控如下內(nèi)容：
- 總金額，如果總金額有大的波動，則有洗錢的可能
- 每筆平均金額
- 支付成功率
四、監(jiān)控架構
實際上對一個業(yè)務來說，大部分系統(tǒng)監(jiān)控的指標是類似的，而按照這種方式，每個指標在各個被監(jiān)控系統(tǒng)中還需要單獨寫腳本實現(xiàn)，工作量大。針對這種情況，可以采用日志集中監(jiān)控的方式來處理。考慮到日志最終都需要歸并到一個日志倉庫中，這個倉庫可以有很多用途，特別是日常維護中的日志查詢工作。多數(shù)指標可以在日志上完成計算的。借助這個系統(tǒng)，也可以完成監(jiān)控：zabbix監(jiān)控。
日志通過Apache Flume來收集，通過Apache Kafka來匯總，一般最后日志都歸檔到Elastic中。統(tǒng)計分析工作也可以基于Elastic來做，但這個不推薦。 使用Apache Spark的Streaming組件來接入Apache Kafka完成監(jiān)控指標的提取和計算，將結果推送到Zabbix服務器上，就可以實現(xiàn)可擴展的監(jiān)控。
這個架構的優(yōu)勢在于：
- 監(jiān)控腳本的跨系統(tǒng)使用。 指定日志規(guī)范后，只要按照這個規(guī)范編制的日志，都可以納入監(jiān)控，無需額外配置。
- 服務重新部署時無須考慮監(jiān)控腳本的部署，所有監(jiān)控直接生效。
難點在于，提煉一套通用的日志規(guī)范，考慮如何通過Spark來分析日志。
4.1 日志收集
Flume和logstash都可以用于日志收集，從實際使用來看，兩者在性能上并無太大差異。flume是java系統(tǒng)，logstash是ruby系統(tǒng)。使用中都會涉及到對系統(tǒng)的擴展，這就看那個語言你能hold住了。
4.2 日志數(shù)據(jù)流
Flume和Logstash都支持日志直接入庫，即寫入HDFS，Elastic等，有必要中間加一層Kafka嗎？太有必要了，日志直接入庫，以后分析就限制于這個庫里面了。接入Kafka后，對于需要日志數(shù)據(jù)的應用，可以在kafka上做準實時數(shù)據(jù)流分析，并將結果保存到需要的數(shù)據(jù)庫中。
4.3 日志分析
Streaming分析，可以走Spark，也可以用Storm，甚至直接接入kafka做單機處理。這取決于日志數(shù)據(jù)規(guī)模了。Spark streaming是推薦的，社區(qū)活躍度高，又集成了多種算法。
4.4 日志系統(tǒng)與日志框架
Java主流的日志系統(tǒng)有l(wèi)og4j，JULlogback等，日志框架有apache commons logging，slf等，關于這些系統(tǒng)的歷史掌故恩怨情仇八卦趣事，網(wǎng)上有不少資料，這里不詳細介紹。
4.5 日志系統(tǒng)選型
最好的編程語言是PHP還是Java？同樣的，也有爭論：最好的日志框架是slf還是commons-logging？最好的日志系統(tǒng)是Log4j還是Logback？在使用上，它們的API和使用方式大體類似，slf有模版支持，但這也不是關鍵需求。而性能方面，從測試用例中也沒有發(fā)現(xiàn)哪個系統(tǒng)或框架有明顯優(yōu)勢。對性能有決定性影響的是使用方式。
4.6 日志高能預警
根據(jù)測試結果，在高并發(fā)系統(tǒng)中，關于日志，有如下結論：
- Log4j與logback在高并發(fā)下業(yè)務場景下性能上并無太多差異，不用太糾結使用哪個API，影響性能的是日志內(nèi)容的寫法和數(shù)據(jù)量。
- 輸出類名和行號會嚴重影響性能，這需要使用到性能不佳的反射機制。執(zhí)行頻率高，性能要求高的代碼，禁用反射，禁用new操作。
- 高峰期系統(tǒng)出錯，如果打印錯誤堆棧，那絕對是雪上加霜，理由同上。
- 多線程時輸出日志，寫鎖是影響性能的關鍵因素。緩解寫鎖的措施，首選加大日志寫入緩沖區(qū)，其次是異步打印。異步對性能有提升，但不顯著。寫鎖出問題的一個現(xiàn)象是CPU跑滿。
- 日志分級本身無太大意義。
總結
以上是生活随笔為你收集整理的服务端技术进阶(三)从架构到监控报警，支付系统的设计如何步步为营的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【图像融合】基于脉冲神经网络PCNN实现
- 下一篇： Window系统安装FFmpeg教程