SaaS 創業必看：Laravel 多租戶系統 (Multi-tenant) 架構設計全攻略 – 從單一資料庫到獨立隔離的抉擇

嗨，我是 Eric，浪花科技的資深工程師。最近這兩年，不管是想做 B2B 系統還是各類雲端服務的客戶，十個有八個開口就問：「Eric，我們的系統要可以『開分店』，每個客戶要有自己的後台，資料不能混在一起。」

這就是所謂的多租戶系統（Multi-tenant System）。在 SaaS（軟體即服務）大行其道的今天，這幾乎是標配。但是，很多專案在初期因為選錯了架構，導致後期維護變成一場災難——要嘛是資料庫 Migration 跑到天荒地老，要嘛是某個大客戶把資料庫操掛，連帶害死所有小客戶。

今天這篇文章，不講太虛的理論，我們直接用 Laravel 的角度切入，聊聊在 2025 年打造一個穩健的 SaaS 系統，你的架構該怎麼選？程式碼該怎麼寫？

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

簡單來說，多租戶就是「一套程式碼，服務多個客戶（租戶）」。

想像你是一房東（SaaS 平台），你蓋了一棟大樓（應用程式）。

如果是單租戶（Single-tenant），等於每個房客來，你都要重新蓋一棟透天厝給他，成本高到爆炸。

如果是多租戶（Multi-tenant），大家住在同一棟大樓裡，共用水電管線（伺服器資源），但每個人有自己的鑰匙，進不了別人的房間（資料隔離）。

而在 Laravel 開發中，最核心的抉擇點在於：資料庫該如何隔離？

三大主流資料庫隔離策略：你該選哪種？

這是身為架構師最頭痛的選擇題，選定離手，後面要改非常痛苦。我們來看看這三種流派：

1. 共享資料庫，共享 Schema (Shared Database, Shared Schema)

這是最簡單、成本最低，也是最多小型 SaaS 初期的選擇。所有租戶的資料都在同一個 Table 裡，我們透過一個 tenant_id 欄位來區分。

• 優點：
  • 開發速度快，跟寫普通 Laravel App 沒兩樣。
  • 成本最低，只需要維護一個資料庫連線。
  • Migration 超快，一次跑完。
• 缺點：
  • 資料外洩風險高： 工程師寫 Query 只要忘記加 where('tenant_id', $id)，A 客戶就會看到 B 客戶的訂單，這是絕對的災難。
  • 備份困難： 無法單獨備份或還原「某個客戶」的資料。

2. 共享資料庫，獨立 Schema (Shared Database, Separate Schemas)

這主要適用於 PostgreSQL。大家共用一個 DB 連線，但每個租戶有自己的 Schema（命名空間）。這在 Laravel 中實作稍微複雜一點，但在隔離性和成本之間取得了不錯的平衡。

3. 獨立資料庫 (Multi-Database)

這是最「尊爵不凡」的隔離方式。每個租戶都有自己獨立的資料庫（例如 tenant_a_db, tenant_b_db）。

• 優點：
  • 極致的安全隔離： 物理上就分開了，幾乎不可能發生資料混淆。
  • 效能互不影響： 大客戶可以搬到獨立的高效能 RDS 實例，不影響小客戶。
  • 備份靈活： 客戶不爽要走，直接 dump 他的 DB 給他就好。
• 缺點：
  • 維護成本高： 你有 1000 個客戶，就要跑 1000 次 Migration。
  • 連線數爆炸： 每個資料庫都需要連線，伺服器負載較高。

Laravel 實作核心：如何識別租戶？

不管你選哪種資料庫策略，Laravel 第一步都要知道「現在是誰來了」。通常我們透過 Middleware (中介層) 來處理。

網域識別 (Domain Identification)

最常見的做法是透過 Subdomain (clientA.saas.com) 或 Custom Domain (www.clientA.com) 來識別。

在 Laravel 的 Middleware 中，我們可以這樣寫：

// app/Http/Middleware/IdentifyTenant.php

public function handle($request, Closure $next)
{
    $host = $request->getHost();
    
    // 從資料庫查找對應網域的租戶
    $tenant = Tenant::where('domain', $host)->first();

    if (! $tenant) {
        abort(404, 'Tenant not found');
    }

    // 將租戶資訊綁定到 Service Container，方便全域調用
    app()->instance('current.tenant', $tenant);

    // 如果是多資料庫模式，這時候要動態切換 DB 連線
    $this->configureTenantConnection($tenant);

    return $next($request);
}

這裡有個工程師的小囉嗦：千萬不要在 Controller 裡面才去判斷租戶。這是基礎設施層級的邏輯，一定要在 Request 進入應用程式的最外層（Middleware）就搞定。

Laravel 程式碼層面的隔離技巧

如果你選擇的是「共享資料庫」模式（大多人的起手式），那麼 Laravel 的 Global Scopes 就是你的救命稻草。

我們不希望每次查詢都手動寫 ->where('tenant_id', $id)，人是會犯錯的。我們利用 Trait 和 Global Scope 讓 Eloquent 自動幫我們加上這個條件。

實作 TenantScope

// app/Traits/BelongsToTenant.php

trait BelongsToTenant
{
    protected static function bootBelongsToTenant()
    {
        static::addGlobalScope('tenant', function (Builder $builder) {
            // 假設我們已經在 Middleware 把 current.tenant 存好了
            if (app()->has('current.tenant')) {
                $builder->where('tenant_id', app('current.tenant')->id);
            }
        });

        // 自動在建立資料時寫入 tenant_id
        static::creating(function ($model) {
            if (app()->has('current.tenant')) {
                $model->tenant_id = app('current.tenant')->id;
            }
        });
    }

    public function tenant()
    {
        return $this->belongsTo(Tenant::class);
    }
}

現在，你只需要在你的 Model（例如 Order, Product）裡面加上 use BelongsToTenant;，所有的查詢就會自動被隔離，創建資料時也會自動帶入 tenant_id。這才是優雅的 Laravel 寫法！

進階挑戰：檔案儲存與佇列 (Storage & Queues)

多租戶不只是資料庫的問題，你的檔案（圖片、PDF）和背景工作（Jobs）也需要隔離。

1. 檔案系統隔離 (S3)

不要把所有客戶的圖片都混在同一個 S3 bucket 的根目錄。建議的做法是為每個租戶建立一個資料夾前綴。

Storage::disk('s3')->put(
    app('current.tenant')->id . '/avatars/user_1.jpg', 
    $content
);

甚至，你可以動態配置 Laravel 的 Filesystem config，讓 root 直接指向該租戶的目錄，這樣你的程式碼就不用到處拼接路徑了。

2. 佇列隔離 (Job Queues)

這是很多新手會忽略的坑。當你把一個 Job 推到 Queue 時，這個 Job 被 Worker 執行時，Worker 怎麼知道要連哪一個租戶的資料庫？

如果你用的是 stancl/tenancy 這種成熟套件，它會自動處理 TenantAware 的 Job。如果你是手刻，務必在 Job 的 payload 裡帶上 tenant_id，並在 Job 的 handle() 方法一開始，就重新初始化租戶環境。

直接使用套件 vs. 手刻？

除非你的需求極度特殊，否則在 2025 年，我強烈建議直接使用 Tenancy for Laravel (stancl/tenancy) 這個套件。

• 它完美處理了多資料庫切換的邏輯。
• 它解決了 Migration 跑多顆 DB 的痛苦。
• 它支援 Redis 前綴隔離。
• 它甚至幫你處理了 Subdomain 的路由。

自己手刻多租戶架構雖然可以學到很多，但通常會死在細節上（例如測試很難寫、Cache 污染問題）。商業專案，求穩、求快，套件是好選擇。

結論：沒有最好的架構，只有最適合的

做為工程師，我們很容易陷入「技術潔癖」，覺得一定要做到實體資料庫隔離才叫專業。但實務上，如果你的每個客戶資料量都很小，開 1000 個 DB 只會讓你的 AWS 帳單爆炸，維運成本也高。

Eric 的建議是：

如果是 B2C 或輕量級 SaaS，先用單一資料庫 + TenantScope，等到規模大了再來拆分。

如果是 B2B 且客戶極度重視資安（例如醫療、金融），那就咬著牙上多資料庫隔離。

SaaS 的路很長，架構保持彈性，才能走得遠。

延伸閱讀

想更深入了解 Laravel 架構與資安實作，這幾篇也是必讀：

• Laravel + Redis 不只會快取？資深工程師揭秘 3 大進階戰術：即時廣播、API 限流與分散式鎖！
• Laravel 門神不好當？從自訂驗證到 Middleware，打造滴水不漏的 API 防線
• API 金鑰之亂終結者：Laravel + JWT 深度實戰，打造無狀態認證的現代化後端！