Gateway

1. 伺服器僅暴露 Gateway 監聽埠，Client 與 Server 之間通訊均通過 Gateway 轉發
2. Client 與 Gateway 僅建立一條連線，Gateway 可與多種 Server（Login、Game）建立連線，初步設想同一時間僅保留一條連線，內網連線的切換代價不高，當然同時保留多條連線也行
3. Gateway 應具備以下功能：加密與解密、壓縮與解壓，我個人認為沒有太大必要讓除 Gateway 之外的 Server 具備壓縮與解壓，邏輯簡單就好

Manager

1. 所有的 Gateway、Server、DBProxy 均來這裡註冊登出用於 Client、Gateway、Server 發現可用的 Gateway、Server、DBProxy，來註冊的服務，應即時報告當前處理數量，實現負載均衡；應具有狀態（開放、關閉），實現偽熱切換
2. 提供管理介面：開關指定服務，訊息廣播（系統訊息，全域性訊息），查詢和通知玩家所在 GameServer 玩家充值事件等等

Login

1. 玩家註冊，玩家鑑權登陸，和不需要快取玩家資訊的所有邏輯（玩家在大廳裡的操作）

Game

1. 快取玩家資訊實現遊戲相關邏輯

DBProxy

1. 資料快取與持久化，監聽並與 Login、Game 進行互動

Message

1. 訊息頭（長度32bit + 標識8bit + 主命令16bit + 子命令16bit） + 訊息體
2. 標識用來按位指定是否加密是否壓縮
3. 使用網路位元組序即大端位元組序
4. 從主命令開始加密壓縮

注：

1. Manager 只會啟動一個，剩餘所有服務均可多開進而負載均衡
2. 客戶端傳送心跳包，服務端接收心跳包，實現客戶端保活
3. 應該會為每個服務啟用守護程序（supervisor）
4. 這裡並未獨立出來日誌伺服器，先這樣吧
5. 有些架構中把登陸伺服器放在第一位，它的登陸和我的登陸意義不同，它的登陸像是一個使用者中心
6. 客戶端獲取 Gateway 地址列表，要麼自己實現 Http 服務，要麼購買相關雲服務，相較於 DNS 指向這些地址更加靈活
7. 沒有最好的架構，只有最適合的架構，隨著架構承載不起當前人數，我認為我會高興的加班調整已不那麼適合的架構，其實本架構我設想的是應對中小型棋牌遊戲專案

思考的時候有很多想要額外說明的，成文時卻東忘西忘，想到時再來補充吧

2017.4.15
關於 Login 想再多說些，它所實現的功能不能僅通過它的名稱來感覺，若把 Login 再拆成 Login、Lobby 也不為過，但是會讓架構稍微複雜些，若非要去掉 Login 把所有邏輯揉進 Game 也並非不可實現，我這裡所想的也只是滿足中小型這個期望作折衷而已，如何來判定指定邏輯是否應該寫入 Login 伺服器，我舉例來說明我的想法，譬如註冊、登陸、簽到、排行榜等等，這些邏輯可以通過 Login 與 DBProxy 直接互動返回結果，它們就應該寫入 Login 伺服器