一、支付系統的簡介

什麼是支付系統？自古以來，所有的商業活動都會伴隨著經濟的收款與付款行為。隨著時代的發展，記錄收付款行為的方式不斷迭代：古代的錢莊通過手工（算盤）記賬，工業社會通過收銀機機械記賬……

現在，網際網路/移動網際網路時代，我們的商業行為也一同進行了數字化與資訊化的演變，這就是所謂的電子商務。

支付系統伴隨著電子商務的發展而出現，它為各類電子商務經營活動實現線上收付款交易以及管理交易資金等功能，獲得支付牌照的第三方支付公司可以參與資金的核算及存管，簡單說就是可以在合法期限、合法範圍內挪用資金。是具有一定獨立性的內部系統模組----很多公司稱之為中颱。

二、支付行業發展的前世今生

億歐網上一篇中國支付行業發展史裡的圖片，既形象又簡潔的代表了支付行業發展的前世今生：

而近代的支付行業發展史，可簡單描述為以下幾個時代：

第一個是現金時代第二個是刷卡時代

第三個是二維碼時代第四個是刷臉時代

三、網際網路支付系統架構

以小編之前在第三方支付公司工作的經歷來說，有幸參與了公司從0到1搭建支付系統（重構）的過程。完整熟悉了支付行業生態及產品業務，基於微服務分散式全新搭建的一套支付系統。檢視另一篇文章，小編在支付公司的經歷：

3.1 主要技術棧：

JavaSpringBoot/SpringCloudMyBatisRedisKafkaswagger2ELKMaven

3.2 設計原則

分而治之微服務化：根據業務功能、不同的效能需求等將系統劃分為多個微服務，每個微服務獨立開發、獨立部署、獨立執行，擁有獨立的資料庫儲存，各個微服務之間使用介面通訊，不允許跨微服務訪問資料庫。服務分層：支付系統系統的微服務按照在業務處理流程中的地位以及後續功能變更頻率分為公共服務層、基礎業務服務層、基礎支撐服務層。業務與平臺分離：業務系統（包括公司的業務系統和商戶系統）與平臺從開發到部署完全分離，尤其需要強調的是公司的業務系統與公司在部署上也需分離，例如部分特殊的業務可部署在阿里雲。前後端分離：所有包含介面的子系統遵循該原則，後端負責提供基礎的業務服務介面，前端負責展示介面的邏輯（前端包括客戶端的JS、後續可能的APP介面以及部署在服務端的負責根據介面展示需求聚合請求的Node.js等）。動靜分離：靜態資源和動態請求分離開發和部署，靜態資源後期可考慮上CDN。業務驅動設計：處理流程不強行抽象：例如支付服務的不同支付方式的處理流程如果存在較大不同，則內部處理邏輯不強行抽象，避免各個環節均在判斷的情況。介面不強行抽象，根據業務適度抽象定義介面，避免大而全的接口出現注重非功能性品質要求：所有服務均採用叢集+業務呼叫無狀態化自動降級、限流非同步優於同步，示例如下：不追求強一致性，保證最終一致性微服務間同步呼叫採用HTTP協議，不使用二進位制協議，保證資料互動的良好可讀性如果微服務A的業務處理過程中，需要驅動微服務B進行相關處理，但是並不依賴微服務B的處理結果，則使用非同步訊息機制，避免各個微服務之間產生不必要的效能耦合；例如清算服務非同步通知支付服務清算結果，賬務系統驅動會計系統執行會計分錄等。對上游渠道的通知處理，僅完成必要的處理後即返回，保證對上游渠道系統的友好性效能：避免不必要的效能損耗，合適的追求效能提升可用性：充分考慮各種情況安全性

3.3 架構邏輯

系統整體採用微服務架構，各個微服務獨立開發、獨立部署、獨立執行、擁有獨立的資料庫，各個微服務之間介面進行通訊，不共享任何檔案、資料。

系統邏輯上分為產品應用層、接入層，公共服務層、基礎業務服務層和基礎支撐服務層五層，外加跨各層的運維支撐的系統，如下圖所示。

四、支付產品

支付產品是由支付系統對支付渠道進行封裝而對業務方提供的支付能力，基礎支付產品分類如下：

賬戶產品：企業賬戶服務（充值、提現、轉賬等） 集團賬戶（分級管理、資金調撥等）基礎收款產品：代收代付、分賬、分潤等基礎付款產品：批量付款、委託結算等

網際網路支付產品，結合支付場景和流程，產品的主要應用和分類又分為如下所示：

各位老鐵記得點一手關注再走哦！