本文主要介紹了新零售SaaS架構中的開放平臺架構設計，以及如何通過開放平臺增強產(chǎn)品能力、促進創(chuàng)新、構建生態(tài)系統(tǒng)和降低成本等方面的優(yōu)勢。

SaaS產(chǎn)品通常都會建設自己的開放平臺，滿足客戶更多差異化的需求，通過開放平臺構建一個以SaaS標準產(chǎn)品能力為中心的生態(tài)圈。

今天為大家介紹一下開放平臺的架構設計。

一、為什么需要搭建開放平臺

1. 增強產(chǎn)品能力

開放平臺能夠讓三方開發(fā)者和合作伙伴開發(fā)新的應用或服務，增加原有SaaS產(chǎn)品能力。這樣就可以滿足更多用戶需求，從而提高用戶的滿意度和黏性。

2. 促進創(chuàng)新

三方開發(fā)者能夠在SaaS標準產(chǎn)品的基礎上，創(chuàng)造新的解決方案，為平臺帶來創(chuàng)新的業(yè)務模式，這些可能為SaaS企業(yè)帶來更多的盈利機會。

3. 構建生態(tài)系統(tǒng)

開放平臺能夠建立一個以SaaS標準產(chǎn)品為中心的生態(tài)系統(tǒng)，吸引開發(fā)者、合作伙伴和其他相關方參加，共同構建一個互惠互利的生態(tài)圈。

4. 降低開發(fā)和運營成本

通過邀請三方開發(fā)者來創(chuàng)造和擴展產(chǎn)品能力，他們可以有效分擔SaaS企業(yè)的開發(fā)、運營成本，更聚焦于核心產(chǎn)品的優(yōu)化和創(chuàng)新。

二、開放平臺的服務對象是誰？

SaaS企業(yè)的開放平臺通常包括以下關鍵用戶角色：

1. 第三方開發(fā)者

他們期望能快速入駐開放平臺，并構建應用，通過用戶訂購應用獲取收益。因此，他們需要API文檔、SDK工具和開發(fā)者后臺，幫助開發(fā)者構建、測試和部署應用，并且利用平臺資源推廣自己的應用。

2. 定制客戶

定制客戶一般為擁有自研能力的企業(yè)客戶，有定制化功能需求，例如與內(nèi)部系統(tǒng)（如ERP、CRM）進行打通，實現(xiàn)企業(yè)自身的業(yè)務流程。

3. 平臺運營人員

平臺運營人員需要為三方開放者和企業(yè)客戶服務，幫助他們解決問題，因此，需要客戶管理，應用申請流程管理、服務配置、參數(shù)配置、角色分配、財務對賬管理等產(chǎn)品能力。

三、開放平臺的運營流程

SaaS開放平臺的運營流程涉及平臺的管理和維護，為企業(yè)客戶、三方開發(fā)者提供服務，包括吸引與管理三方開發(fā)者，提供必要的開發(fā)工具和支持，對開發(fā)者創(chuàng)建的應用進行審核和上線管理，通過數(shù)據(jù)監(jiān)控和分析評估平臺的健康度和用戶活躍度，確保提供有效的服務支持，和維護平臺的安全和合規(guī)性。

下圖展示了開放平臺的整體運營流程，實際的開放平臺項目可以基于該流程做變更。

四、開放平臺整體架構設計

1. 管理后臺

層針對不同角色，提供不同的管理后臺：

• 開發(fā)者后臺：為三方開發(fā)者提供的工作臺，包括應用管理、API接入、開發(fā)工具、數(shù)據(jù)分析和測試工具等。
• 平臺運營后臺：用于平臺運營團隊管理整個系統(tǒng)的工作臺，包括客戶管理、權限控制、計費管理、系統(tǒng)監(jiān)控等功能。
• 商家后臺：SaaS企業(yè)客戶的后臺系統(tǒng)，主要用于訂購應用市場的三方應用，授權應用，并使用其提供的服務能力。

2. 服務層

• 服務層為上層的管理后臺提供核心服務能力：
• 開發(fā)者接入：提供API文檔、SDK工具、開發(fā)指南，應用的注冊、管理等。
• 運營管理：包括平臺用戶信息管理、權限設置、用戶資料管理。對開發(fā)者提交的應用進行審核，確保應用的質(zhì)量和安全性。管理平臺計費、結(jié)算，收集和分析平臺的運營數(shù)據(jù)。
• 監(jiān)控中心：包括服務器、應用、網(wǎng)絡、數(shù)據(jù)庫、安全、中間件和存儲監(jiān)控。這些功能確保開放平臺的穩(wěn)定性、性能和安全，通過實時監(jiān)控、告警支持技術團隊進行有效管理和維護。

3. API網(wǎng)關

API網(wǎng)關是整個開放平臺的流量入口，它提供的能力確保了平臺操作的安全、穩(wěn)定和高效管理。

4. 業(yè)務開放能力

業(yè)務開放能力由各個業(yè)務域系統(tǒng)提供，這些開放能力提供了核心業(yè)務數(shù)據(jù)/功能的交互能力。

五、開放能力設計

開放能力可以分為以下幾種類型：

• 前端擴展：開發(fā)者可創(chuàng)建個性化的前端H5/小程序頁面，滿足企業(yè)客戶不同場景不同行業(yè)的需求。
• API 接口/消息推送：API接口允許開發(fā)者通過定義的接口與平臺系統(tǒng)交互，實現(xiàn)數(shù)據(jù)和功能的集成，例如商品創(chuàng)建接口。消息推送是指平臺系統(tǒng)主動通知三方系統(tǒng)，如訂單狀態(tài)變更通知。
• 后端擴展：開發(fā)者可以通過擴展點，自由嵌入自定義流程節(jié)點，構建個性化的業(yè)務邏輯。
• 數(shù)據(jù)模型擴展：允許將三方系統(tǒng)的數(shù)據(jù)模型整合到平臺系統(tǒng)中，在平臺系統(tǒng)中可以查看或處理三方數(shù)據(jù)。

以商品系統(tǒng)為例，列出不同類型開放能力的使用場景：

• 前端擴展：頁面串聯(lián)、定制商詳組件、定制商品詳情、定制B端管理頁面。
• API 接口/消息推送：商品發(fā)布接口、同步分店接口、查詢商品詳情接口、商品價格修改接口、商品修改接口、商品屬性接口、商品上下架接口、商品類目接口、商品創(chuàng)建消息、商品變更消息。
• 后端擴展：商品校驗類擴展點（例如，商品創(chuàng)建時，校驗商品編碼是否符合定制需求的規(guī)范）、商品的定制信息計算擴展點（例如，通過外部接口計算出商品重量信息）。
• 數(shù)據(jù)模型擴展：商品模型擴展并存儲個性化的字段信息。

六、開放API設計原則

1. RESTful風格API

RESTful API 是一種遵循 REST 原則的 API 設計方式。REST 是一組約束條件和原則，由 Roy Fielding 在 2000 年的博士論文中提出。

RESTful API 的設計依賴于網(wǎng)絡協(xié)議，主要是 HTTP，并且它使用 HTTP 的原生功能（比如 HTTP 的動詞和狀態(tài)碼）來執(zhí)行操作。以下是 RESTful API 的一些主要特點：

• 面向資源：在REST架構中，所有內(nèi)容都被視為”資源”，每個”資源”都有一個獨特的URI（統(tǒng)一資源標識符）。
• 無狀態(tài)：RESTful API不保存狀態(tài)，這意味著每個請求都應包含執(zhí)行請求所需的信息。服務器不會保存客戶端的任何信息。
• 統(tǒng)一接口：RESTful API應該有一個統(tǒng)一的接口，客戶端和服務器基于接口交互，實現(xiàn)解耦。交互通常通過HTTP動詞實現(xiàn)，如GET（獲取資源）、POST（創(chuàng)建資源）、PUT（更新資源）、DELETE（刪除資源）。

RESTful API的三個顯著優(yōu)勢如下：

• 它建立在HTTP協(xié)議上，協(xié)議簡潔易用，得到了廣泛的應用。
• 接口設計以資源為中心，讓接口易于理解和使用，比較直觀。
• 數(shù)據(jù)交換采用XML或JSON格式，大大簡化了數(shù)據(jù)的處理和傳輸過程。

但嚴格遵循 RESTful API風格，也有一些缺陷：

（1）HTTP協(xié)議的動詞受限

當業(yè)務需求變得復雜時，僅依賴于HTTP的動詞方法來對資源操作，可能不足以滿足需求，這時往往需要通過接口名稱來進一步區(qū)分。此外，一些特定的HTTP請求，如PUT和DELETE，可能會在網(wǎng)絡傳輸過程中被某些防火墻設備攔截。

（2） URL包含參數(shù)，可讀性差

在URL中嵌入?yún)?shù)占位符（例如：GET /Api/Orders/{id}/OrderItems/{id}）會降低其可讀性。如果需要基于URL統(tǒng)計接口的調(diào)用次數(shù)，需要對具有相同URL的不同參數(shù)進行額外的處理。

（3）HTTP狀態(tài)碼的表達性差

使用如20X、30X、4XX、5XX等標準的HTTP狀態(tài)碼，不足以描述復雜的業(yè)務場景的狀態(tài)。

建議接口設計遵循以下準則：

• 限制HTTP方法的使用，僅采用GET和POST。
• 避免在URL中包含參數(shù)占位符，盡量使用URL的參數(shù)傳參。
• 使用自定義的業(yè)務狀態(tài)碼來提供更豐富的響應信息。

2. API分組原則

根據(jù)業(yè)務領域，對開放API進行分組。例如店鋪API、商品API、庫存API、訂單API、物流API、客戶API、營銷API。

SaaS標準產(chǎn)品一般都基于DDD進行架構設計，根據(jù)業(yè)務領域組織開放API，是普遍采用的最佳實踐。當需要改進或變更某個特定業(yè)務領域的功能時，開發(fā)人員可以直接找到相關的API組進行修改，不會影響到其他領域的API。

對于三方開發(fā)人員，可以更容易地找到與某個業(yè)務功能相關的API，因為它們通過業(yè)務域的劃分邏輯組織在一起。

3. 版本管理

為了統(tǒng)一和清晰地標識不同版本的相同接口，建議將版本號放置在接口路徑的末尾，示例如下：

• 老版本：http://api.xxxx.com/item/create_item
• 新版本：http://api.xxxx.com/item/create_item/v2返回數(shù)據(jù)

每個接口的響應數(shù)據(jù)，應遵循統(tǒng)一的JSON或XML格式規(guī)范，并且至少應包含以下關鍵字段：

• 狀態(tài)碼 (code)：表示請求的總體結(jié)果，通常用于標識操作的成功或異常狀態(tài)。
• 消息 (msg)：提供關于狀態(tài)碼的詳細描述，以幫助理解請求的具體結(jié)果。
• 數(shù)據(jù) (data)：包含與請求相關的具體業(yè)務信息和數(shù)據(jù)。

六、安全措施

1. 接口簽名

為開發(fā)者分配AccessKey（開發(fā)者標識，確保唯一）和SecretKey（用于接口加密，確保不易被窮舉，生成算法不易被猜測）。

按照請求參數(shù)名的字母升序排列非空請求參數(shù)（包含AccessKey），使用URL鍵值對的格式（即key1=value1&key2=value2…）拼接成字符串A。

在字符串A最后拼接上Secretkey得到字符串B。

對字符串B進行MD5運算，得到Sign值。請求時，攜帶參數(shù)AccessKey和Sign，只有擁有合法的身份AccessKey和正確的簽名Sign才能放行。這樣就解決了身份驗證和參數(shù)篡改問題，即使請求參數(shù)被劫持，由于獲取不到SecretKey（僅作本地加密使用，不參與網(wǎng)絡傳輸），也無法偽造合法的請求。

2. 數(shù)據(jù)加密

敏感數(shù)據(jù)，如用戶信息，應使用加密算法進行保護，常用的加密方法包括RSA和AES。

3. 訪問控制

在接口訪問的API網(wǎng)關，應設置訪問控制，僅允許來自被商家授權的白名單的請求。商家可以通過商家后臺系統(tǒng)自主管理其白名單。

七、消息推送

消息推送是平臺主動通知三方系統(tǒng)，提供數(shù)據(jù)更新的一種機制，滿足三方系統(tǒng)對信息實時性的需求。例如，當商家成功創(chuàng)建訂單后，三方系統(tǒng)可以通過訂單查詢接口來獲取訂單的當前狀態(tài)。

三方系統(tǒng)若想實時獲取訂單狀態(tài)，可以選擇定時查詢接口，但這樣效率低并消耗大量資源。通過系統(tǒng)主動推送訂單狀態(tài)信息，可以有效地解決這一問題。但消息推送也帶來了一些挑戰(zhàn)：

• 順序性問題：訂單可能經(jīng)歷多個狀態(tài)，且這些狀態(tài)在業(yè)務上有特定順序。網(wǎng)絡延遲可能導致狀態(tài)送達三方系統(tǒng)時，順序錯亂，這時三方系統(tǒng)需要通過校驗訂單狀態(tài)，判斷變更是否符合業(yè)務邏輯，來確保訂單狀態(tài)的準確性。
• 消息丟失風險：目前系統(tǒng)通常采用消息隊列異步發(fā)送消息推送，盡管有消息中間件的機制確保消息的可靠性，但三方系統(tǒng)出現(xiàn)網(wǎng)絡問題，仍有可能導致推送失敗。解決方案：三方系統(tǒng)可以定期全量查詢訂單狀態(tài)，對雙邊的訂單狀態(tài)進行對賬處理，確保數(shù)據(jù)的完整性。