為什么需要搭建開放平臺

增強產品能力

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

促進創新

三方開發者能夠在SaaS標準產品的基礎上，創造新的解決方案，為平臺帶來創新的業務模式，這些可能為SaaS企業帶來更多的盈利機會。

構建生態系統

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

降低開發和運營成本

通過邀請三方開發者來創造和擴展產品能力，他們可以有效分擔SaaS企業的開發、運營成本，更聚焦于核心產品的優化和創新。

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

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

第三方開發者

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

定制客戶

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

平臺運營人員

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

開放平臺的運營流程

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

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

開放平臺整體架構設計

管理后臺

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

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

服務層

服務層為上層的管理后臺提供核心服務能力：

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

API網關

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

業務開放能力

業務開放能力由各個業務域系統提供，這些開放能力提供了核心業務數據/功能的交互能力。

開放能力設計

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

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

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

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

開放API設計原則

RESTful風格API

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

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

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

RESTful API的三個顯著優勢如下：

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

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

HTTP協議的動詞受限

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

URL包含參數，可讀性差

在URL中嵌入參數占位符（例如：GET /Api/Orders/{id}/OrderItems/{id}）會降低其可讀性。如果需要基于URL統計接口的調用次數，需要對具有相同URL的不同參數進行額外的處理。

HTTP狀態碼的表達性差

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

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

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

API分組原則

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

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

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

版本管理

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

• 老版本：http://api.xxxx.com/item/create_item
• 新版本：http://api.xxxx.com/item/create_item/v2

返回數據

每個接口的響應數據，應遵循統一的JSON或XML格式規范，并且至少應包含以下關鍵字段：

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

{
	"code":200,
	"msg":"OK",
	"data":{
	"item_id":"123456",
	"product_name":"奶油蛋糕"
	}
}

安全措施

接口簽名

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

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

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

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

數據加密

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

訪問控制

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

消息推送

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

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

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