回顧四大模組的業務流程

在最基礎的情境下，玩家的請求會經過 API Gateway，再分流到四個核心服務：

PAM（帳號服務）：玩家註冊、登入、KYC
Wallet（金流服務）：充值、提款、下注、派彩
Game Engine（遊戲引擎）：整合遊戲供應商 API
Risk Engine（風控服務）：AML、流水檢查、多帳號偵測

flowchart TB
    Player[玩家] --> Gateway[API Gateway]
    Gateway --> PAM[PAM<br/>玩家帳號服務]
    Gateway --> WALLET[Wallet<br/>錢包/金流服務]
    Gateway --> GAME[Game Engine<br/>遊戲引擎/聚合器]
    WALLET --> RISK[Risk Service<br/>風險控制引擎]

多租戶架構＆連線池

上面的架構如果是自己的平台用用可能還行，但包網包網，肯定就是會有很多人來租用你的系統，要同時服務很多租戶（Operator），那現在問題來了我的架構要怎麼近行變動？

在技術上的方案有很多，但其中一個最保守的方式就是每個租戶都有自己的 DB，在之前的架構圖中，每個微服務其實都有一個獨立的 DB；那在多租戶的架構中，就會是每個租戶在每個服務中都會有自己的 DB

但這時候就會暴露一個問題是，如果每一筆資料進來，服務要查資料庫 → 建立連線 → 執行查詢 → 關閉連線，這樣太耗資源，所以就會需要引入連線池這個概念，在一段時間內只要這個租戶持續有流量進來，我們就會快取他的 DB 連線

以 Wallet 金流服務的概念為例子，架構圖如下

flowchart TB
    WALLET[Wallet Service]
    WALLET --> poolMgr[Connection Pool Manager]
    poolMgr --> tenantA[(wallet_db_A)]
    poolMgr --> tenantB[(wallet_db_B)]
    poolMgr --> tenantC[(wallet_db_C)]

整體架構圖

如果我們把所有架構拼湊起來就會變成這樣

flowchart TB
    %% --- 上層 業務流程 ---
    Player[玩家] --> Gateway[API Gateway]
    Gateway --> PAM[PAM<br/>玩家帳號服務]
    Gateway --> WALLET[Wallet<br/>錢包/金流服務]
    Gateway --> GAME[Game Engine<br/>遊戲引擎/聚合器]
    WALLET --> RISK[Risk Service<br/>風險控制引擎]

    %% --- 下層 多租戶連線池 ---
    subgraph PAM_DB["PAM Service"]
        pamCM["Connection Pool Manager"]
        pamCM --> pamTenantA[(pam_tenantA_db)]
        pamCM --> pamTenantB[(pam_tenantB_db)]
    end

    subgraph Wallet_DB["Wallet Service"]
        walletCM["Connection Pool Manager"]
        walletCM --> walletTenantA[(wallet_tenantA_db)]
        walletCM --> walletTenantB[(wallet_tenantB_db)]
    end

    subgraph Game_DB["Game Service"]
        gameCM["Connection Pool Manager"]
        gameCM --> gameTenantA[(game_tenantA_db)]
        gameCM --> gameTenantB[(game_tenantB_db)]
    end

    subgraph Risk_DB["Risk Service"]
        riskCM["Connection Pool Manager"]
        riskCM --> riskTenantA[(risk_tenantA_db)]
        riskCM --> riskTenantB[(risk_tenantB_db)]
    end

    %% --- 業務服務 與 各自 DB pool 的連結 ---
    PAM --> pamCM
    WALLET --> walletCM
    GAME --> gameCM
    RISK --> riskCM

這裡的關鍵在於：

Gateway 共用：所有玩家流量都進同一個入口
Service 共用：程式邏輯是一份，不需要為每個租戶重新寫
DB 隔離：每個租戶有獨立 DB，資料安全、合規
Connection Pool Manager：是「租戶請求 → 對應 DB」的橋樑

結語

這篇筆記，算是我第一次完整理解「多租戶 × 包網」的樣子

未來還有更多細節可以學：像是 Platform Admin Console（平台方怎麼建立租戶）、跨租戶報表、動態擴展架構 但至少現在，我能很清楚地說出：

PAM：身份
Wallet：錢流
Game Engine：遊戲
Risk Engine：風控
Connection Pool：多租戶的橋樑

希望這篇筆記，不只是我的學習記錄，也能成為我未來切入 iGaming 架構思維的一張入場券

微服務視角下的包網平台 02：多租戶架構

回顧四大模組的業務流程

多租戶架構＆連線池

整體架構圖

結語