所有的支付系統(tǒng)都對(duì)接了很多的外部支付、流出、外匯等各種類型的渠道，這些渠道的接口和報(bào)文格式各異。今天和大家一起聊聊如何實(shí)現(xiàn)一種簡潔高效的低代碼報(bào)文網(wǎng)關(guān)設(shè)計(jì)，主要包括：報(bào)文網(wǎng)關(guān)的定位，三種形態(tài)，低代碼報(bào)文網(wǎng)關(guān)的設(shè)計(jì)思路，系統(tǒng)架構(gòu)，核心代碼實(shí)現(xiàn)。

如果你做過支付系統(tǒng)并寫過腳本或代碼對(duì)接過渠道，或者你好奇如何通過低代碼來對(duì)接外部千奇百怪的渠道，歡迎一起探索。

1. 前言

在數(shù)字支付領(lǐng)域的深處，存在著一個(gè)關(guān)鍵的、卻往往被忽視的英雄——報(bào)文網(wǎng)關(guān)。作為支付系統(tǒng)與外部世界溝通的橋梁，報(bào)文網(wǎng)關(guān)承擔(dān)著參數(shù)轉(zhuǎn)換、報(bào)文組裝與解析、安全加密、簽名驗(yàn)簽等多重重要任務(wù)。

一般來說，小型公司可能根本就沒有報(bào)文網(wǎng)關(guān)這一說法，直接引入HttpClient包，手?jǐn)]幾個(gè)類，就把一個(gè)渠道對(duì)接搞定。稍大的公司，可能做一些模板方法的抽象，或者一些組件的抽象，也能實(shí)現(xiàn)一定的高效接入及復(fù)用。但對(duì)于更大型跨國公司，如果接入的渠道有幾百條，這樣手寫接入渠道，往往伴隨著代碼高復(fù)雜性和高維護(hù)成本。因應(yīng)這一挑戰(zhàn)，"低代碼報(bào)文網(wǎng)關(guān)"的概念應(yīng)運(yùn)而生。

在本文中，我們將一起探索這種低代碼報(bào)文網(wǎng)關(guān)的創(chuàng)新設(shè)計(jì)。我們會(huì)從報(bào)文網(wǎng)關(guān)在支付系統(tǒng)中的角色和重要性入手，然后深入探討低代碼報(bào)文網(wǎng)關(guān)的工作原理、產(chǎn)品架構(gòu)、系統(tǒng)架構(gòu)以及核心代碼實(shí)現(xiàn)。我們的目標(biāo)不僅是理解其技術(shù)細(xì)節(jié)，更是領(lǐng)悟其背后的設(shè)計(jì)哲學(xué)——如何在保證系統(tǒng)強(qiáng)大功能的同時(shí)，實(shí)現(xiàn)更高的接入效率和可維護(hù)性。

這篇文章旨在為廣大支付技術(shù)從業(yè)者、軟件開發(fā)者以及對(duì)支付系統(tǒng)感興趣的讀者們，提供一個(gè)全新視角來理解和應(yīng)用低代碼報(bào)文網(wǎng)關(guān)。

2. 報(bào)文網(wǎng)關(guān)在支付系統(tǒng)中的定位

報(bào)文網(wǎng)關(guān)最核心的職責(zé)就是對(duì)接外部渠道的API接口，把內(nèi)部的請(qǐng)求發(fā)出去，把渠道返回的數(shù)據(jù)轉(zhuǎn)成內(nèi)部的參數(shù)。

這里面還涉及到很多技術(shù)細(xì)節(jié)，比如參數(shù)轉(zhuǎn)換、簽名驗(yàn)簽、加密解密、報(bào)文組裝解析，發(fā)送接收等。

在前面的兩篇文章中，我們介紹了渠道網(wǎng)關(guān)，兩者的區(qū)別在于：

渠道網(wǎng)關(guān)：是一個(gè)更大范圍的網(wǎng)關(guān)，還包括渠道路由、渠道開關(guān)、渠道咨詢等能力。

報(bào)文網(wǎng)關(guān)：是渠道網(wǎng)關(guān)的一部分，只負(fù)責(zé)對(duì)接渠道的接口，小團(tuán)隊(duì)可能只是一個(gè)小模塊，大團(tuán)隊(duì)可能會(huì)獨(dú)立出應(yīng)用。

3. 報(bào)文網(wǎng)關(guān)的幾種形態(tài)

一般來說，從簡單到復(fù)雜、從固定到靈活，報(bào)文網(wǎng)關(guān)會(huì)存在四種形態(tài)：

1. 純手?jǐn)]代碼：

• 在這種最初級(jí)的形態(tài)中，每個(gè)外部渠道都需要單獨(dú)的代碼實(shí)現(xiàn)。這意味著為每個(gè)新接入的銀行或支付服務(wù)，開發(fā)團(tuán)隊(duì)需要編寫一套新的接口邏輯。
• 優(yōu)點(diǎn)：針對(duì)性強(qiáng)，可以精確控制每個(gè)渠道的交互細(xì)節(jié)。
• 缺點(diǎn)：隨著接入渠道的增多，代碼變得越來越復(fù)雜，維護(hù)和擴(kuò)展的成本急劇上升。

2. 模板方法報(bào)文網(wǎng)關(guān)：

• 這種形態(tài)通過引入模板方法模式，將報(bào)文處理流程的共通部分抽象出來，為各個(gè)渠道提供統(tǒng)一的處理框架，同時(shí)留有接口供具體渠道實(shí)現(xiàn)其特定邏輯。
• 優(yōu)點(diǎn)：提高了代碼的重用性，降低了維護(hù)成本。
• 缺點(diǎn)：對(duì)于一些特殊需求，模板方法可能仍然不夠靈活，需要額外的定制。

3. 低代碼報(bào)文網(wǎng)關(guān)：

• 低代碼報(bào)文網(wǎng)關(guān)把所有核心的代碼邏輯實(shí)現(xiàn)后，只需要寫幾個(gè)配置文件，就可以完成渠道的接入。
• 優(yōu)點(diǎn)：極大地提高了靈活性和易用性，加快了新渠道的接入速度，核心代碼由有經(jīng)驗(yàn)的資深員工編寫，減少出錯(cuò)可能性。
• 缺點(diǎn)：復(fù)雜場(chǎng)景下可能需要寫一些內(nèi)聯(lián)函數(shù)，造成了一定復(fù)雜度。

4. 產(chǎn)品化配置報(bào)文網(wǎng)關(guān)：

• 在低代碼報(bào)文網(wǎng)關(guān)基礎(chǔ)上，提供圖形化配置界面，進(jìn)一步降低使用難度。
• 優(yōu)點(diǎn)：極大地提高了易用性，加快了新渠道的接入速度，以前寫代碼可能需要4、5天才接一個(gè)接口，變成可能0.5天就能接一個(gè)接口。
• 缺點(diǎn)：平臺(tái)的初始研發(fā)成本很高，如果總體接入的渠道不多，ROI可能不高。

每種形態(tài)都反映了各公司在特定時(shí)期的技術(shù)水平和方案造型，但總體來說，對(duì)于中大型公司來說，低代碼報(bào)文網(wǎng)關(guān)和產(chǎn)品化配置報(bào)文網(wǎng)關(guān)是一個(gè)比較不錯(cuò)的選擇。一方面可以提高效率，另一方面也有足夠的研發(fā)資源來建平臺(tái)。

4. 一種低代碼報(bào)文網(wǎng)關(guān)設(shè)計(jì)思路

首先我們要知道報(bào)文網(wǎng)關(guān)核心只做這么幾件事：

1. 接收內(nèi)部應(yīng)用的請(qǐng)求。
2. 內(nèi)部標(biāo)準(zhǔn)參數(shù)轉(zhuǎn)成外部渠道的參數(shù)。比如內(nèi)部叫mobileNo，渠道可能叫：mobile_id。
3. 特定字段加密（可選，由渠道定）。
4. 組裝需要簽名的明文字符串并簽名。
5. 組裝發(fā)送報(bào)文，比如有json，kv，xml等。
6. 對(duì)報(bào)文整體加密（可選，由渠道定）。
7. 發(fā)送請(qǐng)求，并接收請(qǐng)求。
8. 對(duì)報(bào)文整體解密（可選，由渠道定）。
9. 解析報(bào)文。
10. 組裝驗(yàn)簽明文字符串并驗(yàn)簽。
11. 特定字段解密（可選，由渠道定）。
12. 外部返回參數(shù)轉(zhuǎn)成內(nèi)部標(biāo)準(zhǔn)參數(shù)。
13. 返回給內(nèi)部應(yīng)用。

通過上面的流程分析，我們很容易想到流程引擎或責(zé)任鏈處理，再加一個(gè)上下文，就可以實(shí)現(xiàn)全部的操作。

具體包括：

1. 可視化配置：提供直觀的用戶界面，允許用戶通過圖形化方式配置報(bào)文的處理流程，無需編寫復(fù)雜的代碼。
2. 模塊化處理邏輯：將報(bào)文處理的各個(gè)步驟模塊化，如報(bào)文解析、加密/解密、數(shù)據(jù)映射等，用戶可以根據(jù)需要組合這些模塊來構(gòu)建完整的處理流程。
3. 靈活的適配能力：支持靈活地適配不同的支付渠道，包括但不限于銀行接口、電子錢包、第三方支付平臺(tái)等。
4. 動(dòng)態(tài)配置管理：所有配置信息動(dòng)態(tài)管理，支持實(shí)時(shí)更新，無需重啟系統(tǒng)或重新部署。

5. 低代碼報(bào)文網(wǎng)關(guān)的系統(tǒng)架構(gòu)

說明：

1. 最上層是API：核心服務(wù)和管理服務(wù)分離。
2. 核心上下文：主要是用于保存接口配置，原始請(qǐng)求，中間處理結(jié)果等。
3. 核心處理Handler：參數(shù)轉(zhuǎn)換、加密、解密等全部基礎(chǔ)功能全部組件化。
4. 流程引擎：負(fù)責(zé)串起所有的Handler依次運(yùn)行。
5. 內(nèi)聯(lián)函數(shù)：解決特殊場(chǎng)景下的報(bào)文轉(zhuǎn)換。
6. 配置中心：配置內(nèi)部接口，外部接口，參數(shù)映射等。
7. 流程管控：發(fā)布、回滾、權(quán)限管理等能力。

通過這種系統(tǒng)架構(gòu)，低代碼報(bào)文網(wǎng)關(guān)不僅能夠提供強(qiáng)大靈活的配置能力，還能確保處理流程的穩(wěn)定執(zhí)行，同時(shí)保持高度的可維護(hù)性。這樣的架構(gòu)使得報(bào)文網(wǎng)關(guān)能夠適應(yīng)不斷變化的業(yè)務(wù)需求，同時(shí)降低了總體的維護(hù)成本和技術(shù)復(fù)雜性。

6. 低代碼報(bào)文網(wǎng)關(guān)的核心代碼實(shí)現(xiàn)

代碼實(shí)現(xiàn)有很多種方式，且報(bào)文網(wǎng)關(guān)也是一個(gè)獨(dú)立的應(yīng)用，把所有的代碼展示出來也不太現(xiàn)實(shí)。這里給出上面系統(tǒng)架構(gòu)圖中的核心代碼示例。讀者可以擴(kuò)展實(shí)現(xiàn)細(xì)節(jié)，有興趣的同學(xué)也可以私信我。

整體思路如下：

1. 設(shè)計(jì)數(shù)據(jù)庫表結(jié)構(gòu)：用于存儲(chǔ)內(nèi)部接口定義，外部接口定義，接口映射關(guān)系，外部渠道參數(shù)等。這部分在這里略過。
2. 設(shè)計(jì)運(yùn)行上下文：GatewayContext（保存處理的上下文信息，包括接口配置、內(nèi)部請(qǐng)求參數(shù)、加解密臨時(shí)數(shù)據(jù)、加驗(yàn)簽臨時(shí)數(shù)據(jù)、發(fā)送渠道報(bào)文、渠道返回原始報(bào)文、解析后報(bào)文等）。
3. 設(shè)計(jì)各種處理Handler：內(nèi)部參數(shù)轉(zhuǎn)外部參數(shù)Handler，加密handler，簽名Handler，報(bào)文組裝Handler，發(fā)送Handler，報(bào)文解析Handler，驗(yàn)簽Handler，解密Handler，外部參數(shù)轉(zhuǎn)內(nèi)部參數(shù)Handler等。
4. 設(shè)計(jì)Handler工廠類：GatewayHandlerFactory（通過getHandlers()獲取處理的責(zé)任鏈）。
5. 設(shè)計(jì)內(nèi)聯(lián)函數(shù)：用于處理一些復(fù)雜操作。比如外部渠道返回的幣種和金額兩個(gè)字段轉(zhuǎn)成內(nèi)部的一個(gè)Money類。這部分在這里略過。

下面是核心代碼組件包括GatewayContext、GatewayHandlerFactory 和一系列的 GatewayHandler 基本實(shí)現(xiàn)：

GatewayContext 類用于保存處理過程中的上下文信息，包括臨時(shí)參數(shù)、報(bào)文信息等。

public class GatewayContext { // 接口配置信息 private interfaceInfo interfaceInfo; // 原始請(qǐng)求 private Map<String, Object> originalRequestParam; // 轉(zhuǎn)換后參數(shù) private String requestParam; // 簽名明文 private String signPlanContext; // 省略部分參數(shù)，以及getter和setter方法 ... ...}

GatewayHandlerFactory 是一個(gè)工廠類，用于構(gòu)建處理責(zé)任鏈。

public class GatewayHandlerFactory { private static final List<GatewayHandler> handlers = new ArrayList<>(); static { handlers.add(new ParameterTransformHandler()); handlers.add(new EncryptionHandler()); handlers.add(new SignatureHandler()); // 添加其他handler ... ... } public List<GatewayHandler> getHandlers() { // 添加其他handler return handlers; }}

GatewayHandler 接口定義了處理邏輯的執(zhí)行方法。

public interface GatewayHandler { void execute(GatewayContext context);}

具體的 Handler 實(shí)現(xiàn)：

內(nèi)部參數(shù)轉(zhuǎn)外部參數(shù)Handler

public class ParameterTransformHandler implements GatewayHandler { @Override public void execute(GatewayContext context) { // 實(shí)現(xiàn)內(nèi)部參數(shù)到外部參數(shù)的轉(zhuǎn)換邏輯 }}

簽名Handler

public class SignatureHandler implements GatewayHandler { @Override public void execute(GatewayContext context) { // 不需要簽名 if (!context.isNeedSign()) { return; } context.setSignMessage(sign(context.getSignPlainContext(), context.getInterfaceInfo().getSignConfig())); } // 簽名方法略}

其它Handler的實(shí)現(xiàn)略。

執(zhí)行Service

public class GatewayServiceImpl implements GatewayService { @Override public GatewayResponse execute(GatewayRequest request) { // 轉(zhuǎn)成網(wǎng)關(guān)的上下文 GatewayContext context = buildGatewayContext(request); // 獲取責(zé)任鏈，依次執(zhí)行 List<GatewayHandler> handlers = GatewayHandlerFactory.getHandlers(); for(GatewayHandler hander : handlers) { hander.execute(context); } // 轉(zhuǎn)換返回 return convertResponse(context.getResponseParam); } // 其它代碼略 ... ...}

這些組件和處理器共同構(gòu)成了低代碼報(bào)文網(wǎng)關(guān)的核心功能，允許系統(tǒng)靈活地配置和處理支付系統(tǒng)與外部渠道之間的報(bào)文交換。通過這種設(shè)計(jì)，報(bào)文網(wǎng)關(guān)可以輕松適應(yīng)不同支付渠道的接入和業(yè)務(wù)流程的變更，同時(shí)大大減少了傳統(tǒng)編碼方式所需的開發(fā)和維護(hù)工作。

7. 結(jié)束語

在本文中，我們深入探討了報(bào)文網(wǎng)關(guān)在支付系統(tǒng)中的重要性，從其在支付系統(tǒng)中的定位、不同形態(tài)的發(fā)展，到一種具體的低代碼設(shè)計(jì)思路，以及詳細(xì)的系統(tǒng)架構(gòu)。我們還看到了核心代碼的實(shí)現(xiàn)，展示了如何通過靈活的處理器和上下文管理，實(shí)現(xiàn)報(bào)文網(wǎng)關(guān)的關(guān)鍵功能。

產(chǎn)品化配置的低代碼報(bào)文網(wǎng)關(guān)通過提供直觀的配置界面和強(qiáng)大的后端處理能力，使得支付系統(tǒng)更加靈活，能夠快速適應(yīng)新的支付渠道和業(yè)務(wù)模型。同時(shí)，它也降低了技術(shù)門檻，使得初始技術(shù)人員能夠更容易地參與到支付渠道的對(duì)接中，而不用擔(dān)心技術(shù)太菜可能導(dǎo)致的各種各樣的問題。

這是《百圖解碼支付系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)》專欄系列文章中的第（23）篇。點(diǎn)擊上方關(guān)注，和墨哥一起深入解碼支付系統(tǒng)的方方面面。

前一篇：《圖解渠道網(wǎng)關(guān)（二）：模型、狀態(tài)機(jī)與流程編排》