0xShinyui
微服務視角下的包網平台 01：從零開始的學習筆記

微服務視角下的包網平台 01：從零開始的學習筆記

2025-08-13

從一個產品經理的角度，用微服務思維一步步拆解包網平台。 從最基本的 PAM，到錢包、遊戲引擎，再到風控引擎，逐層拼湊出完整的架構， 這篇文章是我作為自學者的理解筆記，也是一張觀察博弈產業的入場券。

這篇筆記是我，作為一個 PM，嘗試跨入博弈產業的第一步；雖然身為白產 PM，但我對博弈業的運作邏輯一直很好奇，究竟是什麼樣的產業鏈以及生態，才能構成一個年產值 1000 億的產業

撇開道德與價值觀爭議，我選擇用「學習者」的角度切入。去理解它的系統邏輯 因為對 PM 來說，能拆解清楚 商業邏輯 × 技術架構，才是我們的專業價值

這篇文章可能在商業邏輯上有錯誤的地方，還請見諒，因為資訊實在是太少了 @@

第一步：PAM（玩家帳號服務）

如果用 SaaS 來類比，PAM 就是 User Service。 它的職責很單純：

  • 處理玩家註冊、登入
  • 維護會員層級、代理關係
  • 保存 KYC（身分驗證）狀態 沒有 PAM，就沒有合法的玩家，也就沒有後續的交易

架構圖：只有 PAM

flowchart LR
    Player[玩家] --> Gateway[API Gateway] --> PAM[PAM<br/>玩家帳號服務]

第二步：加入 Wallet（金流 / 錢包服務）

有了玩家，下一步自然就是「錢」 Wallet 是平台的心臟，負責：

  • 玩家充值、提款
  • 下注時扣款，派彩時加款
  • 保持帳本一致性，避免重複扣款 它與 PAM 的交互很緊密：
  • 在交易之前，要先確認玩家身份是否有效（凍結、黑名單、KYC）。

架構圖 v2：PAM + Wallet

flowchart LR
    Player[玩家] --> Gateway[API Gateway]
    Gateway --> PAM[PAM<br/>玩家帳號服務]
    Gateway --> WALLET[Wallet<br/>錢包/金流服務]
    PAM <--> WALLET

第三步：加入 Game Engine（遊戲引擎 / 聚合器）

玩家登入後，真正要玩的就是遊戲 但平台自己不開發遊戲，而是透過 Game Engine 去對接外部供應商

Game Engine 的職責：

  • 整合不同遊戲商 API，提供統一接口
  • 管理遊戲登入、下注、派彩流程
  • 回傳遊戲紀錄給平台

交互上：

  • PAM：確認玩家身份
  • Wallet：下注要扣錢，派彩要加錢
  • （這裡還沒有 Risk，所以一切「無風控」）

架構圖 v3：PAM + Wallet + Game

flowchart LR
    Player[玩家] --> Gateway[API Gateway]
    Gateway --> PAM[PAM<br/>玩家帳號服務]
    Gateway --> WALLET[Wallet<br/>錢包/金流服務]
    Gateway --> GAME[Game Engine<br/>遊戲引擎/聚合器]
    PAM <--> WALLET
    WALLET <--> GAME
    PAM <--> GAME

第四步：加入 Risk Engine（風控引擎）

到這裡，平台已經可以運作了：玩家註冊 → 存款 → 進遊戲 → 派彩 但如果沒有 Risk Engine，平台就會面臨很大的風險：

  • 玩家可能用多帳號洗紅利
  • 錢可能被用來洗錢（AML 問題）
  • Bot 或對沖玩家可能套利

所以 Risk Engine 的角色是「守門員」 它的職責：

  • KYC / AML：檢查提款是否合法
  • 流水檢查：玩家有沒有完成投注量
  • 異常偵測：高速下注、可疑模式

交互上：

  • 與 PAM：拿身份與註冊資料
  • 與 Wallet：提款時攔截、決策是否放行
  • 與 Game Engine：監控下注事件

架構圖 v4：完整的四大模組

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

遊戲商 vs 包網風控差異

額外提一下，在研究時我突然有一個有趣的想法，遊戲商跟包網的風控，那到底差在哪？

遊戲供應商的風控引擎

先說遊戲商的風控重點是 「遊戲公平性」與「防止作弊」，它是「針對單一遊戲」的

  • 範圍：
    • 防止外掛（例如 Blackjack 數牌器、slot 模擬器、Bot 自動下注）
    • 保證 RNG 公平（經 GLI/BMM 認證，避免被操控）
    • 偵測異常下注模式（例如百家樂持續大額單邊下注）
  • 責任：保證遊戲本身的可信度，維護遊戲商與監管牌照的合法性
  • 資料範圍：遊戲商只看到「玩家在這一場遊戲的行為」，不會知道玩家整體資金、跨遊戲紀錄 可以理解成：遊戲供應商風控 = 遊戲內作弊防護

遊戲供應商的風控引擎

包網風控關注的是 「平台級的金流安全與風險管理」，它是「跨遊戲、跨金流」的

  • 範圍：
    • KYC / AML：防止洗錢、大額異常提款
    • 流水檢查：確保玩家投注額達標，避免紅利套利
    • 多帳號偵測：同一 IP/裝置註冊多帳號
    • 行為風險：玩家是否用異常模式在不同遊戲中對沖
  • 責任：保護租戶（平台經營者）的營收，降低損失風險
  • 資料範圍：平台能看到「玩家在所有遊戲 + 所有金流的全域行為」 可以理解成：包網風控 = 平台級資金與玩家行為守門員

一條鏈路：提款流程

回到正題，把四個模組串起來後，來看提款的例子：

  1. 玩家提出提款 → Wallet
  2. Wallet 驗證玩家身份 → PAM
  3. Wallet 發送事件 → Risk
  4. Risk 決策：
    • 低風險：Wallet 呼叫 Payment Gateway，自動出款
    • 高風險：標記後交人工審核
  5. Payment Gateway → Wallet 更新 → 玩家收到回覆

在這條鏈路裡，Wallet 是發起者，Risk 是守門員，PAM 提供身份，Payment Gateway 是執行者。

為什麼用微服務？

最後提一下，為什麼要用 Microservice 的角度看這件事，過去我經手的專案，使用量都偏小，開發團隊也不大，所以在技術上並沒有使用微服務的必要；單體系統往往更快，更容易維護 但當我研究包網的架構時，發現情況完全不同：

  • 每個模組的商業邏輯都很複雜：PAM 不只是登入註冊，還牽涉代理、會員層級、KYC；Wallet 不只是餘額查詢，而是完整的交易帳本。
  • 併發數量可能極高：遊戲下注、派彩、提款、紅利計算，這些操作都可能同時湧入
  • 服務邊界天然分明：身份（PAM）、金流（Wallet）、遊戲供應（Game Engine）、風控（Risk Engine），各自都是獨立的業務領域

這些特徵正好對應了微服務適用的場景：高併發 + 複雜商業邏輯 + 清晰的業務邊界 所以即使我並不是要從工程實作出發，用微服務的角度去理解包網平台，卻讓我能夠更快地看清楚它的模組劃分與交互方式 對一個 PM 來說，這就是價值： 我們不一定要寫程式，但我們要能看懂「這個需求應該是 PAM 的事，還是 Wallet 的事？」、「提款流程應該加規則引擎，還是交給人工審核？」 而微服務的思維，正好給了我這樣的觀察框架

結語：我的自學體悟

一開始，包網平台對我來說是黑箱 後來我用「漸進式」的方法：先 PAM，再加 Wallet，再接 Game，最後放上 Risk，才發現它其實就是四個微服務互相交互

  • PAM：身份
  • Wallet：錢流
  • Game Engine：遊戲內容
  • Risk Engine：安全守門員

其他功能（CRM、代理、報表），都只是建立在這四塊基礎之上 對 PM 來說，理解這些交互，比學程式更重要。因為我們的價值在於：能不能把業務需求，翻譯成「這應該是一個服務，還是某個服務的事件流」 希望這份筆記，不只是我的學習記錄，也能成為我未來進入這個產業的一張入場券