3 篇文章 含有標籤「architecture」

• status: 📝Proposed / ✅Accepted / ❌Rejected / 🔄Deprecated
• makers: [參與決策的人員或團隊]
• refs: ADR-000 (建議按順序編號)

1. 背景 (Context)​

描述我們面臨的問題是什麼？為什麼現在需要做這個決定？ 例如：目前的資料庫查詢速度過慢，導致使用者在高流量期間無法登入。

• Status: 📝Proposed
• Maker: GameServer , Transaction Server Developer
• Refs: none

Context​

若平台採用 Single Wallet 架構，玩家所有資金最終都歸屬於平台錢包，而非遊戲內部帳戶。

在現行流程中，每一次下注（bet）前，GameServer 都必須向平台確認餘額是否足夠，並在下注成立時完成扣款或鎖款。

因此出現一個直觀的問題：「既然每次下注都要經過 GameServer，平台錢包是否可以直接掛載在 GameServer 上，而不需要一個獨立的 Wallet Server？」

• Status: 📝Proposed
• Maker: GameServer , Transaction Server Developer
• Refs: none

Context​

若採取轉帳錢包，我們就必須負責維護用戶的餘額。本質上，我們也成為了一個平台。

為了設計抗併發系統，我認為可以使用 K:N:M 的概念來描述整個系統下的節點：

• $K$：Player（玩家連線數）
• $N$：Game Server（遊戲邏輯節點）
• $M$：Transaction Server（交易／帳務節點）

且預期是 $K ≫ N > M$。

玩家數量($K$)可能來自我們平台或是外部平台：數量極大、行為不可控，系統上主要的交易來源。

如果交易服務 $M = \{ m_1, m_2, \dots, m_N \}$ 是一群主機構成的叢集，則遊戲伺服器是否應該直接知道交易伺服器的位置，還是統一由 Loading Balancer 進行分發？