後端介面對接的模式範本: 概念澄清： 【下單】是個廣義上的叫法，並不僅限於支付訂單的訂單。因為整個過程都圍繞一個【seqNo】訂單號或流水號這個唯一標識展開，因而統稱【下單】。 【下單】可以是為派發一個優惠券、申請一個支付訂單、申請一個發票等等。 【seqNo】也可以叫orderNo，有唯一性，每次 ...
後端介面對接的模式範本:
概念澄清：
【下單】是個廣義上的叫法，並不僅限於支付訂單的訂單。因為整個過程都圍繞一個【seqNo】訂單號或流水號這個唯一標識展開，因而統稱【下單】。
【下單】可以是為派發一個優惠券、申請一個支付訂單、申請一個發票等等。
【seqNo】也可以叫orderNo，有唯一性，每次請求都不一樣，唯一標識一筆業務。
後端介面需要考慮的點：
- 通信層安全驗證(可以通過nginx層做https的證書驗證工作)
- 單向https.
即客戶端驗證服務端證書。例如：瀏覽器驗證網站證書。
我們需要做的就是服務端的證書一定是要第三方授信CA簽的證書。
這樣瀏覽器拿到證書可以在本地找到該授信的第三方ca證書來驗證網站證書的真偽。
如果網站的證書自己簽名的證書，客戶端需要在瀏覽器中配置該證書自簽名使用的的CA證書。
https單向相比於雙向實現方便，也是最基礎的保障。不可能http直接在公網上跑，那樣業務報文都是明文暴露狀態，非常不安全。
- 雙向https
一般後端交互https雙向，基本都是使用自簽名的證書。
客戶端需要配置服務端的ca證書，用於解開服務端給我們的其自身的證書。
服務端同時也需要配置客戶端的ca證書，用於解開客戶端給服務端的其自身的證書。
如果是代碼實現發送雙向https請求,你會發現有兩個證書配置,一個是請求方自身的證書，一個是服務端的ca證書。
https雙向優點就是更加安全，通過證書能互相確認彼此身份。在後端交互中常見。單向https在瀏覽器/服務端中常見。
- 介面層校驗:
介面或者header中有類似於sign的欄位，用於驗證簽名。
簽名的作用就兩個:防篡改；防抵賴
sign = sha256WithRSA(報文,私鑰)等方法的模式為【私鑰簽名、公鑰驗簽】的方式，可以防篡改，防抵賴.但是實現相對較重，需要生成和管理公私鑰。
使用appkey/secretKey模式,使用類似於sign=MD5(報文,secretkey)只能防篡改,因為這個secretKey是雙方都知道的.但是實現方式較輕量，也很普遍。
- 數據安全保護
通信層https只能保證數據在網路或者公網中是密文傳輸的。
但是一旦數據過了nginx這關，即解除https證書驗證之後，報文數據在內網中就是明文在傳輸。對應敏感數據不能明文顯示。
複雜安全點的模式可以使用數字信封模式：
即提供兩個欄位：
partnerData:敏感數據的加密值，使用對稱加密的，例如：AES演算法。
dekey：隨機對稱密鑰的加密值，使用非對稱加密的，例如：RSA演算法
partnerData=AES(敏感數據,隨機對稱密鑰)
dekey=RSA(隨機對稱密鑰,接收方的公鑰)
解密的過程就是加密的逆過程，先用自己的私鑰解出對稱密鑰，再使用對稱密鑰解開敏感數據。
因為基於公私鑰，所以只有私鑰持有者才能解開這個數字信封。安全性非常好。
- 業務授權校驗:
通信層可以進來，驗簽能通過。但是業務授權也要鑒別，例如：同樣可以調用派發優惠券介面，但是商戶A只能發商戶A商品的優惠券。
介面或者header中有類似於appkey/appCode/authCode等類似功能欄位，該欄位和驗簽綁定。通過該欄位查詢配置，確認該請求是否有該業務的許可權。
- 防重發攻擊:
https單向中多見，https雙向中少見。主要預防攻擊不要流到業務層。
1.防止錯誤的報文重覆攻擊，一般錯誤報文驗簽直接可以過濾。
2.防止正確的報文重覆攻擊
一般在介面或者header中有timestamp/nonce/messageId等欄位,這些欄位每次請求都會不一致。
如果報文被截獲,重放攻擊,可能由於timestamp時間和伺服器時間相差很遠，或者相關nonce欄位已經被緩存過，無法通過。
同時可以結合冪等措施，即被處理過的業務不會重覆執行。
- 實現冪等:
介面中有seqNo欄位,可以叫訂單號/流水號。
一個seqNo就對應了一次業務下單，同樣的流水號無論請求多少次，結果都是一樣的，不會重覆做。
防止請求在通信中丟失，請求方無法判斷該業務的實際狀態，是【還未送達】或【處理完了，回程時丟失】
實現冪等後，請求方可以使用相同seqNo進行下單，服務端如果處理過該seqNo訂單，就將之前的處理結果返回，如果沒處理就收單繼續處理。
- 提供查詢
為什麼提供了冪等還要提供查詢？
查詢和冪等的作用區別就在於，很多時候請求方請求出現異常，沒有明確的答案，如果希望業務繼續，則可以冪等請求。
例如該用戶派發優惠券，如果發生異常則繼續冪等派發即可。
如果需要根據實際業務狀態決定如何操作，則需要先查詢。
例如:很多有時效的業務，搶購業務，用戶下單異常，最終沒搶到貨。
肯定是先查詢，如果剛纔訂單實際成功，則給用戶退款。如果剛纔訂單未成功,則直接關閉業務，這單子不用繼續做下去了。
- 非同步通知:
下單介面如果是同步介面，肯定沒有實現非同步通知的必要。
很多下單介面是非同步介面，真正的業務狀態在同步中無法返回，同步僅僅返回已收單。
非同步通知的作用：能增強業務的時效性，同時也能減少請求方輪詢導致的壓力。
如果收到明確通知，請求方當即可以觸發下一步操作，如果沒有通知或通知丟失，請求方只能掛單等待異常處理時主動查詢確認狀態。
- 是否需要對賬
一般後端對接的業務介面，基本都需要對賬。
對賬最大的問題是【跨天】，例如：請求方請求時間為凌晨：23:59:59.但是接收方收到的時間為次日：00:00:04
假如按照T+1對賬，那在T日臨界點，總可能出現對不平的情況。請求方有該筆賬，但是接收方沒有。
我們不討論【勾對】等其他實現方式。
如果可能，在定義介面的時候，可以討論清楚對賬方式及以哪方時間為準。避免後續對賬開發困難。
例如：在下單介面中添加objectData欄位，以請求方的該欄位作為對賬時間依據。
- 考慮升級
對接的任何一方都有在業務進行中要升級介面的可能。但是要避免需要停服、及互相依賴的局面，例如：大家約定一個時間，半夜你先升級，我在升級。
場景1：公私鑰泄露需要更換。
可以在介面中添加keyIndex來標識密鑰的版本或者signType欄位來標識簽名的演算法。
這樣請求方報文中使用什麼版本的密鑰，接收方就使用什麼版本的密鑰解密。互相不依賴。提前配置好即可。
場景2：介面欄位升級
下單介面有新增欄位，選擇升級介面版本號，形成一個新介面。老介面仍保留。接收方先升級，請求方擇機升級，互不影響。
查詢同理。
- 考慮異常
網路異常、網路波動、今天我災備、明天他機房維護等。這些單個事件都是小概率，但是這樣的事件非常多。
網路異常也導致很多業務異常，我們要充分考慮的異常導致的掛單和中斷的情況，做好異常處理和自愈功能。
例如：對賬往ftp上投送對賬文件。可能網路異常，今天的文件沒放上去；或者今天的放上去了，但是出問題需要重新放；可能災備停了兩天，在進行對賬等等
ps:不要忽略這些小概率事件，沒有預案，只要發生一次，造成的異常業務筆數可能手動處理很久。
- 介面效率
考慮這個介面的負載是很關鍵的步驟。同步介面壓力大點，非同步介面可以使用MQ進行削峰填谷相對壓力小點。
提升效率，控制併發是一個非常龐大的體系。常見的方式：
1.共用數值欄位，我們只做累加
2.每個用戶獨立有一條記錄，將併發化解。
4.用插入代替更新，分段鎖庫存等，使用<=0代替=0，防止極限情況擊穿等。
5.分庫分表，避免熱點表和數據的阻塞。
6.註意風控,報警等情況。
...............
- 示例：
{
"authCode": "123", 業務認證碼
"appCode": "123", 請求方
"deKey":"frfferdfa" 對稱密鑰加密值
"partnerData": "22", 敏感數據加密值
"seqNo": "123",請求流水
"timestamp": "202107201653123", 時戳
"keyIndex": "1", 加密密鑰版本
"sign": "123" 簽名
}
本文來自博客園，作者：wanglifeng，轉載請註明原文鏈接：https://www.cnblogs.com/wanglifeng717/p/16213202.html
