1.項目背景

車支付系統(tǒng)對接很多的外部渠道，如蘋果支付、支付寶、微信、銀聯(lián)等，在實際開發(fā)與實施的過程中，發(fā)現(xiàn)了其中存在的一些問題，比如：

創(chuàng)新互聯(lián)10年專注成都高端網(wǎng)站建設按需網(wǎng)站策劃服務,為客戶提供專業(yè)的成都網(wǎng)站制作,成都網(wǎng)頁設計,成都網(wǎng)站設計服務;創(chuàng)新互聯(lián)服務內(nèi)容包含成都網(wǎng)站建設,微信小程序開發(fā),軟件開發(fā),網(wǎng)絡營銷推廣,網(wǎng)絡運營服務及企業(yè)形象設計;創(chuàng)新互聯(lián)擁有眾多專業(yè)的高端網(wǎng)站制作開發(fā)團隊,資深的高端網(wǎng)頁設計團隊及經(jīng)驗豐富的架構師高端網(wǎng)站策劃團隊;我們始終堅持從客戶的角度出發(fā),為客戶量身訂造網(wǎng)絡營銷方案，解決網(wǎng)絡營銷疑問。

• 需要一定精力在與渠道進行非業(yè)務邏輯的聯(lián)調(diào)與測試。
• 渠道的對接可能分布在不同的業(yè)務子系統(tǒng)中，沒有進行統(tǒng)一有效的出口管控。

針對以上類似問題，外聯(lián)網(wǎng)關應運而生，以保證內(nèi)部系統(tǒng)與外部系統(tǒng)之間進行安全、有效、便捷的通訊。

2.設計方案

2.1系統(tǒng)交互流程圖

簡單來說，系統(tǒng)的主要功能就是通過對請求的一些配置，選擇系統(tǒng)預置的一些插件（系統(tǒng)內(nèi)置了常用的通訊協(xié)議、加簽驗簽、加密解密過程，也可以通過規(guī)則引擎腳本實現(xiàn)對請求和響應數(shù)據(jù)的個性化處理），以實現(xiàn)在不編寫代碼的情況下，實現(xiàn)對請求的鑒權、參數(shù)預處理、參數(shù)與響應結(jié)果映射等。讓業(yè)務開發(fā)同學更關注業(yè)務邏輯。

平臺還提供Mock數(shù)據(jù)的能力，在外部接口未提供可調(diào)用環(huán)境時，可以根據(jù)渠道提供的文檔，進行Mock數(shù)據(jù)的返回。

系統(tǒng)提供兩種接入方式：

• 客戶端如果采用spring cloud，可以接入統(tǒng)一注冊中心Consul；
• 如果是其他系統(tǒng)，可以通過HTTP方式調(diào)用。

3.實踐過程

在獲取到對接方的接口文檔之后，通過分析接口的通訊與鑒權方式，在外聯(lián)網(wǎng)關的配置管理后臺配置相應的參數(shù)，配置完成之后會有相應的模板編號，客戶端通過模板編號+對接接口的請求參數(shù)進行接口的請求。

3.1組管理

系統(tǒng)通過組管理，對同一系列的接口的通用配置，實現(xiàn)對一個外部渠道中一個或多個接口的的請求響應處理配置，包括：

• 加簽驗簽
• 加密解密
• 預設字段

系統(tǒng)預置加密及簽名：

• 加密分為三種：

對稱加密（symmetric），例如：AES、DES等

非對稱加密（asymmetric），例如：RSA、DSA等

摘要加密（digest），例如：MD5、SHA-1、SHA-256、HMAC等。

• 摘要算法：

算法	說明
MD5-LOWER	摘要函數(shù)-128位-小寫
MD5-UPPER	摘要函數(shù)-128位-大寫
SHA-1	摘要函數(shù)-160位
SHA-256	摘要函數(shù)-256位
SHA-384	摘要函數(shù)-384位
SHA-512	摘要函數(shù)-512位
SHA1withRSA	先用 SHA-1 去摘要，然后使用 RSA 加密
SHA256withRSA	摘要后加密
SHA384withRSA	摘要后加密
SHA512withRSA	摘要后加密
MD2withRSA	摘要后加密
MD5withRSA	摘要后加密

• 加解密算法：

算法	說明	備注
AES	對稱加密。更快，兼容設備，安全級別高	AES|128|AQIDBAUGBwgJAAECAwQFBg==|AES/CBC/PKCS5Padding
DES	對稱加密。本地數(shù)據(jù)，安全級別低
RSA	非對稱加密。有公鑰和私鑰
SM4	國密算法-對稱加密SM4	encrypt_key、decrypt_key配置通過“|”間隔key和iv

注意：

AES|秘鑰長度|IV向量（byte-->Base64）|AES/mode （加密模式）/padding （填充方式）

AES|128|AQIDBAUGBwgJAAECAwQFBg==|AES/CBC/PKCS5Padding

• 簽名策略（SignStrategyEnum）

簡寫	過程
KV_JOIN_BODY_URL	對請求參數(shù)中body和urlParam值，根據(jù)配置的連接方式組成字符串
V_JOIN_BODY	請求參數(shù)（body）值拼接
V_JOIN_BODY_SORT	請求參數(shù)（body）值拼接（需排序）
KV_JOIN_BODY_HEADER	對請求參數(shù)中body和header值，根據(jù)配置的連接方式組成字符串
KV_JOIN_BODY_ENCRYPT	對請求參數(shù)中body和encrypt（加密前）值，根據(jù)配置的連接方式組成字符串
KV_JOIN_BODY_ENCRYPTED	對請求參數(shù)中body和encrypt（加密后）值，根據(jù)配置的連接方式組成字符串
BODY_JSON	對請求參數(shù)中body數(shù)據(jù)轉(zhuǎn)換為JSON字符串
BODY_ENCRYPT_SORT_JSON	body+encrypt 參數(shù)字段排序后 json 化
BODY_JSON_RSA	對請求參數(shù)中body數(shù)據(jù)轉(zhuǎn)換為JSON字符串在經(jīng)過RSA加密（Base64編碼）
ENCRYPT_RSA	對請求中的加密字符串進行再簽名
V_JOIN_HEADER_NO_SORT	header 內(nèi)容拼接，無排序
KV_JOIN_BODY_URL_REJECT_SIGNMETHOD	對請求參數(shù)中body和urlParam值，根據(jù)配置的連接方式組成字符串,并且剔除SingMethod的key和value

• 驗簽策略（VerifySignStrategyEnum）

簡寫	過程
V_JOIN_BODY	請求參數(shù)（body）值拼接
BODY_SORT_JSON	返回結(jié)果集字段排序后 JSON 化
BODY_SORT_JSON_E_WALLET	返回結(jié)果集字段排序后 JSON 化(E錢包專用)

• 簽名鹽值位置：

標識	說明
left	拼接左側(cè)
right	拼接在右側(cè)
both	兩側(cè)都有

• 加密策略（EncryptStrategyEnum）

簡寫	過程
SPECIFIC_JSON	在請求體??encrypt??中指定要加密的內(nèi)容，轉(zhuǎn)換成JSON字符串
BODY_JSON	在請求體??body??中指定要加密的內(nèi)容，轉(zhuǎn)換成JSON字符串

• 解密策略：

簡寫	過程
SPECIFIC_JSON	指定的字段，解密后為JSON字符串

• 接口預設參數(shù)：

{
 "body": {
  "requestNo": "$simple_uuid$",
  "requestTime": "$millisecond_long$",
  "charset": "UTF-8",
  "signType": "SHA256withRSA",
  "encryptType": "AES"
 }
}

示例：$simple_uuid$

預設值	類型	說明
simple_uuid	String	UUID
millisecond_long	Long	毫秒
timestamp_long	Long	時間戳
持續(xù)完善中

3.2請求項配置

在配置好接口組之后，接下來就可以通過對請求項實現(xiàn)對某一個接口的具體配置，其中包括：

• 選擇對應的接口組
• 是否需要Mock數(shù)據(jù)
• Mock數(shù)據(jù)的模板配置（每個屬性由 3 部分構成：屬性名、生成規(guī)則、屬性值，可以實現(xiàn)返回動態(tài)Mock數(shù)據(jù)。）
• 請求的方式（POST、GET）
• 請求與響應的Content-type，編碼格式等
• 請求超時的配置
• 請求參數(shù)映射（參數(shù)名稱的轉(zhuǎn)換）
• 請求參數(shù)腳本（通過規(guī)則引擎腳本對請求參數(shù)進行二次處理）

Mock模板示例：

'name|min-max': value
'name|count': value
'name|min-max.dmin-dmax': value
'name|min-max.dcount': value
'name|count.dmin-dmax': value
'name|count.dcount': value
'name|+step':

3.3模板配置

模板是打包一個或者多個請求（目前僅支持一個，后續(xù)通過接入規(guī)則引擎平臺，實現(xiàn)對請求項的編排能力），對外暴露給客戶端，通過模板編號進行請求。

 4.規(guī)劃 

外聯(lián)平臺目前實現(xiàn)了基本的對請求的處理與封裝，還是有很多需要集成與完善的功能，比如對請求的監(jiān)控與性能統(tǒng)計，直觀感受外部接口的響應效率，更好的優(yōu)化自己的系統(tǒng)。

還有可以接入規(guī)則引擎系統(tǒng)，可以實現(xiàn)對請求更靈活的配置，讓系統(tǒng)更加靈活，適應更多的場景。

 5.總結(jié) 

外聯(lián)網(wǎng)關是針對請求外部接口的一套實現(xiàn)方案，以低代碼的形式實現(xiàn)復用，以減少接口對接工作量為目標，最終實現(xiàn)提高工作效率，實現(xiàn)對接口的統(tǒng)一管理與控制，確保交易在各支付渠道之間安全、無縫的傳遞。

• 作為之家內(nèi)部業(yè)務系統(tǒng)與外部系統(tǒng)的隔離與統(tǒng)一管理：
• 實現(xiàn)外部支付清算系統(tǒng)的統(tǒng)一接入和接入管理；
• 完成通訊協(xié)議及信息的轉(zhuǎn)換；
• 完成報文組包解包、報文解密和加密；
• 完成信息的路由分發(fā)；
• 完成報文的發(fā)送和接收。

作者簡介：鄭剛 

• C端及中臺產(chǎn)研中心-效能平臺部-業(yè)務平臺團隊。
• 2017年加入汽車之家，主要負責中臺及金融相關業(yè)務服務器端設計與開發(fā)工作。

當前名稱：外聯(lián)網(wǎng)關平臺實踐之車支付渠道改造
新聞來源：http://uogjgqi.cn/article/dpphgcg.html