SaaS 帝國的基石：Laravel 多租戶系統（Multi-tenant）終極架構指南，從零打造你的專屬王國

嗨，我是浪花科技的資深工程師 Eric。今天想來聊一個聽起來很潮，但實際上是許多 SaaS (軟體即服務) 產品背後的核心骨架：Laravel 多租戶系統（Multi-tenant）設計。你是不是曾經想過，像 Slack、Shopify 這樣的服務，是怎麼做到讓成千上萬個客戶（租戶）在同一個應用程式裡，各自擁有獨立的資料空間，互不干擾？難道他們為每個客戶都複製貼上一整套程式碼跟資料庫嗎？想到要管理上千個部署，我的頭就開始痛了。

當然不是！這背後的魔法，就是「多租戶架構」。簡單來說，就是用一套軟體系統，服務多個客戶。這就像蓋一棟公寓大樓，而不是為每戶人家蓋一棟獨立別墅。房東（也就是我們開發者）只需要維護一棟大樓，但每個住戶（租戶）都有自己獨立的門鎖和房間，享受著私密空間。這不僅大幅降低了維護成本，也讓新客戶的「入住」流程變得極為快速。

今天，我會帶你從概念到實戰，一步步拆解 Laravel 多租戶系統的設計精髓。不管你是正準備開發下一個偉大的 SaaS 產品，還是想讓自己的架構設計功力更上一層樓，這篇文章絕對能讓你滿載而歸。準備好了嗎？泡杯咖啡，我們開始吧！

什麼是多租戶 (Multi-tenancy)？為什麼你的下一個 SaaS 專案需要它？

在我們深入程式碼之前，先得把觀念搞清楚。所謂的「多租戶」，核心精神就是「共享」與「隔離」。

• 共享 (Shared)：所有的租戶共享同一個應用程式實例、同一個程式碼庫，甚至可能共享同一個資料庫。這意味著當你需要更新功能或修補漏洞時，只需要部署一次，所有租戶就能同步升級。這對維運來說，簡直是天堂。
• 隔離 (Isolated)：儘管底層資源是共享的，但每個租戶的資料、設定、使用者等都必須是嚴格隔離的。A 公司的資料絕對不能被 B 公司的使用者看到，這是最高指導原則，也是多租戶設計中最具挑戰性的一環。

那麼，採用多租戶架構有什麼好處呢？身為一個有點龜毛的工程師，我喜歡凡事先看優缺點：

• 成本效益：維護一套系統的成本遠低於維護一百套系統。伺服器、資料庫、維運人力的開銷都能大幅降低。
• 維護效率：一次更新，全員受惠。不用再為每個客戶手動上版，省下的時間可以拿去研究更多酷東西。
• 快速擴展：新客戶註冊後，系統只需要為他建立新的租戶資料，幾乎可以瞬間開通服務， onboarding 流程極為順暢。

當然，天下沒有白吃的午餐。多租戶架構也帶來了新的挑戰，例如：架構設計更複雜、資料隔離的風險、以及「吵鬧的鄰居」問題（某個租戶的異常高流量可能影響到其他租戶）。但別擔心，這些問題都有成熟的解決方案，而 Laravel 正是解決這些問題的絕佳工具。

架構大對決：單一資料庫 vs. 多重資料庫，我該選哪條路？

這是多租戶設計的第一個，也是最重要的一個十字路口。你的選擇會深深影響後續的開發與維運。主要有兩種主流策略：

方案一：單一資料庫，共享 Schema (Single Database, Shared Schema)

這是最常見也最簡單的入門方式。所有租戶的資料都存放在同一個資料庫、同一套資料表中，我們透過在每個需要區分租戶的資料表上增加一個 tenant_id 欄位來進行識別。

舉例來說，你的 products 資料表可能會長這樣：

+----+------------------+---------+------------+
| id | name             | price   | tenant_id  |
+----+------------------+---------+------------+
| 1  | Product A        | 100.00  | 1          |
| 2  | Product B        | 150.00  | 1          |
| 3  | Cool Gadget      | 200.00  | 2          |
+----+------------------+---------+------------+

當租戶 1 查詢他的產品時，系統必須在所有 SQL 查詢中自動加上 WHERE tenant_id = 1 的條件。

• 優點：開發速度快、伺服器成本低、管理單純（只有一個資料庫要備份和維護）、跨租戶的數據分析相對容易。
• 缺點：資料隔離的風險最高！只要一個查詢忘了加 tenant_id，就可能造成災難性的資料外洩。隨著租戶增多，資料表會變得極度龐大，可能影響效能。

方案二：一租戶一資料庫 (Multiple Databases, One Per Tenant)

這種策略更為極致，直接為每個租戶建立一個獨立的資料庫。應用程式在收到請求時，需要先識別出是哪個租戶，然後動態地切換到該租戶專屬的資料庫連線。

• 優點：資料隔離性和安全性是頂級的。每個租戶的資料庫都是獨立的，完全不用擔心資料交叉污染。也更容易針對特定的大客戶進行資料庫的客製化或效能調校。
• 缺點：管理複雜度直線上升！你有多少個租戶，就要管理多少個資料庫。執行資料庫遷移 (Migration) 時，需要為所有資料庫都跑一次，這就是工程師的惡夢。伺服器成本也更高。

工程師的小囉嗦：到底怎麼選？

我的建議是：除非你有非常明確的理由（例如法規要求、客戶合約規定），否則從「單一資料庫」開始。 對於絕大多數新創 SaaS 產品來說，單一資料庫的開發速度和低成本優勢是無可取代的。你可以透過 Laravel 強大的 Global Scope 機制，優雅地解決資料隔離問題。等到你的業務真的成長到單一資料庫無法負荷時，再來考慮遷移或混合模式也不遲。過早優化是萬惡之源，記住了！

實戰演練：用 Laravel 打造多租戶系統

光說不練假把戲，我們來動手吧！這裡我會分別展示兩種架構的核心實作思路。

租戶識別：誰是老大，我怎麼知道？

在處理資料之前，系統得先知道「現在是誰在說話」。常見的租戶識別方式有：

• 子網域 (Subdomain)：例如 tenant1.yourapp.com。這是最常見且專業的做法。
• 自訂網域 (Custom Domain)：允許租戶綁定自己的網域。
• 請求路徑 (Request Path)：例如 yourapp.com/tenant1/dashboard。比較少見。

我們會以最常見的「子網域」為例。你需要一個中央資料庫（或稱為 `landlord` 資料庫）來存放所有租戶的資訊，包括他們的子網域對應。

單一資料庫實作：Global Scope 的魔法

這是 Laravel 的精髓所在。我們可以定義一個全域作用域 (Global Scope)，讓它自動為所有 Eloquent 查詢加上 WHERE tenant_id = ? 的條件。

步驟 1: 建立 Trait 與 Scope

首先，建立一個 `app/Models/Traits/BelongsToTenant.php` Trait 和 `app/Models/Scopes/TenantScope.php` Scope。

TenantScope.php:

<?php

namespace App\Models\Scopes;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;

class TenantScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        // 檢查當前是否有已識別的租戶
        if (tenancy()->getTenant())
        {
            $builder->where($model->getTable() . '.tenant_id', tenancy()->getTenant()->id);
        }
    }
}

BelongsToTenant.php:

<?php

namespace App\Models\Traits;

use App\Models\Scopes\TenantScope;
use App\Models\Tenant;
use Illuminate\Database\Eloquent\Model;


trait BelongsToTenant
{
    protected static function bootBelongsToTenant()
    {
        static::addGlobalScope(new TenantScope());

        // 當建立新模型時，自動填入 tenant_id
        static::creating(function (Model $model) {
            if (tenancy()->getTenant()) {
                $model->tenant_id = tenancy()->getTenant()->id;
            }
        });
    }

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

這裡的 `tenancy()->getTenant()` 是一個輔助函數，它會回傳當前已識別的租戶物件。你需要自己實作一個服務來處理這部分的邏輯，通常會在 Middleware 中完成。

步驟 2: 在你的模型中使用它

現在，在你所有需要區分租戶的模型中，只要 use 這個 Trait 就行了！

<?php

namespace App\Models;

use App\Models\Traits\BelongsToTenant;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    use HasFactory, BelongsToTenant;
    
    // ...
}

就這樣！從現在開始，所有對 Product 模型的查詢，例如 Product::all()，都會被 Laravel 自動轉換成 SELECT * FROM products WHERE tenant_id = [current_tenant_id]。是不是很優雅？

多重資料庫實作：動態切換資料庫連線

如果選擇了這條硬核路線，我們需要一個 Middleware 來動態設定資料庫連線。

步驟 1: 設定資料庫連線範本

在 config/database.php 中，設定一個租戶資料庫的連線「範本」。

'connections' => [
    // ...
    'tenant' => [
        'driver'      => 'mysql',
        'host'        => env('DB_HOST', '127.0.0.1'),
        'port'        => env('DB_PORT', '3306'),
        'database'    => null, // 我們會動態設定它
        'username'    => env('DB_USERNAME', 'forge'),
        'password'    => env('DB_PASSWORD', ''),
        // ...
    ],
],

步驟 2: 建立 Middleware

建立一個 Middleware，例如 `IdentifyTenantAndSwitchConnection`。

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use App\Models\Tenant;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Config;

class IdentifyTenantAndSwitchConnection
{
    public function handle(Request $request, Closure $next)
    {
        // 根據子網域找出租戶
        $subdomain = explode('.', $request->getHost())[0];
        $tenant = Tenant::where('subdomain', $subdomain)->firstOrFail();

        // 動態設定租戶資料庫名稱
        Config::set('database.connections.tenant.database', $tenant->db_name);

        // 設定預設連線為租戶連線
        DB::setDefaultConnection('tenant');
        
        // 清除之前可能存在的連線快取
        DB::purge('tenant');
        DB::reconnect('tenant');
        
        // 將租戶實例注入服務容器，方便後續使用
        app()->instance('current_tenant', $tenant);

        return $next($request);
    }
}

最後，將這個 Middleware 加到你的 `app/Http/Kernel.php` 的 `web` 或 `api` 群組中。這樣一來，每個請求進來時，Laravel 都會自動連上正確的租戶資料庫。

進階議題：不只是資料庫，多租戶的完整生態系

一個成熟的多租戶系統，需要考量的遠不止資料庫。別怪我沒提醒你，這些坑遲早會遇到：

• 檔案儲存 (File Storage)：使用者上傳的檔案也需要隔離。一個簡單的方式是在檔案路徑中加入租戶 ID，例如 s3://your-bucket/tenant_123/avatars/user.jpg。
• 快取 (Caching)：多個租戶共享 Redis 或 Memcached 時，快取鍵 (Cache Key) 可能會衝突。解決方法是在所有快取鍵前面加上租戶專屬的前綴，例如 tenant_123:users:all。
• 佇列與背景任務 (Queues & Jobs)：當一個背景任務被觸發時，它需要知道自己是為哪個租戶服務的。你需要在任務被分派時，將當前的租戶 ID 一併傳入，並在任務執行時重新建立租戶的上下文環境。

這些議題都值得單獨寫一篇文章來探討，但重點是，你必須從一開始就意識到它們的存在，並在架構設計中預留彈性。

結論

打造一個強健的 Laravel 多租戶系統，就像是為你的 SaaS 帝國打下堅實的地基。它確實比傳統的單一客戶應用程式複雜，但帶來的可擴展性和維護效益是無可比擬的。

我們今天從核心概念出發，比較了兩種主流的資料庫架構策略，並透過程式碼範例展示了如何在 Laravel 中優雅地實現它們。記住，技術選型沒有絕對的對錯，只有適不適合你的業務場景。對大多數專案而言，從單一資料庫與 Global Scope 開始，會是風險最低、效益最高的選擇。

希望這篇深入的探討能幫助你釐清思路，在未來的專案中更有信心地做出架構決策。多租戶的世界很廣闊，但有了 Laravel 這個強大的框架，我們就有能力建造出穩定、高效且可擴展的 SaaS 應用。

如果你在實作過程中遇到任何棘手的問題，或是想針對你的特定業務需求進行更深入的架構規劃，浪花科技的團隊隨時準備好提供專業的協助。

延伸閱讀

• 告別雜亂無章！資深工程師帶你走進 Laravel Admin 後台架構設計的藝術
• 肥 Controller 瘦不下來？Laravel 後台架構終極對決：Repository vs. Action 模式，資深工程師帶你選對屠龍刀！
• 別再手寫 SQL 了！Laravel Eloquent ORM 終極指南：從新手入門到效能優化，一次搞懂 Active Record 的黑魔法

對打造自己的 SaaS 平台或複雜的 Laravel 系統有興趣嗎？歡迎點擊這裡，填寫表單與我們聯繫，讓浪花科技的專業團隊成為你最強大的技術後盾！