電子商務平臺API 開放系統設計與實現

麥克爾斯（深圳）科技服務有限公司 索紅升

近年來，電子商務行業不斷發展，行業競爭更為激烈，同時也有著十分龐大的數據信息和流量。所以相關企業也更加希望通過開放式的系統促進和合作方之間的互利共贏，從而促使相關電商企業正在著手建立專業化的電商平臺開放式的API 系統，為外界進行多種多樣的服務，從而獲取豐富的流量和用戶。本文結合電子商務平臺API 開放系統的設計方向、系統架構、用戶授權、請求鑒權、頻率控制以及訂購關系這幾項主要功能，設計實現了優質的電子商務平臺API 開放系統，希望能夠借此推動互聯網電子商務開放系統良性發展，推動現代化電商企業成長。

1 電子商務平臺API 開放系統設計

1.1 系統設計目標

電商API 開放系統與其他開放平臺相比，具有明顯的電商特性，電商系統當中的商品類型、數量眾多，用戶包括各種品牌商、賣家、商家、消費者等，用戶數量龐大，請求訪問異常頻繁，另外電商具有復雜的購物流程邏輯，一個訂單往往會包括多種不同狀態，需要考慮許多問題。總體來看，電商十分復雜，應當在對外開放的同時，在第三方開發者上屏蔽這些復雜的邏輯與流程，因此標準化與通用化是必然的發展方向，外界開發者只需要了解API 接口與相關的參數作用，調用接口能夠獲取所需信息即可，不再需要掌握電商內部較為復雜的流程與邏輯。電商API 開放系統還屬于聯系內外的橋梁，發揮著類似于中間件的作用，但這卻是一個較為完整的開放系統。內部應當聚合電商業務，外部應當為開發者屏蔽一些業務細節，同時還能夠借助于開放系統，促進電商后臺的穩定服務，由于API 服務是否穩定取決于電商后臺是否穩定，因此在確保后臺十分穩定、可靠的前提下，還需要不斷優化后臺服務可靠并且較為穩定的基礎上，應當要求后臺進一步優化服務，提升運行效果。外部優勢利用API 訪問基礎服務，此時可能出現超時的情況，這樣的問題絕大部分情況下是由基礎服務引發的，這時就應當在API 側推動系統內部改進，從而提高服務整體質量水平。還應當提供內部較為便利的在線文檔管理系統，從而奠定系統進一步優化和開發的基礎，對業務接口優化與更新過程中的數據信息進行詳細記錄[1]。

1.2 系統框架

系統設計的整體目標明確之后，可以針對如圖1 所示的系統構架圖對本文設計實現的開放式API 系統架構全方位的了解，途中展示的主要就是系統基礎功能與接口調用流程，與應用的接入以及文檔在線測試和開發一類功能沒有任何關系，可以讓人們更好地了解系統內部流程。在圖1 中，右側的調用人員主要為復雜開發的第三方App，用戶們如果訂購應用，系統就會直接發送請求，通常需要利用Nhinx 轉發至系統當中的服務器內部，由于用戶數量較多，因此請求頻率會較大，通過轉發能夠提高系統內部服務器的負載均衡度。利用單一的業務邏輯，在處理之后可以直接進行鑒權與頻率監測，同時針對相關用戶的請求發出是否正常進行檢查，鑒權與頻率限制檢查主要就是在緩存當中的數據信息進行讀取，運用緩存主要就是為了進一步提升檢查效率與鑒權性能，定期更新緩存內容，如果出現崩潰，則能夠直接對其中數據進行讀取，完成鑒權與頻率控制。通過鑒權與頻率，能夠借助于API 接口調取后臺業務接口，獲取相關信息，而后再將其反饋到調用方。

圖1 系統框架圖Fig.1 System framework

本開放系統采用開源技術框架的技術容易學習，并且優勢眾多，開發人員能夠在短期內完成開發，其開源技術也有著較為廣泛的應用，能夠被業內從業人員所接受，外部開發人員也更加熟悉系統架構，更方便系統的開發與應用，滿足標準化與通用化的發展目標[2]。

1.3 系統功能設計

1.3.1 用戶授權訂購關系

用戶授權訂購關系在電商平臺API 開放系統當中屬于一個基礎，系統后續的相關功能都是服務于這種關系的，該功能的設計能否實現，直接影響系統整體。用戶授權訂購過程的應用，包括用戶、鑒權、登錄校驗以及授權入口等。電商開放系統當中的用戶主要包括買賣雙方，第三方開發者所開發的各種應用通常直接掛到電商平臺當中，比如在用戶完成系統登錄之后，就會在管理界面中出現一個專屬于第三方的特定工具模塊，其主要用來對第三方軟件進行展示。移動設備當中大多會設置應用商店，用戶們在商店內可以從列表當中挑選App，在某個用戶完成對某個App 的訂購之后，則應用會針對用戶登錄情況進行直接檢查，如果確認沒有登錄，則需要用戶登錄，用戶登錄之后，應用便會發送授權訂購這一請求，詢問用戶是否需要和應用之間建立一個訂購關系。這時就要求電商登錄這一模塊檢查用戶的登錄狀態，在開放系統當中實現。確定所有用戶的正常登錄狀態，在合法申請的基礎上，將用戶訂購關系記錄到數據庫當中，同時針對訂購成功界面進行實時反饋。在此期間，應當進行嚴格的安全防護，盡可能讓所有用戶都能夠更加便捷的訂購應用，完成登錄的用戶則在進行電極訂購并確定之后，便能夠快速訂購該應用。

1.3.2 請求鑒權

在鑒權環節內，用戶首次授權應用會建立訂購關系，同時也會獲取到訪問權限，最開始的流程類似于授權訂購流程，鑒權過程中會對用于訂購情況開展細致化檢查，如果發現訂購完成，則直接檢查訪問權限期限，如果依舊在期限內，則能夠請求該系統繼續保持運行；如果發現已過期，則可以為用戶直接自動續費，一些續期依舊為原理訪問Token，但是部分處于安全性可能重新出現多種訪問權限。用戶們一旦屬于首次對應用進行授權，則鑒權應當針對該接口的具體訪問權限進行直接調取。在獲取訪問權限的有效期之后，便會將其直接記錄在數據庫內，同時用戶們自動返回到訪問權限。而后用戶如果需要調用接口，則可以利用訪問權限獲取臨時權限，利用臨時權限生成具體的請求，對Sign 值進行計算，借助于鑒權校驗獲取信息。鑒權訪問接入之后，還應當通過攔截器或過濾器完成檢查，這種功能通常是借助于Structs2 實現，兩者都能夠通過文件的配置從而達到預期工作目的，過濾器則需要依賴于Serlet 容器，攔截器則需要利用Java 落實具體的反射機制。

1.3.3 訪問頻率控制

當系統接收訪問請求后，首先請求會被攔截器攔截，并將其直接輸送至檢查服務內，首先將用戶換粗期間的頻率上限數值提取出來，這部分上限數值指的就是用戶們在上次訪問過程中的次數。得到這個上限值之后，需要進行實時的更新，本質上來說屬于上次和本次的兩個次數和，同時對緩存當中的用戶限制進行更新。該數據能夠直接落實到數據庫當中，也能夠存儲在緩存當中，因為其是一種中間數據，所以在達到期限后就能夠直接歸零而后重新計算，在緩存期間也有可能出現丟失的問題，只需要進行重新計算，將其他所有開銷全部落實就可以，因此能夠直接保留至緩存當中。更新緩存的數據之后，將數值返回，而后用現階段的上限數值以及用戶訪問頻率都有著可以對比的受限數據，同時更新對接口部位進行請求的訪問次數。用戶大部分都存在同樣的受限數據，所有的業務接口也擁有總訪問受限制。

2 電子商務平臺API 開放系統實現

2.1 用戶授權訂購功能的實現

用戶結束應用訂購后，一般存在兩種差異化情況，首先是用戶屬于完成過登錄狀態，此時該應用將請求平臺檢查用戶以往的登錄狀態，并在得到確認之后，才需要用戶進行確認授權，此時還需要結合權限請求用戶們的臨時權限，在獲取之后，才可以繼續調用業務接口，并從中得到用戶信息；其次是用戶屬于未登錄過的狀態，這是就應當返回登錄開始界面，等待用戶完成授權與登錄，繼續后續的工作環節。這個過程就是利用UserAuth得以實現，該類當中應用的主要包括應用ID、應用名稱、API 接口一類具體的參數信息，用戶們在對所訂購應用進行授權止嘔，主要的操作都是基于Web 網頁得以實現，而其中的請求則屬于一種十分普遍的協議請求。在授權期間，具體流程是通過UserAuth 類內部的Auth方法得以實現的。

2.2 請求鑒權功能的實現

請求鑒權主要有3 種，本文分析的就是用戶授權當中的內部鑒權這種功能。請求鑒權這個工作屬于利用攔截器得以實現的，在接入請求后，首先會受到攔截器直接攔截，完成檢查工作，在檢查結束后繼續完成后續操作。鑒權工作就是用作對操作的操作人員進行驗證，其中涉及到的需要檢查的主要包括UID、AppID、Skey 以及權限一類參數信息，還有業務接口內請求參數，這些都可以利用計算Sign 數值進行檢查。Sign 值計算過程中最為關鍵的一個步驟就是對參數進行拼接，獲取原本的計算字符串，比如用戶們在調用接口完成發布信息的工作期間，商品參數就能夠直接簡化，變成itemCode。

2.3 訪問頻率控制功能的實現

訪問頻率控制主要就是借助于攔截器完成的，實現的主要類有Limit Interceptor，實際判斷邏輯主要借助于API UID Frequence 得以實現。針對訪問頻率進行控制就是要統計用戶們在5min 內的具體訪問次數，明確是否存在超額問題。首先會獲取緩存內部數據信息，針對用戶們在規定時間內是否會出現5min 訪問的情況進行判斷，如果超過，則應當重新對訪問次數與時間進行計算。如果在有效期內，則應當判斷這一階段內的訪問次數與規定頻率之間是否相符，一旦超出則應當針對用戶們的特殊權限與特殊規則進行繼續判斷，特殊用戶則能夠繼續進行訪問，但也可以直接上報，如果用戶不是特殊類型的用戶，則應當對其訪問進行限制。如果緩存當中沒有數據，則需要新增技術與計時，并將其更新在緩存當中。

2.4 系統實現流程

2.4.1 系統管理員用例

開放系統內部操作最頻繁的一個人員就屬于管理人員，通常分為應用管理、訪問頻率管理與業務接口管理三方面。其中應用管理包括以下內容：（1）查詢檢索應用。所有應用都應當在系統當中注冊，集中展示到系統當中，更便于管理員隨時檢查和具體應用；（2）查看詳細的應用信息。管理人員可以隨時獲取應用所有信息和功能，比如其中的開發者數據信息、訪問Token 以及應用權限等；（3）審核應用與測試。所有應用在系統推向用戶之前，都應當通過開發自測與系統檢測，確保其沒有任何不良導向之后才能夠推向所有用戶；（4）卸載應用。應用廢氣或合作完成之后，管理人員可以將應用直接卸載。

業務接口管理主要包括以下用例：（1）新增接口鑒權信息。開放系統當中的業務接口主要可以劃分為三大類，即訪問公共信息類、訪問用戶信息類以及設計用戶隱私與商業信息類；（2）接口修改鑒權信息。管理人員可以隨時針對業務接口內部鑒權信息進行查看，同時也可以隨時修改；（3）查詢接口列表。業務接口都可以結合電商流程在不同的模塊內完成分類，比如常見的訂單接口與商品杰闊等，而管理人員則可以針對不同模塊內的接口列表進行查詢；（4）查詢接口內部信息。業務接口內部信息較為豐富，管理員能夠隨時查看所有接口當中的所有信息。

2.4.2 第三方開發者用例

負責開發的第三方主要用例可分為以下幾點：（1）服務商的注冊。第三方的所有開發者既能夠是個人、企業，也可以是團隊，在開發者們開發調用接口過程中，首先需要在系統內部將自己注冊變成服務商，也就是以合作者的身份進行開發。通常可以進行個人與企業兩種不同的服務商注冊；（2）申請應用開通權限。開發者可以在完成注冊后，便第一時間申請開通，完成開通后則可以獲取ID、訪問權限以及數字簽名，而后便能夠開發應用；（3）查看應用。第三方開發者通常可以開發多種應用，特別是類似于企業與團隊開發人員，他們能夠隨時對應用列表與信息進行查看，比如開通應用期間必備的3 個主要參數；（4）應用信息的完整編輯。針對自行開發的應用，開發人員還能夠編輯系統內部基礎信息，明確具體的開發進度、應用功能以及開發設置等；（5）管理應用。在結束應用開發后，就應當推出用戶應用，需要利用管理人員審核才能夠正式推出應用，所以要求開發人員需要進行直接的審核申請，其中包括測試申請審核的應用，還有上下架以及升級等具體內容。

3 結語

綜上所述，在當前的大數據背景下，電子商務平臺API 開放系統的科學設計與實現，能夠有效推動網絡大數據技術的合理應用，使其更好地服務于電商行業，促進電商行業的現代化、先進化、高效化發展。