移動支付時代，越來越多的人習慣于不帶現金出門，許多支付場景只需要掏出手機就能完成。正因為如此，收銀系統的可用性問題也越來越重要。如何打造移動支付時代的高可用收銀系統？這是微信支付團隊的經驗，僅供參考。
1、為什么強調收銀系統的可用性？
隨著移動支付高速發展，用戶已養成出門消費不帶錢包的習慣，頻繁的日常消費對商戶收銀系統高可用提出了極高的要求，收銀系統一點小小的故障如“付不了錢、重復支付、付款超時”等都會給用戶和商戶帶來諸多的不適和不利，引發用戶憤怒、投訴、糾紛，最終導致商戶的用戶流失。所以對于商戶來說如何打造高可用的收銀系統就變得十分的重要。
如何打造高可用收銀系統？看完本文，相信您將有所啟發。
2、高可用收銀系統設計方案
通過對市面上的收銀系統進行分析研究，發現普遍存在以下風險：
1.服務時延不穩定：
跨城調用、DNS配置不當，導致網絡不穩定；
2.系統可用性考慮不周：
多個支付渠道（支付寶、微信等）部署在一起，相互影響；
業務邏輯服務和數據服務部署在一起，相互影響；
無異地容災、自動切換能力；
3.數據容災恢復不及時：
DB單點、主備切換依賴人工、故障恢復時間（TTR）不可控；
為了幫助商戶提升服務質量，盡可能降低以上風險，微信支付團隊提出一套高可用收銀系統的設計方案，其系統架構圖如下所示：
接下來從三個層面分別闡述：
1.降低服務時延：
收銀系統線下門店遍布全國、網絡復雜（包含電信、聯通、鐵通、移動等），對系統時延提出更高挑戰。
針對這個問題，一些云服務商支持“BGP網絡訪問跨地域實時切換”的能力，通過冗余網絡出口部署，實現跨區域網絡間靈活切換調度，為網絡出口災備提供了保障。
另外騰訊云聯合微信支付推出支付加速方案，部署在騰訊云上的服務可以直接將發往微信支付的公網請求解析為內網訪問，將延時率減少30%，提升用戶支付體驗。
同時，微信支付官方還提供了api和api2兩個API域名，供服務商系統自行探測服務質量，優先選擇速度更快的域名進行訪問。
注：雙域名探測擇優有如下注意點：
并發探測，誰先回來誰先被采用，從而提升效率；
建立探測重試機制、控制探測頻率，減少不必要的探測；
建議的探測時機：系統開啟時發起探測，或請求超時發起探測；
2.云助力，低成本提升可用性：
文章開頭提到，在移動支付時代，用戶對收銀系統的可用性有更高的要求，這就迫使服務商做系統設計需要考慮更多因素。
由于這些因素實現成本比較高，純粹自己實現的話不太現實，所以這里筆者將結合比較熟悉的騰訊云提供的能力來進行闡述，建議身處云時代的服務商多了解這些能力，低成本解決高可用問題。
因素一、多地部署、多點接入：
利用騰訊云在全球20多個數據中心的基礎設施，很容易實現多地部署和多點接入，在架構層的高可用設計可以最大限度容忍單個地域網絡運營商故障和網絡抖動帶來的不穩定因素，并為全球各地的業務伙伴提供最優質的接入條件。
當網絡出現故障時，騰訊云全球內網互聯互通，及時調度業務流量至其他區域可以保證用戶體驗不受影響。
因素二、防DDoS攻擊：
DDoS攻擊將真正的用戶擋在門外，現在云服務商也會提供防御此類攻擊的服務。比如騰訊云大禹BGP高防系統提供800G防護帶寬和21道BGP線路，可以動態調度網絡流量，幫助用戶有效抵御DDoS攻擊。
因素三、負載均衡、故障屏蔽：
為了提升系統的穩定性和容災能力，業界比較成熟的解決方案是基于“無狀態的應用層服務設計”，做到能夠“實時監控服務器節點可用狀態、自動轉移失敗任務到其他可用節點、將集中請求分攤到集群各個機器節點的能力”。
身處云時代服務商可以借助騰訊云的負載均衡（CLB）能力來低成本解決這個問題。騰訊云的負載均衡具備健康檢查能力，可允許用戶自定義健康檢查頻率，以確保后端云服務器在出現故障時第一時間感知到并且及時切走業務流量，保證前端應用的高可用和無感知。
CLB單集群4臺物理服務器組成，最大并發連接數超過1.2億，可處理峰值40Gbps的流量，每秒處理包量為600萬。只有一臺實例可用的極端情況下，仍可支撐3000萬以上的并發連接，確保后端正常提供服務，高擴展和低成本的優勢最大限度節省IT成本。
因素四、過載保護：
移動支付目前處于高速增長期，各種營銷活動會帶來業務高峰。
一方面需要及時擴容，預留冗余服務能力；另一方面當實際業務流量遠超過系統的最大正常服務水平時進行自我保護，快速拒絕掉部分請求，保證正常的服務水平，而不是被拖垮影響全部服務；
建議采用云服務商提供的消息隊列，通過云上的分布式消息隊列CMQ提供可靠的異步通信，有效提升系統吞吐量，確保消息的可靠傳遞，減少后端系統壓力，防止系統雪崩。
另外騰訊云服務器具備彈性伸縮（Auto Scaling）能力，只需配置簡單的伸縮規則，集群即可在高負載時自動擴容縮容，確保業務平穩度過高峰。按量計費能力可以最大限度節省IT成本。
3.“跳單”，實現數據層秒級自動容災切換能力：
收銀系統的數據分成兩類，一類是訂單信息（主要包括訂單表和退款表，特點是數據量大且多讀多寫）；另一類是基礎信息（主要包含門店、設備、商戶等信息，特點是數據量少且多讀少寫）。這里介紹的數據庫高效容災實踐是基于訂單信息DＢ，以MySQL為例。
MySQL容災策略普遍依賴“半同步，主備切換”，通過自動或者人工切換（業務恢復時間在1分鐘到幾十分鐘之間）。這對于交易量稍大的場景來講，故障恢復時間還是太長。如何在更短的時間內達到恢復業務，我們設計了“跳單”的數據層容災解決方案。
核心思路：
在數據訪問層封裝一個“跳單”組件“自動避開有故障的存儲”，讓訂單數據數據可以隨意落到各個容器。
下面詳細介紹“跳單”的整體流程：
為了實現跳單邏輯，我們先將數據庫水平劃分為若干組，每組DB一主兩備、讀寫分離，主DB用來寫，從DB用于讀，主從同步由MySQL半同步機制來保證。
使用訂單號保存分組標記，如原先單號為201609121215432322199，可以在最后一位加分組標識，如組2，則變成2016091212154323221992
在這樣的前提下：
a）創建訂單請求：
收銀終端的一個創建訂單請求過來，先調用DB選擇器隨機選擇一組DB，然后查詢計數器，看該組DB失敗次數是否超出閾值，超限則跳過重選，否則通過探測器發送一條update語句，探測DB是否可用。如失敗則需重選DB，成功則把分組標記寫到單號，把訂單插入改組DB。
b）更新或查詢請求：
直接解析單號的分組標記，然后操作對應DB。“跳單”保證新交易是正常的，優先把支付做成。某組DB發生故障時，訂單查詢和撤銷等操作需等主備切換恢復才能進行。
這里的注意事項：
計數器需要設置周期，比如一分鐘，以便設備故障恢復自動啟用。
調用MYSQL的時候需要設置超時時間，比如1秒，避免某一組DB故障，拖死上層服務。
探測使用update語句，這是因為DB如果死機恢復了之后有可能是只讀狀態，如果發送select來探測就無法保證DB是可寫的。
3、做了“跳單“后的日常演練
為檢測系統是否真正高可用，需要做定期演練，以下是我們的日常演練計劃：
每周做一次單組DB故障的常規演練。
每季度做一次多組DB故障演練。
從下圖演練時的監控可見，當某組DB故障時請求會掉底發生跳單，但整體曲線平滑，業務運行正常，無影響。
4、做了“跳單”后的擴容和縮容
擴容步驟：
部署新的訂單DB，給它分配DB編號；
將新庫信息配置到DB選擇組件；
新庫接入業務流量；
觀察監控有無異常；
縮容步驟：
將撤掉DB的庫編號按收縮之后剩余DB數取模：例如原來有5組DB，收縮到3組，計劃撤掉庫5，則先把5庫模3得到2。
把數據遷移到庫2，修改配置，關閉庫5流量。新的訂單不會再進入庫5，而歷史查詢則通過取模訪問庫2即可。
監控無異常之后正式撤掉庫5。
5、做了“跳單”后的商戶維度查詢
多組DB容災方案有一個通用難題就是“商戶維度列表查詢效率問題”。訂單分散在不同的DB，若查詢量小則可直接采用全庫掃描，通過上層并發調用來解決效率問題。如果變成高頻操作，則需考慮額外搭建一套數據庫，以商戶緯度進行數據存儲，這兩套數據庫之間的數據同步采用可靠消息隊列來進行同步。具體推薦了解下騰訊云上面的PGXZ和MQ組件。
雖然因為“跳單”而帶來了列表查詢的效率問題，但是對收銀系統來說，核心設計理念還是“盡可能把支付做成”！不要因為列表查詢問題而影響到核心支付的可用性。
6、收銀系統安全性考慮
系統安全性也是衡量一個收銀系統可用性的關鍵指標，通過調研發現線下收銀系統有可能存在以下安全風險：
收銀終端軟件被非法安裝；
整臺pos機被盜；
中間人攻擊；
正常交易訂單被非法退款；
為了應對上述風險，我們提供以下策略供大家參考：
POS機注冊激活機制，即解決收銀終端軟件被非法安裝的問題，又可以在POS機被盜時直接屏蔽掉；
請求及響應參數簽名機制，防止客戶端偽造，及請求篡改；
走HTTPS協議，且限制合法根證書，防止中間人抓包、監聽、請求重放；
限制當天內的訂單可以在當時交易的POS機上發起退款，超過一天的只能通過微信支付商戶系統進行退款，解決惡意退款問題。
另外微信支付官方安全團隊也在微信支付的開發者文檔里面加入了“最佳安全實踐”，大家可以自行前往查看。
7、推薦使用微信支付網絡監控工具
為了更好的監控商戶服務器與微信支付服務器之間的網絡質量，微信支付的運維團隊提供了一套網絡監控工具，通過將監控數據上報到微信支付的運維系統，方便運維人員幫助商戶優化鏈路質量。
該工具的詳細使用說明可以看微信支付開發者文檔中的說明。
8、寫在最后
綜上所述，從無到有搭建一套高可用收銀系統要考慮的問題點很多。全部自建成本不低，建議多關注云服務商提供的一些基礎能力（BGP高防、BGP網絡訪問跨地域實時切換、分布式消息隊列CMQ、負載均衡CLB、彈性伸縮AS、TDSQL、“云支付”等），盡可能站在云時代的基礎設施上來進行高效研發才是更加明智的選擇。
再次強調，我們追求的是“盡可能把支付做成”！
