SaaS架構：開放平臺架構設計

架构师汤师爷發表於2024-10-12
架構

大家好，我是湯師爺~

今天聊聊開放平臺架構設計。

為什麼需要搭建開放平臺

增強產品能力

開放平臺能夠讓三方開發者和合作夥伴開發新的應用或服務，增加原有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閘道器，應設定訪問控制，僅允許來自被商家授權的白名單的請求。商家可以透過商家後臺系統自主管理其白名單。

訊息推送

訊息推送是平臺主動通知三方系統，提供資料更新的一種機制，滿足三方系統對資訊實時性的需求。例如，當商家成功建立訂單後，三方系統可以透過訂單查詢介面來獲取訂單的當前狀態。

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

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

本文已收錄於，我的技術網站：tangshiye.cn 裡面有，演算法Leetcode詳解，面試八股文、BAT面試真題、簡歷模版、架構設計，等經驗分享。

相關文章