Java微服務消息隊列架構詳細設計文檔(直接下載下傳)
前言
本文是Java微服務遊戲領域業務線消息隊列中間件詳細架構設計文檔，用于指導消息隊列後續的開發、測試和運維
詞彙表
無
1. 業務背景
2021 年左右，遊戲業務發展很快，系統也越來越多，系統間協作的效率很低，由此帶來幾個明顯的系統問題：
一、性能問題：某個功能觸發多個相關子系統調用完成後續操作，串行同步調用降低了業務功能響應效率。
- 遊戲廠家更新遊戲版本後，營運人員擷取最新的遊戲包，更新版本資訊，然後上傳包 到包管理系統打測試包，營運人員進行基本測試。營運子系統通知論壇有新的包将要 釋出，進行預熱。
- 測試完成後，營運管理子系統要通知包管理系統進行打包 。
- 遊戲準點正式釋出的時候，營運子系統要通知 App、Web 站點等即時更新到新版本 。
- 玩家進行充值，充值完成後充值子系統通知 VIP 子系統。
- VIP 子系統判斷玩家等級達到 VIP 後，要通知福利子系統、要通知客服子系統、要通知商品子系統等級子系統。
二、耦合問題：當新增一個子系統時，需要讓另外某個系統通知時，需要改動發出通知的子系統。
- 如果要增加“廣告子系統”，那麼廣告子系統需要開發新的接口給微網誌釋出子系統調用。
三、協作效率問題：每個子系統提供的接口參數和實作都有一些細微的差别，導緻每次都需要重新設計接口和聯調接口，開發團隊和測試團隊花費了許多重複工作量。
基于以上背景，我們需要引入消息隊列實作消息異步化，進行系統解耦，提升系統間協同效率。
2. 限制和限制
1.資料庫采用 MySql
2.Java 語言編寫
3.需要支援 HTTP 接口
4.叢集成本不能超過 20 台機器
5.品質标準符合 ISO9001 标準
6.單機房部署
7.開發人員 6 人左右
3. 總體架構
3.1 架構分析
3.1.1 高性能
遊戲新版本釋出和 VIP 充值的消息并不多，消息隊列不需要保證高可用性。
3.1.2 高可用
新遊戲預熱在固定事時點準時釋出，是一個非常重要的事件，此時系統不能出現問題，或者消息未通知到某方，進而使玩家不能準點下載下傳或進入營運活動。是以消息隊列系統需要高可用性，包括消息寫入、消息存儲、消息讀取都需要保證高可用性。
3.1.3 可擴充
消息隊列系統的功能基本明确，無需要可擴充。
3.1.4 成本
實作成本低、測試投入大、可以接入到現有運維體系，需要按照運維體系要求開發對應功能。
3.1.5 安全
消息隊列系統可用于多個系統間通信，通訊的業務資料需要加密處理，存儲也的使用者密碼需要采用不可逆算法加密存儲，消息需要保證完整性，可以用校驗和機制，存儲到磁盤的資料需要備份。
3.2 總體架構
白盒圖：
SDK
1. 用戶端采用 Java 語言開發，基于 Netty 實作與服務端互動
伺服器
1. 伺服器基于 Netty 開發，采用 Reactor 網絡模型
2. 兩台伺服器組成一個 sharding，整個系統可以多個 sharding，每個 sharding 包含一主一從兩台伺服器（可以對比 MongoDB shard）
3. 主伺服器提供消息讀寫操作，從伺服器隻提供消息讀取操作
4. 伺服器基于 ZooKeeper 進行主從切換
用戶端和伺服器的 Relation
1. 用戶端與服務端采用 TCP 連接配接，采用 Json 傳遞資料
2. 為了相容非 Java 系統，服務端同時提供 HTTP 接口
MySQL 的 Role 和 Relation
1. 采用 MySQL 主從同步
2. 每個消息隊列對應一個表
3. 消息表最多存儲 30 天内的消息，過期的自動清除
4. 直接用 MySQL 的主從複制來實作資料複制
系統架構圖：
1）采用資料分散叢集的架構，叢集中的伺服器進行分組，每個分組存儲一部分消息資料。
2）每個分組包含一台主 MySQL 和一台備 MySQL，分組内主備資料複制，分組間資料不同步。
3）正常情況下，分組内的主伺服器對外提供消息寫入和消息讀取服務，備伺服器不對外提供服務；
4）主伺服器當機的情況下，備伺服器對外提供消息讀取的服務。
5）用戶端采取輪詢的政策寫入和讀取消息。
4. 詳細設計
4.1 核心功能
4.1.1 消息發送流程
1. 消息隊列系統設計兩個角色：生産者和消費者，每個角色都有唯一的名稱。
2. 消息隊列系統提供 SDK 供各業務系統調用，SDK 從配置中讀取所有消息隊列系統的伺服器資訊，SDK 采取輪詢算法發起消息寫入請求給主伺服器。
3. 如果某個主伺服器無響應或者傳回錯誤，SDK 将發起請求發送到下一台主服務，相當于在用戶端實作了分片的功能
4.1.2 消息消費流程
1. 消息隊列系統提供 SDK 供各業務系統調用，SDK 從配置中讀取所有消息隊列系統的伺服器資訊，輪流向所有伺服器發起消息讀取請求。
2. 消息隊列伺服器需要記錄每個消費者的消費狀态，即目前消費者已經讀取到了哪條消息，當收到消息讀取請求時，傳回下一條未被讀 取的消息給消費者。
3. 預設情況下主伺服器提供讀寫服務，當主伺服器挂掉後，從伺服器提供讀消息服務
4.1.3 伺服器主從切換
1. 同一組的主從伺服器配置相同的 group 名稱，在 ZooKeeper 建立對應的 PERSISENT 節點
2. 主從伺服器啟動後，在 ZooKeeper 對應的 group 節點下建立 EPHEMERAL 節點，名稱分為為 master 和 slave
3. 從伺服器 watch 主伺服器的 master 節點狀态，當 master 節點逾時被删除後，從伺服器接管讀消息，收到用戶端 SDK 的讀消息請求後傳回 消息，收到用戶端 SDK 的寫請求直接拒絕。
4.2 關鍵設計
1）消息發送可靠性
業務伺服器中嵌入消息隊列系統提供的 SDK，SDK 支援輪詢發送消息，當某個分組的主伺服器無法發送消息時，SDK 挑選下一個分組主伺服器重發消息，依次嘗試所有主伺服器直到發送成功；如果全部主伺服器都無法發送，SDK 可以緩存消息，也可以直接丢棄消息，具體政策可以在啟動 SDK 的時候通過配置指定。
如果 SDK 緩存了一些消息未發送，此時恰好業務伺服器又重新開機，則所有緩存的消息将永久丢失，這種情況 SDK 不做處理，業務方需要針對某些非常關鍵的消息自己實作永久存儲的功能。
2）消息存儲可靠性
消息存儲在 MySQL 中，每個分組有一主一備兩台 MySQL 伺服器，MySQL 伺服器之間複制消息以保證消息存儲高可用。如果主備間出現複制延遲，恰好此時 MySQL 主伺服器當機導緻資料無法恢複，則部分消息會永久丢失，這種情況不做針對性設計，DBA 需要對主備間的複制延遲進行監控，當複制延遲超過 30 秒的時候需要及時告警并進行處理。
3）消息如何存儲
每個消息隊列對應一個 MySQL 表，消息隊列名就是表名，表結構設計
4.3 設計規範
1）消息隊列伺服器使用 Spring Boot + Netty 開發
2）MySQL 使用 Innodb 存儲引擎
3）TCP 包的結構設計
4）HTTP 通訊格式
5. 品質設計
5.1 消息隊列管理背景
為了提高架構品質落地，專門為消息隊列實作一個管理平台，友善對系統進行測試、運維、觀測。并且包含權限管理、配置管理、監控。
5.2 成本
一個資料分組就需要 4 台機器（2 台伺服器 + 2 台資料庫)，整體成本較高。
5.3 可維護性
運維希望保證可維護性，各種維護操作要友善，例如收發消息情況、權限控制、上下線、禁止某個生産者發消息，某個消費者消費消息等，是以消息隊列需要容易維護。
6. 演進規劃
6.1 消息隊列一期
實作基本消息發送和接收功能和 SDK
6.2 消息隊列二期
小步快跑疊代出背景管理系統、提高系統的品質。