前言

說起支付平臺，支付寶量級的支付平臺和一個小型公司的支付不可同日耳語。一個初創或剛創業一兩年的公司，一沒人力，二沒財力的情況下，如果也想對接支付那怎么辦呢？感謝支付寶和微信支付，兩大行業巨頭提供了簡單易用的方案，簡化了對接流程，又能支持大部分銀行。今天我們就來根據不同業務規模，設計一個能經受業務考驗的支付平臺。

第一階段

舉個例子，阿力空閑時間，接了個外包的分銷系統。業務模型如：成為會員，可以自動帶二維碼的分銷海報，掃描你二維碼的人成為會員后，你獲得提成。

這個例子有幾個核心步驟：

申請會員，支付成為會員，自動生成海報，

計算分銷提成。

有點小挑戰的自動生成海報。這個可以參考微信參數二維碼接口和GDI+繪制圖片來搞定，利用html5的canvas也能搞定。

最核心的部分，當然是支付。

先來一張訂單表流程圖壓壓場面。

訂單模型

前些天看領域驅動提到了核心域和子域，那么整個交易流程是是這個模型的核心域，訂單表是交易流程的子域。

我大概說下這些字段，業務類型和業務id以及業務處理url實現了各個業務的解藕，各個業務線都有自己的限界上下文。它可以根據取消日期和取消地址完成訂單的取消動作，可以根據支付平臺交易id和支付平臺查詢對賬。業務通知狀態是用來綜述通知業務處理是否成功。說完了訂單，讓我們來看下整體交易流程。

交易流程

訂單有三個主流程，提交訂單是用戶主動觸發，支付回調是屬于支付平臺觸發，定時取消是后臺任務根據設定的取消時間自動運行，小業務可以不考慮訂單取消問題。

這樣來說，第一版支付中心就完成了。由于剛上線，流量每天很少，平穩了運行一段時間后，也許會出現支付平臺支付，但搭建的支付中心卻未支付，只能手動修改數據庫了，并觸發業務回調了，這在最終一致性里，可以成為人工補償。后來不厭其煩，加了個支付日志，記錄任何與支付平臺交互的信息，然后每隔一段時間掃描最近變更的日志表，并和訂單表對比，發現不匹配的，修復為已支付，完美的解決了這個問題，這在最終一致性里，可概括為定時補償。

交易日志表

老板缺少人手，業務量又上升，又對阿力解決問題的能力很欣賞，就直接把阿力工資翻倍從原公司挖了過來。（故事純屬虛構）

第二階段

剛過來新公司不久，就接到了一筆融資，然后新公司擴招了很多同事，市場銷售人一多，產品線更多，線上支付流量也加快起來。阿力信心滿滿，覺得很有干勁。得意不久，就遇到了服務線反饋的問題：有客戶重復支付，需要退款。于是改訂單，清理數據，財務退款，臨時解決了問題。后來次數多了，手工處理及易出錯，就查詢支付寶和微信的自動退款接口，然后依賴日志表記錄過支付成功對比判定重復支付，發起退款，引入了自動退款流程。

交易流程補充自動退款流程

然后又接到了一個線上客戶需要搶購的需求，每月有一天集中一起搶，類似小米秒殺那樣。然后到了激動的那天，系統撐過了三分鐘，華麗麗的掛了！熬了二十分鐘才恢復正常。

痛定思通，支付中心進入重構優化階段。由于公司人員擴張，有時間和精力和能力去重購優化更健康的業務架構。

一，引入消息隊列Rabbitmq支撐流量削峰。如支付回調先進消息隊列，由消息隊列去通知業務。大幅度縮短單次請求處理時間，提升兵法能力。

二，全面引入Redis緩存，減小數據庫訪問壓力，部分關鍵業務表啟用HttpRuntime緩存，性能指數級提升。

三，引入專業調度工具quartz.net或hangfire。可以用來處理定時查詢訂單交易問題，及退費問題。

四，購買商業.net監控平臺，如聽云。檢測程序性能。

阿力跟隨新公司技術體系，也對支付中心實現了升級。

支付平臺回調通知后，先轉發到消息隊列，由消息隊列來通知業務處理，如失敗后延時轉發到消息隊列繼續執行，最高重試5次，然后發短信或郵件通知責任人。

針對之前線上支付平臺和自建平臺不一致問題，利用hangfire調度機制定時每天晚上拉取一周數據和支付平臺核對。確保了兩個異構系統的一致性。

為防止支付平臺同時通知，造成兩條支付日志，先更新訂單成功后，在隊列里，用redis的incr和decr原子性操作，來確保只能同時操作一個訂單，另一個通知延遲處理。

數據庫開啟讀寫分離，部署集群。

經過阿力和同事們兩個月的協力合作與加班加點，新系統終于在那個客戶第三次線上搶購前一段時間上線。經過線上搶購驗證，新的系統輕輕松松的抗過了搶購，大家一片歡聲笑語。阿力看到十幾分鐘XX百萬的交易額驚呆了！，這真是金牌客戶啊！

到了年底，微信紅包火熱起來，許多客戶申請開通微信紅包，有家客戶粉絲有二十多萬，發的錢也特別多。當時一到點，十萬人齊刷刷搖手機搶紅包。最后，重啟了幾遍應用程序池也不頂用。針對如此的流量，我們應該怎么辦呢？每秒萬級的請求暫時就不是小公司處理的來的，況且這流量就過年才有，像級了春運。人有那么多，搶到紅包的人是有限的。百分之九十五的人都是無效流量。那就取巧吧，隨機抽取一部分人的數據進入服務器，其他的人就本地留存吧，通過這種思路減少了一大部分流量。

只考慮第一，第二階段的話，上面關于支付中心的思考架構是完全可以滿足交易量的。況且又有多少公司能邁向獨角獸之路呢？

念天地之悠悠，獨愴然而淚下！

第三階段

上面那種方式雖然取巧，針對特定業務，本來就是搶紅包，大部分人都是無效的，能說的過去，假如是主業務流程有萬級每秒甚至百萬千萬級每秒的請求量應該怎么辦呢？阿力陷入了迷茫。

聽說過docker，kuberneters為代表的容器編排，聽說過CI/CD自動部署，聽說過微服務的強大，聽說過負載均衡，仿佛都是方向。

大海跨不過陸地，臺風卻能輕易穿梭，大化為小，繁化為簡，聚簡成面，規模化微服務也許才是解決巨量請求之道！(故事純屬虛構，不要代號入座)

附錄:最終一致性

說完了解決中小型流量的問題，我們來了解下一致性問題。

1、關系型數據庫事務追求ACID:

A: Atomicity，原子性

C: Consistency，一致性

I: Isolation，隔離性

D: Durability，持久性

2、CAP（帽子理論）

C：Consistency，一致性, 數據一致更新，所有數據變動都是同步的

A：Availability，可用性, 好的響應性能，完全的可用性指的是在任何故障模型下，服務都會在有限的時間處理響應

P：Partition tolerance，分區容錯性，可靠性

帽子理論證明，任何分布式系統只可同時滿足二點，沒法三者兼顧

3、Base模型:

BA：Basically Available，基本可用

S：Soft State，軟狀態，狀態可以有一段時間不同步

E：Eventually Consistent，最終一致，最終數據是一致的就可以了，而不是時時保持強一致

利用查詢模式，補償模式，異步確保模式，定時校對模式等可實現分布式系統最終一致性。

最終一致性更詳細用法參考李艷鵬老師關于分布式一致性的講解。https://www.jianshu.com/p/1156151e20c8?from=singlemessage&isappinstalled=0

后言

阿力解決了支付中心的穩定問題后，就買了許多書，看到了上面關于最終一致性的陳述時，心里想到，這些都是我已經實現了的，原來還有這么多頭頭道道？？

阿力又看到了領域驅動設計等書，感慨：支付領域模型真是學習領域驅動設計的最好實踐。它具有獨立的限界上下文，通過回調url和其他業務限界上下文溝通。

最后再用交易流程在做個總結吧！

交易流程

關鍵點:

1.回調部分，有消息隊列通知，并支持失敗重試。

2.每天晚上定時拉取支付平臺對象記錄核賬，保證最終一致性。

3.支付平臺回調時，根據支付日志判定是否重復支付，重復支付的發起自動退款。

源碼

計劃用.netcore按領域驅動的方式，完成以上設計。日期未定。

聲明

全文除附錄部分最終一致性外，均為原創。如文章能給你帶來幫助，請點下推薦，感謝支持。

相關文章：

• ICanPay 統一支付網關

• ASP.NET Core 2.0 使用支付寶PC網站支付

• ASP.NET Core Web 支付功能接入 微信-掃碼支付篇

• 微信和支付寶支付模式詳解及實現（.Net標準庫）

原文鏈接：https://www.cnblogs.com/fancunwei/p/9612567.html

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的.Net架构篇:实用中小型公司支付中心设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。