Skip to content

多人連線 3D 遊戲

接案 · 2026年5月 - 2026年10月 · 兼職

3 位 App 開發者做了一款即時多人連線的 3D 骰子遊戲，但只能在自己的筆電上跑。他們要讓它上線，資料庫預算是 0 元，玩家的網路還很慢。

我負責正式環境平台、基礎設施、可靠性，以及跨服務的架構；團隊繼續開發遊戲功能。我直接在他們的 repo 裡、照他們的每週節奏工作，每週交一份書面報告。

實測成果

Start Game 延遲
965 ms
原本中位數 3,921 ms（4 倍）
資料庫喚醒時間
1.6 小時/天
原本 24 小時，仍維持 0 元方案
3.6 Mbps 首次載入
4.3 秒
原本 10.9 秒
點擊後下載量
990 KB
原本 3,922 KB

我做了什麼

從本機到正式上線

  • 6 個服務的部署管線：CI/CD、開機冒煙測試、依版本 tag 部署、缺 secret 防護。
  • Client 藍綠部署、機器常駐不休眠，消除冷啟動造成的 502 錯誤。
  • 3 個區域的遊戲伺服器，依玩家所在國家選主要區域。

0 元資料庫也不斷線

  • 免費資料庫額度每月第 16 天就用完，直接擋住正式環境。
  • 我重新設計存取方式，現在資料庫一天只醒約 1.6 小時，預算是 12.4 小時。

慢速網路也夠快

  • Start Game：遊戲伺服器往返 7 次降到 2 次，資料庫查詢 12 次降到 2 次。
  • 壓縮材質、tree-shaking、提早啟動場景，首次下載量少了約 75%。
  • 公開資源搬到 CDN。

資料管線

  • 在不允許該擴充套件的主機上建 Postgres 訊息佇列，並在 PR 階段用資料庫分支驗證。
  • 從零打造背景 worker：dead-letter queue、冪等結算（重跑也安全）、重試。

可靠性與安全

  • 統一的 JWT 合約，支援雙金鑰輪替；每個服務間呼叫都有逾時與重試。
  • 來源站只接受 CDN 流量，加上 mTLS 與防火牆規則。
  • 處理正式環境事故：重建掛掉的區域、額度封鎖、卡住的佇列訊息。

交接

  • 一行指令起好所有服務的本機環境，以及端到端的本機對戰測試。
  • 11 份決策紀錄、22 份週報、runbook，以及團隊共用的 AI 開發設定。

系統組成

  • API 後端
  • 大廳服務
  • 遊戲伺服器
  • 3D 網頁前端
  • 背景 worker
  • 共用 TypeScript 合約

3 個區域的容器主機、Serverless Postgres、物件儲存、附防火牆的 CDN

約 6 個月，兼職。6 個服務 repo 共 261 個 commit。

有產品要上線，或是已上線的產品太貴、太慢？

在 LinkedIn 找我
↑↓ 移動 ↵ 開啟 esc 關閉