多租戶 SaaS 架構完整指南：從概念到技術實現

Facebook LinkedIn Tweet

更新日期： 2025 年 3 月 20 日

本文為 SaaS 架構基礎，第 4 篇：

隨著企業數位轉型的加速，越來越多企業選擇 SaaS（Software as a Service，軟體即服務） 作為 IT 解決方案。

與傳統軟體不同，SaaS 服務通常是雲端架構，企業只需透過網頁或 API 連接，即可使用軟體功能，不需要自行部署伺服器或安裝軟體。

然而，當 SaaS 平台需要服務多家企業（租戶，Tenant）時，系統架構就變得更加複雜。

這時候，多租戶（Multi-Tenant）架構成為了 SaaS 開發的重要模式，能夠讓不同企業共用同一套後端系統，但仍能保持數據隔離與 UI 客製化。

本篇文章將詳細介紹多租戶 SaaS 架構的概念、優勢、技術實現方式，並解析如何透過 API 來控制不同企業的 UI 設定，讓初學者能夠理解並應用這種架構設計。

什麼是多租戶（Multi-Tenant）架構？

多租戶（Multi-Tenant） 指的是同一個 SaaS 平台可以同時服務多家企業（租戶），並且讓這些租戶共用相同的後端系統，但仍然能夠確保數據隔離、UI 風格客製化，以及不同的功能權限。

舉例說明

假設有一個「雲端人資管理系統」，公司 A 和公司 B 都使用這個 SaaS 服務。

在多租戶架構下：

✅ 公司 A 的 HR 員工登入後，看到的是 A 公司的 Logo、員工名單、考勤紀錄，但無法存取公司 B 的資料。
✅ 公司 B 的 HR 員工登入後，看到的是 B 公司的專屬 UI 風格、數據與功能，但同樣無法存取 A 公司的資訊。
✅ 這兩家公司使用相同的系統（同一個 SaaS 服務），但各自擁有獨立的資料與設定。

傳統軟體模式 VS SaaS 模式

比較項目	傳統軟體模式（On-Premise）	SaaS 模式（Multi-Tenant SaaS）
安裝方式	需要企業自行安裝、部署	企業透過雲端登入使用
維護成本	企業自行維護，需 IT 團隊	由 SaaS 提供商維護，企業無需管理伺服器
升級更新	需要企業手動升級	由 SaaS 提供商統一升級
數據管理	每個企業的系統獨立，無法共享	多個企業共用系統，但數據隔離
成本	企業需一次性支付軟體購買費	企業按月/年支付訂閱費

在 SaaS 模式下，多租戶架構讓企業能夠快速擴展，並降低 IT 維護成本，這也是 SaaS 服務能夠迅速普及的關鍵之一。

flowchart TB
    subgraph "傳統軟體模式"
        A1([客戶 A]) --> B1([客戶 A 專屬服務<br>獨立部署])
        A2([客戶 B]) --> B2([客戶 B 專屬服務<br>獨立部署])
        A3([客戶 C]) --> B3([客戶 C 專屬服務<br>獨立部署])
        
        B1 --> C1[(客戶 A 專屬<br>資料庫)]
        B2 --> C2[(客戶 B 專屬<br>資料庫)]
        B3 --> C3[(客戶 C 專屬<br>資料庫)]
    end
    
    subgraph "SaaS 多租戶模式"
        D1([客戶 A]) --> E([統一 SaaS 服務<br>單一部署])
        D2([客戶 B]) --> E
        D3([客戶 C]) --> E
        
        E --> F1[(多租戶資料庫<br>共享架構)]
        
        subgraph "邏輯隔離"
            F1 --> G1[租戶 A 資料]
            F1 --> G2[租戶 B 資料]
            F1 --> G3[租戶 C 資料]
        end
    end

多租戶 SaaS 架構：資料隔離方式詳解

在 多租戶架構（Multi-Tenant Architecture） 中，最關鍵的問題之一是 「如何確保不同企業（租戶）的數據彼此隔離？」。

因為所有租戶都共用同一套 SaaS 服務，如果數據隔離不當，可能會導致跨企業資料存取的風險，造成資訊洩漏或安全漏洞。

為了解決這個問題，開發團隊通常會選擇適當的資料庫設計模式，確保租戶之間的數據隔離程度符合業務需求。

以下是三種常見的資料隔離方式，從共享資料庫到完全獨立資料庫，各有其優勢與適用場景。

共享資料庫，共享 Schema（Shared Database, Shared Schema）

在這種模式下，所有租戶共用同一個資料庫，且所有表格也共享，但透過 tenant_id（租戶識別碼）來區分不同企業的數據。

📌 實作方式：

所有租戶的資料存放在相同的資料表中，例如：

employees
┌─────────────┬────────────┬───────────┐
│ tenant_id   │ name       │ position  │
├─────────────┼────────────┼───────────┤
│ A           │ Alice      │ Manager   │
│ A           │ Bob        │ Engineer  │
│ B           │ Charlie    │ HR        │
│ B           │ David      │ Sales     │
└─────────────┴────────────┴───────────┘

每次查詢時，系統會根據 tenant_id 來篩選數據，確保每個企業只能存取自己的資料。
例如，當 公司 A 的用戶登入，查詢 employees 表時，系統會執行：

SELECT * FROM employees WHERE tenant_id = 'A';

✅ 優勢：

開發與維護成本最低：所有租戶共用同一套 Schema，不需要為每個租戶建立新的資料表或資料庫。
擴展性佳：當新租戶加入時，只需要新增一個 tenant_id，不需要變更資料庫架構。

❌ 缺點：

數據隔離程度較低：如果 SQL 查詢沒有適當地加上 tenant_id 條件，可能導致跨租戶資料存取的風險。
報表與備份管理較複雜：需要額外的邏輯來區分不同租戶的數據，防止意外暴露他人資訊。

📌 適用場景：

小型 SaaS 平台，用戶數量較少，對數據隔離要求較低的系統。
企業用戶之間不涉及高度敏感數據，例如簡單的 CMS（內容管理系統）或內部工具。

共享資料庫，獨立 Schema（Shared Database, Isolated Schema）

這種模式下，所有租戶仍然共用同一個資料庫，但每個租戶擁有獨立的 Schema（資料表結構），確保不同租戶的數據不會混在一起。

📌 實作方式：

每個租戶擁有自己的資料表，但存放在同一個資料庫中，例如：

companyA.employees
┌───────┬────────────┬───────────┐
│ id    │ name       │ position  │
├───────┼────────────┼───────────┤
│ 1     │ Alice      │ Manager   │
│ 2     │ Bob        │ Engineer  │
└───────┴────────────┴───────────┘

companyB.employees
┌───────┬────────────┬───────────┐
│ id    │ name       │ position  │
├───────┼────────────┼───────────┤
│ 1     │ Charlie    │ HR        │
│ 2     │ David      │ Sales     │
└───────┴────────────┴───────────┘

查詢時，系統會根據租戶 ID 存取不同的 Schema。
例如，公司 A 登入後，系統會查詢 companyA.employees，而不是 companyB.employees。

✅ 優勢：

數據隔離性更高：租戶之間的數據存放在不同的 Schema 中，即使 SQL 錯誤執行，也不會影響其他租戶的數據。
可針對不同租戶進行個別優化：例如，公司 A 可能需要不同的索引策略，而公司 B 可能需要額外的欄位。

❌ 缺點：

管理較為複雜：當租戶數量增加時，需要動態管理 Schema，並確保所有租戶的表結構一致。
資料庫查詢與維護成本較高：由於不同租戶的數據分布在不同 Schema，跨租戶的查詢變得更加困難。

📌 適用場景：

中型 SaaS 企業，需要一定程度的數據隔離，但又希望共用相同的基礎架構。
例如 財務系統、企業級 CRM，不同租戶的數據較為敏感，需要更高的安全性。

獨立資料庫（Separate Database）

這種模式下，每個租戶擁有完全獨立的資料庫，確保最高的數據隔離性。

📌 實作方式：

每個租戶擁有獨立的資料庫，例如：

companyA_DB (獨立資料庫)
├── employees
├── payroll
├── attendance

companyB_DB (獨立資料庫)
├── employees
├── payroll
├── attendance

companyA_DB (獨立資料庫) ├── employees ├── payroll ├── attendance companyB_DB (獨立資料庫) ├── employees ├── payroll ├── attendance
當用戶登入時，系統會根據租戶 ID 連接對應的資料庫，例如：

if tenant_id == "A":
    db.connect("companyA_DB")
elif tenant_id == "B":
    db.connect("companyB_DB")

✅ 優勢：

提供最高的數據隔離安全性，完全避免跨租戶數據存取問題。
可針對不同租戶進行個別擴展與最佳化，例如某些大客戶可以擁有更強的伺服器資源。

❌ 缺點：

管理成本最高，每新增一個租戶，都需要建立新的資料庫，當租戶數量龐大時，維護與監控變得困難。
硬體資源使用較高，每個租戶都有自己的資料庫，可能會增加伺服器成本。

📌 適用場景：

大型企業級 SaaS 服務，例如銀行、醫療系統，需要最高等級的數據隔離性。
任何需要 合規性（如 GDPR、HIPAA） 的 SaaS 服務，確保不同企業的數據完全獨立。

多租戶架構的 UI 客製化

在 多租戶 SaaS 平台 中，除了後端的數據隔離，前端 UI（使用者介面） 也需要能夠根據不同企業的需求進行客製化。

不同企業可能有不同的品牌風格、功能需求，甚至不同的操作流程，因此 SaaS 服務需要具備「動態調整 UI」的能力，以確保每個企業的使用者都能獲得符合自身需求的體驗。

舉例來說，假設有一個 SaaS CRM（客戶關係管理）平台，該平台服務多家企業：

✅ 公司 A 想要藍色風格的 UI，並需要客戶報表功能。
✅ 公司 B 偏好綠色 UI，並希望有即時聊天支援的功能。
✅ 公司 C 需要更簡潔的 UI，並關閉部分進階功能以提升易用性。

為了實現這樣的需求，開發者通常會使用 API 來動態控制 UI 設定，確保系統能夠靈活應對不同租戶的需求，而不必為每個租戶開發獨立的前端應用程式。

透過 API 控制不同的前台設定

在多租戶 SaaS 平台中，前端 UI 需要依據租戶的設定來動態變更，而不是寫死在程式碼中。

這時候，開發者可以設計一個 「UI 設定 API」，在使用者登入時，根據「企業 ID」取得該租戶的 UI 設定，並動態載入 UI 風格與功能。

📌 實作方式：前端如何決定 UI 設定？

1️⃣ 用戶登入時，系統會確認該用戶所屬的企業 ID（tenant_id）。
2️⃣ 前端向 API 發送請求，查詢該企業的 UI 設定，例如：

GET /api/ui-config?tenant_id=companyA

3️⃣ API 回傳該租戶的 UI 設定，例如：

{
  "theme_color": "#0057B8",
  "logo": "https://cdn.companyA.com/logo.png",
  "features": {
    "chat_support": false,
    "custom_reports": true
  }
}

4️⃣ 前端應用程式根據這些設定，動態調整 UI，例如：

套用 theme_color 作為按鈕與背景顏色。
載入對應的公司 Logo。
判斷功能開關，例如是否顯示「客戶報表」或「即時聊天支援」功能。

具體案例：多租戶 SaaS 的 UI 客製化應用

🟢 案例 1：品牌風格與視覺設定

不同企業可能希望 SaaS 平台的視覺風格與其品牌形象保持一致。這包括：

主題顏色（Theme Color）：按鈕、背景、文字顏色的變更。
公司 Logo：登入頁、導航列中的企業標誌。
字型與按鈕風格：不同企業可能使用不同的品牌字型與 UI 元件樣式。

🔹 範例：不同租戶 UI 設定

企業	主題顏色	企業 Logo
公司 A	藍色 #0057B8	companyA_logo.png
公司 B	綠色 #008C3A	companyB_logo.png
公司 C	橙色 #F15A24	companyC_logo.png

當用戶登入時，系統會從 API 取得這些設定，並自動套用到前端 UI，使不同租戶擁有獨立的品牌風格。

🟢 案例 2：功能開關（Feature Toggles）

不同企業可能需要不同的功能，例如：

A 企業需要「即時聊天支援」，B 企業不需要。
C 企業希望啟用「進階報表功能」，而 A 企業不想要這項功能。

這時，開發者可以在 API 回應中提供 features 參數，讓前端 UI 依據租戶的設定來決定顯示哪些功能，例如：

{
  "features": {
    "chat_support": true,
    "custom_reports": false,
    "dark_mode": true
  }
}

前端應用程式可以根據這些值來顯示或隱藏對應的功能按鈕與選單，而不需要重新部署程式碼。

🟢 案例 3：動態導航選單

某些企業可能希望調整系統的導航選單，例如：

A 企業希望導航列顯示「客戶管理、銷售報告、訂單管理」。
B 企業則只想要「客戶管理、訂單管理」，不需要銷售報告。

API 可以提供一個 menu_items 陣列，讓前端決定要顯示哪些選單項目：

{
  "menu_items": ["customers", "orders"]
}

前端 UI 就可以根據這個設定，只顯示企業需要的選單選項，讓 SaaS 服務更加靈活。

為什麼透過 API 來控制 UI 設定？

使用 API 來控制 UI 的優勢包括：

✅ 靈活性高：開發者可以在 不修改前端程式碼 的情況下，透過 API 來調整租戶 UI 設定，不需要為每個客戶部署不同的版本。

✅ 維護成本低：只需要修改 API 回傳的設定，就能變更不同租戶的 UI，無需修改前端核心程式碼，提升開發效率。

✅ 快速擴展：當新企業加入 SaaS 平台時，只需在資料庫中新增一筆設定，無需更改程式碼或重新部署應用程式，讓 SaaS 服務能夠快速擴展至更多租戶。

多租戶 SaaS 的擴展性與安全性考量

在多租戶 SaaS 平台中，擴展性（Scalability）與安全性（Security）是兩個最重要的技術考量。

由於 SaaS 平台需要同時服務大量企業，每個企業的用戶數、數據量、存取需求都可能有所不同，因此系統必須具備高效的擴展能力，並確保不同租戶的數據安全無虞。

以下將詳細說明 如何提升 SaaS 的高可用性（High Availability）與安全性（Security），以確保系統穩定運作，並防止潛在的數據洩露風險。

高可用性（High Availability）

高可用性指的是 SaaS 平台能夠持續穩定運作，並且即使發生系統故障，仍能保持最低的停機時間。

由於多租戶架構下，SaaS 平台通常要同時為上百、上千家企業提供服務，因此如果系統崩潰或效能不足，會影響所有租戶的業務運行。

為了確保高可用性，SaaS 平台通常會採用以下技術：

1️⃣ 負載平衡（Load Balancing）

負載平衡是一種流量管理技術，用來確保系統能夠應對大量請求，避免某一台伺服器超載而導致系統崩潰。
當用戶請求進入 SaaS 平台時，負載平衡器（Load Balancer） 會將請求分配到不同的伺服器，以確保所有請求都能獲得及時回應。

🔹 典型的負載平衡架構：

用戶請求首先到達負載平衡器（如 Nginx、AWS Elastic Load Balancer、Google Cloud Load Balancing）。
負載平衡器將請求分配給後端伺服器集群（Application Servers）。
如果某台伺服器故障，負載平衡器會自動將流量重新導向其他可用伺服器，避免單點故障。

📌 範例：Nginx 負載平衡設定

upstream backend_servers {
    server server1.example.com;
    server server2.example.com;
    server server3.example.com;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

這樣的設定確保請求能夠被均勻分配到不同的伺服器，提高系統穩定性與效能。

2️⃣ 使用 CDN（內容傳遞網路）來加速前端 UI 加載速度

CDN（Content Delivery Network）是一種 分佈式網路技術，可以將 SaaS 平台的靜態資源（如 HTML、CSS、JavaScript、圖片）快取到全球各地的節點伺服器，讓用戶能夠更快載入網站內容。

🔹 為什麼需要 CDN？

減少伺服器負載：如果每個用戶都直接從 SaaS 伺服器下載資源，伺服器壓力會非常大，而 CDN 可以分散流量，減少主伺服器的負擔。
提升全球用戶的存取速度：CDN 會根據用戶的地理位置，選擇最近的伺服器來提供內容，降低延遲。例如，來自美國的用戶會從美國的 CDN 節點載入資源，而不是從遠端的歐洲伺服器下載。
提升可用性與容錯能力：如果 SaaS 伺服器發生故障，CDN 仍然可以提供快取的內容，減少影響。

📌 範例：使用 Cloudflare CDN 來加速 SaaS 平台

curl -I https://your-saas-platform.com
# 如果有啟用 CDN，回應頭（Response Headers）會顯示：
# CF-Cache-Status: HIT (表示 CDN 已快取內容)

常見的 CDN 服務提供商包括 Cloudflare、AWS CloudFront、Akamai、Google Cloud CDN 等。

安全性與權限控管（Security & Access Control）

由於多租戶 SaaS 平台必須同時管理多家企業的數據，因此確保數據安全與存取控制是至關重要的。

以下是幾種關鍵的安全技術：

1️⃣ RBAC（基於角色的存取控制，Role-Based Access Control）

RBAC 是 SaaS 平台常用的存取控制機制，它根據 「使用者的角色」 來決定該用戶能夠存取哪些資料與功能。

🔹 典型的角色權限架構

角色	權限
管理員（Admin）	可管理所有企業數據、設定使用者權限
企業擁有者（Owner）	只能管理該企業的數據與用戶
一般員工（Employee）	只能查看與自己有關的數據，如客戶名單、工作報告
訪客（Guest）	只能查看公開資訊，無法修改數據

📌 範例：RBAC 權限設定（JSON 格式）

{
  "role": "employee",
  "permissions": {
    "view_customers": true,
    "edit_customers": false,
    "manage_users": false
  }
}

這樣的權限控管可以確保 不同級別的用戶只能存取適當的資料，防止未授權的數據存取。

2️⃣ 加密技術（Encryption）

SaaS 平台中的數據加密（Encryption） 主要用來防止數據在傳輸與儲存過程中被未授權存取。

🔹 常見的加密技術：

SSL/TLS（HTTPS 加密傳輸）：確保用戶端與伺服器之間的資料傳輸安全。
AES（Advanced Encryption Standard，高級加密標準）：用於加密 SaaS 伺服器存放的敏感數據，例如用戶密碼、財務資訊等。
哈希（Hashing）+ Salt：用於保護使用者密碼，確保即使資料庫被攻擊，密碼也不會被輕易破解。

📌 範例：使用 bcrypt 進行密碼加密（Python）

import bcrypt

password = "securepassword"
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

print(hashed)  # 儲存這個雜湊值，而不是明文密碼

這樣即使駭客入侵了資料庫，也無法直接取得使用者的明文密碼。

結語

多租戶 SaaS 架構是一種強大的軟體設計方式，讓 SaaS 供應商能夠降低成本、提高擴展性，同時提供客戶所需的客製化功能。

透過適當的資料隔離技術、API 設計與安全性措施，可以確保多租戶環境的穩定與安全。

如果你是開發者或架構師，理解多租戶 SaaS 模式，將能幫助你設計更靈活、高效的雲端應用！

多租戶 SaaS 架構完整指南：從概念到技術實現

什麼是多租戶（Multi-Tenant）架構？

舉例說明

傳統軟體模式 VS SaaS 模式

多租戶 SaaS 架構：資料隔離方式詳解

共享資料庫，共享 Schema（Shared Database, Shared Schema）

共享資料庫，獨立 Schema（Shared Database, Isolated Schema）

獨立資料庫（Separate Database）

多租戶架構的 UI 客製化

透過 API 控制不同的前台設定

具體案例：多租戶 SaaS 的 UI 客製化應用

🟢 案例 1：品牌風格與視覺設定

🟢 案例 2：功能開關（Feature Toggles）

🟢 案例 3：動態導航選單

為什麼透過 API 來控制 UI 設定？

多租戶 SaaS 的擴展性與安全性考量

高可用性（High Availability）

1️⃣ 負載平衡（Load Balancing）

2️⃣ 使用 CDN（內容傳遞網路）來加速前端 UI 加載速度

安全性與權限控管（Security & Access Control）

1️⃣ RBAC（基於角色的存取控制，Role-Based Access Control）

2️⃣ 加密技術（Encryption）

結語

使用 gcloud CLI 進行 SSH 連線的完整指南

微服務 vs. Serverless：開發架構該如何選擇？完整比較與應用指南

AWS CORS 預檢請求與設定指南

SSH 連線是什麼？初學者必看的安全連線工具指南

OWASP Top 10：最新的 Web 安全風險與防範措施（2021 版）

傳統 Web 開發：伺服器端渲染與 MVC 架構

關於本站

什麼是多租戶（Multi-Tenant）架構？

舉例說明

傳統軟體模式 VS SaaS 模式

多租戶 SaaS 架構：資料隔離方式詳解

共享資料庫，共享 Schema（Shared Database, Shared Schema）

共享資料庫，獨立 Schema（Shared Database, Isolated Schema）

獨立資料庫（Separate Database）

多租戶架構的 UI 客製化

透過 API 控制不同的前台設定

具體案例：多租戶 SaaS 的 UI 客製化應用

🟢 案例 1：品牌風格與視覺設定

🟢 案例 2：功能開關（Feature Toggles）

🟢 案例 3：動態導航選單

為什麼透過 API 來控制 UI 設定？

多租戶 SaaS 的擴展性與安全性考量

高可用性（High Availability）

1️⃣ 負載平衡（Load Balancing）

2️⃣ 使用 CDN（內容傳遞網路）來加速前端 UI 加載速度

安全性與權限控管（Security & Access Control）

1️⃣ RBAC（基於角色的存取控制，Role-Based Access Control）

2️⃣ 加密技術（Encryption）

結語

Similar Posts

關於本站