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