- 支付平臺架構:業務、規劃、設計與實現
- 曹兵強
- 2063字
- 2020-10-30 15:36:05
2.3 SDK架構概述
在講解SDK的具體實現之前,這里先講解融合收銀臺SDK架構的設計特點和架構框圖,便于讀者理解在SDK內部有哪些功能模塊,以及上下結構如何分層。
2.3.1 SDK架構的設計特點
在收銀臺SDK架構的設計上,除了要考慮軟件架構設計的通用性(高可用性和高穩定性),還要考慮互聯網金融業務的特殊性,比如高兼容性、高安全性、高擴展性等。
1.高兼容性
以Android移動應用研發為例,Android系統版本眾多(業內也叫作碎片化嚴重),還有很多是各手機硬件廠商自己定制和修改的系統固件版本(例如華為的EMUI和小米的MIUI固件),并且市場上這些版本的存量運行幅度很廣,這樣一來,Android系統版本的碎片化情況越來越嚴重。所以,我們在做收銀臺SDK架構設計時應該充分考慮移動終端系統運行的實際環境和兼容性。
在兼容性方面應該充分考慮硬件設備的兼容性和軟件的兼容性。
(1)硬件設備的兼容性。因為不同的手機硬件設備生產廠商會生產不同尺寸和不同電子設備元器件的手機,所以在設計SDK時要兼容不同類型的設備(例如:平板設備為橫屏,一般用HD版本來命名)。Google Play(谷歌應用商店)對Android應用上架的要求很高,對硬件設備兼容性檢測的要求也很高,必須通過Google的兼容性測試(Compatibility Test Suite,CTS)才可以上架。所以在設計SDK時應充分考慮硬件設備的兼容性,例如不同傳感器及硬件加速功能的兼容性等,以滿足在不同設備上使用的需求和用戶體驗。
(2)軟件的兼容性。在Android版本碎片化的情況下,軟件開發人員應考慮對不同API的調用能否成功,確保應用在不同的系統版本上均能正常運行。例如:為了使SDK在所有系統版本上都顯示并正常使用,SDK應該容忍一些系統功能API的變化,并提供適應不同屏幕尺寸的靈活用戶界面。
2.高安全性
由于收銀臺SDK處于支付的最前端,負責資金流和信息流的輸入/輸出和商戶的發貨流程,所以為了保障資金流和信息流的安全和商戶的利益,需要確保收銀臺SDK的高度安全。與支付系統的其他子系統相比,收銀臺SDK的安全性變得非常重要。
在收銀臺 SDK 中封裝了一些復雜的邏輯實現及網絡請求,負責與支付后端 API 進行網絡數據通信,例如支付(預)下單請求及支付結果響應。由于網絡請求的通用性和廣泛性(一個SDK 會被多款應用或網絡接入,影響面會擴大),一旦出現了安全漏洞、數據包篡改、偽造并被黑客利用,則影響范圍之廣、危害之大是不言而喻的。
在安全性設計方面應該著重考慮鑒權、授權兩個方面,并且需要對數據安全加密。例如:不能使用明文傳輸業務數據,不能使用HTTP傳輸第三方數據,要使用安全、權威的數字證書及動態化密碼。
案例:在使用HTTP從支付后端服務器請求和接收響應數據時,攻擊者可以通過中間人攻擊、劫持HTTP數據包,偽造支付后端服務器下發正常的支付數據,引導商戶應用正常發貨,造成商戶的資金損失;攻擊者也可以通過DNS劫持來利用漏洞,在DNS劫持、攻擊的過程中,攻擊者可以修改服務器的DNS記錄,把訪問者重定向到攻擊者自己的支付服務器,形成虛假的支付數據。
根據上述例子,在設計架構的過程中應該考慮引入非對稱加解密方案來保障數據的安全性,同時引入HTTPS組件對抗中間人的攻擊,并引入HTTPDNS組件解決DNS的劫持問題。
3.高擴展性
高擴展性也是收銀臺SDK的一個重要特點,因為支付方式和渠道會經常變動,比如增加新渠道、上線、下線、關閉支付渠道,所以需要在設計收銀臺SDK之初就充分理解支付流程和業務,在充分理解后才能對支付渠道的模型和接口能力進行抽象,預留相應功能的擴展點;并在技術設計上借鑒 OSGI(Open Service Gateway Initiative,開放服務網關協議)和 OO(Object Oriented,面向對象)設計擴展點模式。
在設計收銀臺SDK時要用面向對象的思想來看待世界,將公用的系統需求(安全加密、數據存儲、日志記錄、權限驗證等)進行抽象和封裝,形成統一的、便于擴展的接口,以便在每個外部的業務對象中進行調用。使用面向對象思想構建出來的軟件既能使整體架構穩固,也能對公共功能進行封裝,提供各模塊的接口調用,這就好比適配層被封裝起來,將接口進行暴露,以應對各種業務和多變的接口需求。
做好高擴展性設計之后,在有新需求或需求變動時,收銀臺SDK軟件開發人員都能夠基于之前的版本進行快速開發、迭代和響應。
2.3.2 用戶端SDK架構
這里根據市面上部分支付公司的收銀臺用戶端產品,總結出通用的用戶端SDK架構,如圖2-1所示。

圖2-1
市面上的收銀臺SDK幾乎都采用了動態加載技術,其好處是具備了靈活性和動態性,在不需要某項功能時,可以不加載相關功能插件,進而減少整個應用的內存和CPU、網絡等資源消耗,還可以通過動態加載實現功能模塊的熱插拔和功能升級,即在不發布新用戶端版本(用戶端發布版本的周期一般較長)的情況下更新某些功能模塊。
如圖2-1所示的用戶端SDK架構主要分4層,如下所述。
● 第1層是接口層,包括商戶應用或游戲開發者接入支付SDK的接口和回調函數(支付訂單數據)。
● 第2層是業務組件層,為了實現業務的動態更新功能,所有業務都被定義為一個插件,包括收銀臺的核心業務支付插件和充值插件,其物理表現形式為Dex[1]文件,同時包含其他業務插件。
● 第3層是基礎組件層,主要支撐上層業務的日志、線程、下載、定時任務、WebView[2]、插件服務等基礎中間件和設施。
● 第4層是平臺適配層,目前主流的移動操作系統為Android和iOS。