很多團隊第一次把遊戲放上線的時候，伺服器就是一台雲端主機、一個公開 IP、一個人半夜盯著 Discord 看有沒有人喊「掉線了」。這樣其實也能跑，直到某個週五晚上玩家數暴增、或是有人不爽你的封禁決定，拿一個租來的攻擊工具對著你的 IP 打。我們這幾年幫客戶架過 Minecraft 社群伺服器，也維運過手遊的後端 API，踩過的坑大致可以歸成三件事：架構怎麼分層、被打的時候怎麼撐住、以及出事之前怎麼先知道。這篇就照這個順序講。
重點摘要
- 遊戲伺服器架構依同時在線人數、即時性與停機代價決定，不必一開始就做複雜。
- 抗 DDoS 最重要的一步是不讓玩家拿到遊戲主機的真實 IP，這在架構期就要決定。
- 監控的目的是在玩家察覺之前收到通知，Minecraft 看 TPS，手遊後端看 p95 延遲與錯誤率。
- 每個告警都要對應處置動作，備份要定期實際還原才算數。
先想清楚：你的遊戲需要哪一種架構
遊戲伺服器不是越複雜越好。一個五十人上限的 Minecraft 生存伺服器，跟一款預計上架雙平台、要撐開服首週流量的手遊，需要的東西完全不同。我們通常會先問客戶三個問題：同時在線預估多少人？狀態是否需要即時同步（動作類、多人連線）還是回合制／非同步就夠？停機一小時的代價是玩家抱怨，還是會影響營收與商店評分？答案不同，架構就不同。
| 架構層級 | 適合情境 | 優點 | 要注意的事 |
|---|---|---|---|
| 單機一體 | 社群伺服器、封測、小型獨立遊戲 | 成本低、部署快、好除錯 | 單點故障；主機掛掉等於全部停擺，一定要有異地備份 |
| 前後分離 | 手遊後端、需要登入與付費的遊戲 | API、資料庫、遊戲邏輯可以各自擴充 | 資料庫連線數與快取設計會是第一個瓶頸 |
| 代理＋多實例 | 大型 Minecraft 網路、多房間對戰遊戲 | 玩家可在子伺服器間轉移，單一實例壓力可控 | 代理層本身要有備援，跨實例的資料一致性要另外設計 |
| 多區域部署 | 跨國營運、對延遲敏感的即時對戰 | 就近連線、延遲低、單區出事可切換 | 成本與維運複雜度明顯上升，帳號資料要有明確的主區 |
以 Minecraft 為例，Minecraft Wiki 的Java 版伺服器架設教學寫得很清楚：Java 版伺服器對記憶體與單核效能敏感，實體數量、載入區塊、插件都會直接吃掉主執行緒。所以我們替客戶規劃社群伺服器時，通常會從一台 CPU 單核時脈高、記憶體充足的主機起手，等到玩家穩定超過某個門檻，再把大廳、生存、小遊戲拆成不同實例，用代理層串起來。不要一開始就上多實例，維運人力會先被拖垮。
手遊後端則是另一套邏輯。API 伺服器要做到無狀態，讓它可以隨時橫向加開；玩家資料放在資料庫，熱資料（排行榜、活動進度、在線狀態）放進快取。AWS 的 Well-Architected Framework 把可靠性、效能、成本、安全、營運卓越列為設計支柱，我們雖然不一定用 AWS，但這幾個面向確實是每次架構評審都會拿出來對照的清單。
被打是遲早的事：抗攻擊怎麼準備
遊戲伺服器是 DDoS 攻擊的常客，原因很直白：玩家社群裡總有人有情緒，而且攻擊工具的租用門檻非常低。Cloudflare 學習中心對 DDoS 攻擊的說明可以當基礎閱讀，攻擊大致分成流量型（把你的頻寬塞滿）、協定型（耗盡連線資源）與應用層（用看起來正常的請求拖垮服務），三種要用不同方式擋。
我們的經驗是，最重要的一步在架構期就決定了：不要把遊戲主機的真實 IP 暴露給玩家。手遊的 HTTP API 可以直接放在 CDN 或 WAF 後面，這是最成熟的做法。Minecraft 這類走 TCP 長連線的遊戲比較麻煩，需要具備 TCP 代理能力的防護服務，或是自架一層代理節點，把真實主機藏在只允許代理連進來的內網裡。曾經有一位客戶因為早期宣傳時公開了主機 IP，後來換了防護還是照樣被打，最後只能整台搬遷換 IP，這種代價比一開始就規劃好高很多。
防護之外，還有幾件比較「土法」但很有效的事：設定連線速率限制，同一個 IP 短時間內大量連線就先擋；登入流程加上驗證碼或裝置指紋；把管理後台放在完全不同的網段，用 VPN 才能進。攻擊來的時候，你最需要的是管理後台還進得去，才有辦法做任何處置。
監控不是看儀表板，是在出事前收到通知
很多團隊裝了監控工具，但真正的用法是「出事之後回去看圖」。這樣的監控只有事後檢討的價值。我們希望監控做到的是：玩家還沒感覺到之前，值班的人手機已經震了。要達到這件事，重點不在工具，而在指標與告警門檻的選擇。
以我們維運的 Minecraft 伺服器為例，最有預警價值的指標是伺服器 TPS（每秒 tick 數）。TPS 從 20 掉到 18 玩家可能還沒發現，但這通常代表某個區塊的實體或紅石裝置已經開始拖慢主執行緒，再不處理就會變成集體卡頓。手遊後端則看 API 的 p95 延遲與錯誤率：平均值很容易被大量快速請求稀釋，p95 才會反映真正卡住的那群玩家。
我們的基本監控清單
- 主機層：CPU、記憶體、磁碟剩餘空間、網路進出流量（流量突增常是攻擊的第一個訊號）
- 遊戲層：在線人數、TPS 或 tick 時間、登入成功率、付費 API 的錯誤率
- 外部探測：從另一個區域定期模擬玩家連線，確認「外面的人」真的連得進來
- 告警分級：磁碟快滿是白天處理的事，登入成功率掉到九成以下是要立刻叫人的事
- 備份驗證：備份有做不代表能還原，每月至少實際還原一次到測試環境
告警門檻建議先設寬一點再慢慢收緊。門檻太敏感的下場是值班的人每天收到二十封通知，三週後就全部靜音，那跟沒裝一樣。我們的做法是每個告警都要對應一個「收到之後該做什麼」的處置說明，如果一個告警寫不出處置動作，它大概就不該存在。
營運是持續的事，不是上線那天的事
伺服器上線之後，真正花時間的其實是版本更新、插件相容性、玩家資料搬遷、活動期間的臨時擴容，還有跟社群溝通停機維護的時間。這些工作不難，但需要有人穩定地做。如果你的團隊核心是做遊戲內容，把伺服器代管與監控交給專門的人，通常比自己養一位半夜待命的工程師划算。我們在遊戲伺服器建置與營運提供的就是這一段。至於上線前還有哪些商店審核、金流與客服的準備工作，可以接著看手遊上架前的 20 項檢查清單。
常見問題
遊戲伺服器要用雲端主機還是實體主機？
沒有絕對答案，看流量波動與預算。雲端可以彈性加開，適合開服初期與人數不穩的階段；實體或專用主機在負載穩定時，成本比較好掌握。多數團隊會從雲端起步。
小型 Minecraft 伺服器需要 DDoS 防護嗎？
建議要有基本防護。攻擊不看伺服器規模，公開招募玩家的社群伺服器都可能遇到。至少選擇有基礎防護的主機服務，並避免公開真實 IP。
伺服器備份多久做一次才夠？
取決於你能接受回溯多久的進度。玩家資料變動頻繁的遊戲，每日備份是常見的底線，重要更新前再手動備份一次。備份要放在不同的主機或區域，並定期測試還原。