Categories
程式開發

SaaS架構設計的參考指南


SaaS架構設計的參考指南 1

為什麼需要SaaS?

軟件即服務(SaaS)是一種靈活的軟件分發模型,可以由少到一個人或多至上千人的組織來運作。雲服務的問世讓任何人都可以獨立運行自己的SaaS,並在此基礎上建立免費增值模式的業務。

與其他類型的軟件服務相比,它的系統設計相對簡單。但是,由於沒有合適的基準架構,如果我們在設計SaaS時沒有認真思考,其結果可能會變得一團糟。我見過的一些例子中,SaaS平台最終成為一個龐大卻脆弱的單體Web應用程序,其中遍布冗雜的功能。

本文的目的是為你提供一種參考架構,為SaaS實現可伸縮性和可維護性。

SaaS平台的需求

產品需求

  • 用戶和用戶組的訪問控制。
  • 向用戶和組織提供訂閱層,其中每種訂閱類型都可以訪問一組產品。
  • 託管內部管理工具的能力。
  • 可擴展的功能。我們應該能輕鬆添加新的產品和功能集。

設計目標

  • 隔離的服務帶來清晰的責任歸屬與關注點分離。
  • 減小任何更改的影響半徑,比如說分析儀表板中的錯誤不應該影響管理儀表板。
  • 隔離運行Web應用程序。每個Web應用程序都提供一組相關的功能來服務我們的客戶。在大型公司中,每個Web應用程序都可以有自己的專門團隊來構建和運行。

解決方案:隔離和重用

將服務隔離到邏輯組件中的設計可以讓我們的SaaS有更好的可擴展性。我們應該針對我們的架構作出改進,在規模擴展時打破常規:規模越大,架構卻變得越容易管理。就算只有一位孤獨的車間開發人員,他也可以很容易運行並管理多個服務,尤其是現在我們已經擁有了各種各樣可以編排微服務的雲服務,這種事情做起來就更簡單了。

因為計劃在SaaS平台上運行這些功能Web應用(feature Web app),所以我們應該先思考“我們可以重用什麼?”這個問題。

隔離

隔離的Web應用程序是將相關功能分組在一起形成的一個Web應用程序,或是代表一款產品的一組Web應用程序。具體而言,我將其稱為“產品Web應用”,後文將做更進一步的介紹。

在Web應用程序中分組相關功能

例如,所有”分析報告功能”都可以組合在一起,成為一個獨立的Web應用程序,該應用將由一個專門的團隊來構建和維護,且這個團隊在構建分析報告產品方面具有相關的領域知識。在大型公司中,每個產品Web應用都有自己專門的團隊來構建和運行。

內部與公共(可選)

你的產品Web應用也可以分為兩個部分:內部和公共部分。內部和公共部分之間明確區分開來後,你就能在自己的專用網絡內路由一組專用的安全管理工具。

在內部和公共區域代理這些服務的工作由”路由服務”處理,具體將在後面的章節中介紹。

重用

這些是不同的功能Web應用及其相應服務共享的通用功能。每種功能Web應用都需要利用下面列出的這些功能。

SaaS架構設計的參考指南 2

組件

下面這些是構成我們SaaS的邏輯組件。

路由服務

每個請求都需要路由到正確頁面。當用戶訪問yourWebsite.com/your-path時,/your-path需要將用戶轉發到其關聯的請求頁面或功能Web應用。路由服務可確保用戶得到他們所請求的內容。

SaaS架構設計的參考指南 3

在本文的例子中,我們將需要路由服務(routing service)調用另一個服務以獲取路徑和Web應用程序URL映射,以及所需權限。

這些映射預計將在運行時更新。例如,在需要引入新頁面或更改用戶權限而無需發布的情況下更新。

路由服務還負責內部或公共的產品Web應用。可以將其部署到兩個單獨的運行實例中。

SaaS架構設計的參考指南 4

公共和私有路由服務設置的高級設計

實現技巧:Node.js的http-proxy-middleware或Nginx的Reverseproxy是兩個可行的選擇。如果你不需要在運行時從其他服務中以編程方式檢索路徑、URL和權限,則後者是理想的選擇。有關更多信息,請參見後文的”Web應用倉庫”章節。

產品Web應用

每個產品Web應用都通過一個可在內部訪問的URL公開,例如https://my-product-app-1.mydomain.local。其中一些由路由服務路由,以供訂閱的用戶訪問,而另一些仍在內部訪問。

SaaS架構設計的參考指南 5

通過路由服務路由的產品Web應用

在後台,這可以是單個或一組帶有Web前端的微服務。這些Web應用彼此獨立,有自己獨立的代碼庫、支持服務、部署管道,並且理想情況下是由不同的團隊所有。在SaaS平台中,它們的分組方式與其所有團隊的結構保持一致。

這樣以來我們就能將大型Web項目分解為許多可管理的單元。可以將這種模式想像成是將大塊牛排切成許多小塊。一個產品Web應用包含一組不應與其他Web應用重疊的相關功能。

實現技巧:產品Web應用可以是任何Web應用程序,例如常見的Express、Node.js和React堆棧。將設計系統與可複用的微前端(例如Mosaic或Open Components)搭配使用,可以讓你的產品擁有一致的外觀和體驗。

Web應用存儲庫

這個服務負責保存多個團隊擁有的Web應用程序的記錄。路由服務調用Web應用存儲庫,以獲取與所請求路徑對應的Web應用URL(匹配某個條目)。

SaaS架構設計的參考指南 6

路由服務檢索Web應用URL及其關聯的路徑。

下面是一個Web應用存儲庫表示例,用來說明它的功能。

SaaS架構設計的參考指南 7

基於角色的訪問控制(RBAC)服務將提供權限信息,以幫助我們檢查登錄用戶是否有權訪問產品Web應用。

如果要維護的產品Web應用條目數量很少,這裡就可以用一個簡單的路由和硬編碼哈希映射的代理。

實現技巧:這既可以是具有自己的Web管理UI的RESTful服務,也可以是簡單的基礎架構,比如說是位於路由服務中,或者來自對象存儲(如AWSS3)的代碼配置文件。具體的實現方式將取決於所需的規模和可配置性。如果你要繼續考慮服務實現,則可以將Java、Go或C#與RDBMS或NoSQL數據存儲搭配使用。

對於這個服務來說,驗證過程是非常重要的,如果路徑或Web應用URL的配置不正確,則可能會影響你服務的可用性。如果無法確定要支持的產品數量,請使用進化原型方法。你不必在開發週期的早期就構建這個服務,因為一開始只用一個簡單的配置文件就夠了。

身份驗證

應該有一個跨服務共享的專用身份驗證服務。這裡JSON Web令牌就可以派上用場,因為我們能輕鬆地通過標頭跨多個服務傳遞令牌和其他有用的用戶信息。

可以從路由服務或產品Web應用中調用身份驗證服務。如果從產品Web應用調用身份驗證服務,就能讓產品Web應用所有者靈活地對他們想要保護的任何頁面實施身份驗證。這種靈活性讓服務所有者可以管理公共頁面,例如用戶註冊頁。這種方法還減少了在路由服務中執行的邏輯。

SaaS架構設計的參考指南 8

產品Web應用調用身份驗證。

或者也可以在路由服務中處理身份驗證過程。從安全角度來看,這使身份驗證處理更容易審核,因為我們無需查看每一個產品Web應用頁面。這也意味著,如果需要讓一個網頁開啟公開訪問權限,則應該採用某種形式的白名單。這是另一個可配置性折衷。

SaaS架構設計的參考指南 9

路由服務調用身份驗證。

實現技巧:AWSCognito、Auth0或任意JSON Web令牌(JWT)身份驗證服務。

基於角色的訪問控制(RBAC)

驗證用戶身份後,我們需要能夠回答以下問題:

是否允許登錄用戶訪問此頁面或他們嘗試訪問的信息?

可能的答案有:

  • 是的,用戶Alice屬於組織A,該組織有權訪問內容A。
  • 否,用戶Bob屬於組織B,該組織無權訪問內容B。

是否允許登錄用戶執行此動作?

可能的答案有:

  • 是的,用戶Alice具有管理員角色,該角色具有刪除已註冊用戶的權限。
  • 否,用戶Bob只有成員角色,該角色對所有內容只有隻讀權限。

RBAC幫助我們回答上述問題,從而讓我們的Web應用可以允許或撤消用戶執行的特定動作。

SaaS架構設計的參考指南 10

產品Web應用從RBAC服務中檢索權限信息。

下圖顯示了對用戶進行身份驗證並使用RBAC檢查其權限時發生的事件流。

SaaS架構設計的參考指南 11

下面的偽代碼說明瞭如何在特定用例中使用RBAC服務。

檢查用戶是否具有查看頁面的權限。

if (userHasPermissionToViewPage(userId)) {
showPage();
} else {
showNoPermissionError();
}

檢查用戶是否有權執行某個動作。

if (userHasPermissionToPerformAction(userId)) {
showButton();
} else {
doNothing();
}

實現提示:與其他服務相比,這個服務的通信量預計會更高,具體取決於你的權限會有多少粒度。你可以考慮使用和Web應用存儲庫實現類似的選擇:Java、Go或C#,搭配RDBMS數據存儲和一個緩存系統。用戶權限管理需要一個Web管理UI。

高階設計

下圖顯示了運行時中組件之間的交互方式。

SaaS架構設計的參考指南 12

這種解決方案的好處包括:明確所有權、重用通用功能以及關注點分離。

高階序列

下圖顯示了路由服務將用戶路由到請求頁面的序列。從Web應用存儲庫中檢索到產品Web應用詳細信息之後,便會發生這些序列。

選項1

在產品Web應用中調用身份驗證。

SaaS架構設計的參考指南 13

在產品Web應用中調用身份驗證。

選項2

在路由服務中調用身份驗證。

SaaS架構設計的參考指南 14

在路由服務中調用身份驗證。

使用Web應用存儲庫、RBAC和身份驗證頁面作為一個Web應用

Web應用存儲庫、RBAC和身份驗證服務需要它們自己的Web UI來管理數據或接收用戶輸入。 Web應用存儲庫、RBAC和身份驗證服務均有它們自己的Web應用。使用另一個具有管理UI的Web應用可以管理對某個Web應用的訪問權限。

SaaS架構設計的參考指南 15

某些Web應用用作其他組件的UI。

Web應用存儲庫UI允許我們使用所需的權限來管理路徑和Web應用URL。

RBAC UI用於管理用戶、組織、角色和權限。

身份驗證服務的前端UI(即登錄頁面)也被部署為Web應用。

技術說明

  • 服務通過HTTPS調用進行通信。
  • 服務是內部的,但某些Web應用由路由服務公開提供。
  • 這裡沒有詳細介紹冗餘的信息。你可以簡單地在構成SaaS平台的服務之前添加一個負載均衡器,並在多個區域中運行它們。

長期改進

下面總結了一些應該牢記的準則,可以幫助你成功運營SaaS平台。

1.將技術文檔視為產品一部分

關鍵在於要讓團隊能通過良好的文檔管理產品Web應用,同時充分利用可用的工具。好的文檔可以最大程度地減少你的團隊重複詢問SaaS平台相關問題的需求。

2.給工程師同事提供便利

你可以在用於RBAC和Web應用存儲庫的Web UI管理工具之上,再開發一個NodeJS/React模板,其中包括開箱即用的RBAC和身份驗證的客戶端,以盡量減少將Web應用添加到SaaS平台所需的工作。

這樣你的工程師或你自己就可以方便地從這個模板創建新的Web應用,而無需花費很多精力將其集成到平台中。

3.工程設計審查

糟糕的代碼可能會浪費數天甚至數週的開發時間,但相比之下,糟糕的架構決策可能會浪費數月至數年的時間。對於大型公司而言,工程設計審查可能更容易推進;但如果你自己是一名開發人員,那麼也可以從社區中認識的其他工程師那裡獲得反饋。

花費合理的時間預先編寫工程設計文檔,並在工程設計審查期間獲得反饋,可以為你節省很多時間。應該驗證軟件設計假設,並讓其他工程師為你設計的軟件架構找出盡可能多的漏洞。

英文原文:

Architecting a Scalable Software as a Service