1、文檔名稱：互聯網可編程browser os57112 其它總體設計Transformer 總體設計-云端大規模實時全雙工消息系統技術（北京） 所有,()技術（北京）- 1 -系統名稱Transformer項目作者孫曉文檔提交日期2013.8.1文檔名稱：互聯網可編程browser os57112 其它總體設計修改技術（北京）- 1 -No修改后版本號修改內容簡介修改日期修改人1.0總體設計2013.8.1孫曉1.1增加 Channel 內置 Schema 的描述2013.8.5孫曉文檔名稱：互聯網可編程browser os57112 其它總體設計目錄Transformer 總體設計1123背景

2、1名詞解釋1設計目標13.1 實現的功能13.2 設計的性能考慮2設計思路及折衷24.1 系統邏輯視圖24.2 權限44.3 ChannelName44.4 Channel 描述54.5 Session 管理54.6 Trigger 機制64.7 BCMS 需求64.8 消息到達率64.9 宕機恢復74.10 服務擴容7系統設計7455.1系統模塊圖75.1.1 AccessLayer Service85.1.2 Router Service85.1.3 Auth Service85.1.4 TriggerId Service95.1.5 KVAccess9主要處理流程95.25.2.15.2

3、.25.2.3隊列9綁定 Trigger9消息傳遞105.3對外命令115.3.15.3.25.3.35.3.45.3.55.3.65.3.75.3.8隊列11取消.12修改權限白.12綁定 Trigger13取消綁定13消息14接收消息14重新建立連接，恢復 Session145.45.5通信協議15內部協議156789時間點15技術委員會審核意見16設計評審意見16附件及參考資料16技術（北京）- 2 -文檔名稱：互聯網可編程browser os57112 其它總體設計技術（北京）- 3 -文檔名稱：互聯網可編程browser os57112 其它總體設計1 背景我們期望提供一套云與端、端

4、與云、端與端能夠以一致的方式進行靈活、實時、可靠的消息交互的系統，以此為基礎，來改變（Transformer）實時互聯網背景下數據獲取和處理的方式，支持服務/應用的開發，比如 realtime、vigour、ifttt、多機等。而現有的服務 BMCS、BCCS 等，都只是提供了一個方面的能力，而且在實際開發中，也各種各樣的問題。因此我們期望整合現有系統和思想，取其精華，去其，實現一套靈活的云端大規模實時全雙工消息系統。2 名詞解釋1)BCMS：baidu cloud message service2)BCCS：baidu cloud channel sevice3)Ub:應用程序開發框架，包括

5、服務器框架，客戶端框架，異步通信框架，日志框架，配置框架等4)Ubrpc: 基于ub 和 idl 的服務器與客戶端 rpc 開發框架，通過定義 idl，自動生成 ub服務器骨架，自動處理通信協議的 mcpack 字段信息，極大提高開發效率，前已經提供異步模式支持5)Trigger：基于一定用戶規則的消息過濾及用戶行為觸發，可以認為是傳統路由規則和基于消息的用戶行為觸發的結合3 設計目標一期我們提供一套全雙工消息系統，能夠方便、實時、可靠的雙端通信，同時支持簡單的前綴路由策略。二期為隊列(Channel)提供 Schema 能力，從而使的消息是可描述和可計算的，訂閱者可以提供 Trigger，來

6、實現單個 Channel 上消息的智能路由和實時推送觸發。三期我們考慮提供跨 Channel 的 Trigger 描述及觸發功能。下面僅表述一期實現功能，Schema、Trigger 等的描述語法可兼容二期需求。3.1 實現的功能1)使用視角技術（北京）第 1 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計a)/取消隊列(Channel)，含提交Schema 等隊列屬性b)Channel權限修改，支持 public 和讀寫分離，可動態修改讀寫白c)/取消Triggerd)Sync/Aysnc Pub/Sub 接口：Queue/Topic 模式，單播，廣播和組

7、播2)管理視角a)權限申請b)隊列c)實時消息進度d)準實時消息到達率3)服務視角a)隊列管理b)海量連接的接入c)Session 維護d)Schema 描述語法及持久化e)Trigger 描述語法、計算及持久化f)Queue/Topic 的消息服務模式對于與端上的交互，本項目僅提供協議描述，端上 SDK 的實現，另外做起。實現所有的功能模塊。3.2 設計的性能考慮主要性能指標包括：隊列規模，端規模，單隊列的端規模，單隊列的 qps 等。我們期望能夠支持 Billion 級別的隊列數，100M 級別的端規模和單隊列端規模，單隊列支持 1w qps。4 設計思路及折衷4.1 系統邏輯視圖技術（北

8、京）第 2 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計1)接入層(AccessLayer)維持海量連接的穩定接入，只完成消息在端和路由層間的透傳和動態 IP 封禁功能。功能單一，從而可以足夠健壯。2)路由層(Router)介于接入層和 Pub/Sub 系統之間，持久化管理隊列 Schema、Trigger 等信息，完成消息到 Pub/Sub 系統的發布，訂閱 Pub/Sub 系統，獲取消息后完成 Trigger 計算及接入層的推送。整體來說，對外，負責 Session 管理，Schema 和 Trigger 的持久化及計算；對內，完成與 Pub/Sub

9、系統的對接。3)Pub/Sub技術（北京）第 3 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計支持海量隊列的 Pub/Sub 系統，我們選擇 BCMS 來支持。提供 Queue/Topic 兩種隊列形態，負責消息的持久化及發布和消費的狀態管理。4.2 權限權限管理需要考慮 Channel 創建及權限。對于 Channel 創建權限，我們考慮直接采用已有的 AK/SK 或者 AccessToken 機制。對于 Channel 的權限，需要考慮的問題有：1)是否與創建權限一致2)是否要有分級權限，如只讀，只寫，讀寫等3)如何支持動態修改從易用性角度來看，一套類

10、似于的權限方案，能夠比較靈活的支持隊列的創建和使用，如 Realtime 的權限機制，只要雙端的 appKey、authKey 和 channel 一致，即可以完成通信。這三元組的申請及共享，完全是由另一種途徑來完成，如口口相傳。這樣也帶來另外的問題，就是 Channel 的所有用戶是對等的，無法做權限的分級，同時一旦需要修改，需要更新已發布的所有用戶。另外案是所有 Channel 用戶擁有的服務接入權限，Channel 的創建者擁有Admin 權限，并負責對其他使用者的，類似于白機制。這種機制可有效解決上述分級和權限更新問題，但是帶來了 Channel 接入的復雜性，特別是對于動態創建大量C

11、hannel 的某些需求來說，比如內多人聊天等。兩種方案的選擇，依賴于隊列的使用形式，對于偏動態的隊列，第案比較適合，而對于能夠較明顯的區分數據提供者和使用者的靜態隊列來說，第二種方案具有明顯的優勢。由于對于我們的系統來說，兩種隊列類型底層的實現架構是一致的，兩種隊列的使用完全由用戶決定，因此兩種認證方案，我們都會支持，由創建者負責選擇使用哪一種。兩種方式都是以現有的 AK/SK 和加密串認證機制為基礎。4.3 ChannelName技術（北京）第 4 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計ChannelName 是 Channel 上多個用戶間建立

12、的唯一紐帶，因此需要是一個由用戶命名的字。在系統內部，負責 ChannelName 的一致性維護，同時給予用戶命名空間的建議。系 統 內 部 會 采 用 以 權 限 信 息 為 前 綴 的 分 級 命 名 組 合 方 式 ， 如AccessToken.ChannelName，對于用戶僅使用 ChannelName 即可。4.4 Channel 描述Channel 的描述由三部分組成，用戶對 Channel 消息的描述（用戶 Schema），Channel的屬性描述，以及 Channel 上消息的公共描述。用戶 Schema 在綁定隊列時提供。Channel 的屬性描述包括類型、Schema 類

13、型、消息是否需要可靠性，也是在綁定隊列時由用戶設置，不支持動態修改。消息的公共描述，是默認支持，由用戶在 Pub 消息時指定的，包括來自哪里，使用有效期（生命期）等。上述 2、3 兩個部分可做動態擴展，不影響已經綁定的隊列和發布的消息。4.5 Session 管理對于Channel 和發布消息來說，都可以認為是一個的 Req/Res令形式，與傳統的交互沒有區別。但是對于基于 Trigger 的消息訂閱來說，需要的是一種類似于登陸/的 Session機制，具體來說是綁定 Trigger 時提交 Trigger 規則到服務端，同時建立一條從服務端接收消息的通道，當服務端有消息符合條件時，經由該通道

14、完成消息的推送。這里需要解決的問題是，當 TCP 連接斷開重連后，如何知道該連接上綁定的 Trigger，以及消息分發到前端后，如何知道該消息滿足哪個 Trigger 條件。我們考慮為每一個 Trigger 提供一個 TriggerId，在綁定 Trigger時返回，由使用者維護，在重連發生時，提交所需要的 TriggerId 即可完成狀態恢復。TriggerId 是隸屬于權限和 ChannelName 的。這樣的話，在接入層，需要維持一個 TriggerId 到 fd 的，以支持全雙工通信和消息透傳，路由層返回消息時帶該消息所滿足的 TriggerId。需要考慮的一個問題是當 fd技術（北京

15、）第 5 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計失效時，如何同步更新所有的 Trigger 到該fd 的，這個問題在接入層的詳設中闡述。同時，對于到的 Pub/Sub 系統來說，一個 Trigger 就對應一個 Sub，即TriggerId 和 SubId 可以認為是一一對應的。4.6 Trigger 機制Trigger 機制應該由三部分組成，Schema/Trigger 條件描述語法，計算規則和端上觸發語法。Schema 和 Trigger 條件描述語法，我們會在一期采用固定的語義，即僅支持一個字，該字滿足 A.B.C 的語法。同時預留擴展方式，即

16、字可以是 Json 或者是 Sql，不同方式由不同的隊列 SchemaType 來標識。一期的計算規則，僅是做字的前綴匹配，即有消息到來時，匹配消息的 Schema部分與 Trigger 的條件，滿足前綴匹配時，將該消息和 TriggerId 推送出去。端上觸發語法，不在本項目考慮范圍之內。4.7 BCMS 需求現有 BCMS 系統，在海量隊列、隊列形態、消息的持久化和狀態管理上，已經能夠滿足需求，但是需以下幾點：1)Topic 模式，主動獲取消息時的 SubId 和進度管理。2)堆積消息的批量拉取3)訂閱方式的優化，可以基于單 TCP 連接訂閱多個隊列4)Topic 訂閱數的提升，如可以支持

17、單 Topic 上億訂閱者對于 1、2 個需求，需要同步解決，對于 3、4 可以后續解決。4.8 消息到達率由于端設別的特殊性，長連接失效率較高，導致消息的到達率會受到影響，按經驗來看，長連接建立時完成堆積消息的推送，會達到比較好的效果。因此需要支持在連接重連時，完成堆積消息的拉取。具體來說是當路由層接收到上傳的 TriggerId 時，觸發離線拉取流程，而對于上傳的是 Trigger 條件，認為是第一次上線，并不提供離線拉取功能。技術（北京）第 6 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計4.9 宕機恢復當接入層宕機時，連接到該的端會觸發重連，此時要

18、求通過 Session 恢復協議，重新上傳Channel 及對應的SessionId，完成連接狀態恢復。此時Router 上到 AccessLayer的連接會逐步失效，不需要額外的狀態恢復操作。路由層宕機，此時對外部連接沒有影響，但是 AccessLayer 到該 Router 的訂閱會失效，需要重新恢復。采用的方案是 AccessLayer 重新建立與 Router 的連接，并且傳遞所有失效的 Channel 和 SessionId 到 Router，Router 從 AccessLayerChannel 的 Schema和 SessionId 對應的 Trigger 描述，恢復狀態。上述兩

19、個問題都需要考慮的問題是在重啟過程中，如何保持多機上的均衡，這個在詳設中描述。4.10 服務擴容接入層和路由層都是無狀態的，關鍵是依賴的 MQ 的擴容能力，包括兩個方面：1) 集群服務能力擴容，目前已經能夠支持水平擴容。2) 單隊列服務能力擴容，目前 bcms 單隊列的服務能力受限于單機，這個是需要優化的。5 系統設計5.1 系統模塊圖技術（北京）第 7 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計橙色為我們需要實現的模塊，為需要改造的模塊，綠色為已經的需要依賴的模塊。5.1.1 AccessLayer Service該服務是一個基于 TCP 的純異步透傳

20、無狀態服務，同時需要支持 IP 封禁功能，單機可支撐 2M 個 TCP 長連接。該服務對外支持 TCP 接入服務，僅支持 TCP 雙工通信，不支持單連接上 Req/Res 這種通信模式。需要建立隊列、刪除、Trigger、刪除時 Req/Res 響應對 FD 的映射和轉發機制。需要建立 TriggerId 到 FD 的和轉發機制。具體實現策略在詳設中描述。5.1.2 Router Service該服務是一個基于 TCP 的純異步服務，負責隊列管理、Trigger 管理、Pub 和 Sub 及Trigger 計算，是一個無狀態的模塊，所有狀態通過 KVAccess 服務實現持久化管理，并對外提供

21、隊列信息服務。5.1.3 Auth Service技術（北京）第 8 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計基于 Uas 和隊列類型，實現兩種認證策略。最主要的是實現基于用戶的 AK/SK 的分級認證策略，需要實現分級白的持久化存儲。5.1.4 TriggerId Service提供全局唯一的 ID 管理服務，保證重啟后分配的 ID重復，不需要有持久化支持。5.1.5 KVAccessKVAccess 在 BCMS 中已經，我們需要改造以支持新的需求。目前需要新增的需求有：1)ChannelName 到 BCMS 的 Queue/Topic Name

22、 的單次寫入，多次，需要有讀 Cache 的支持。2)ChannelName 到 Schema 的單次寫入，在路由層恢復時，暫不需要 Cache 支持。3)TriggerId 到 TriggerInfo 的單次寫入，路由層恢復時，暫可以不需要 Cache 支持。模型的選型在詳細設計中描述。5.2 主要處理流程5.2.1隊列5.2.2 綁定 Trigger技術（北京）第 9 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計5.2.3 消息傳遞技術（北京第 10 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計5.3 對外命令5.3.1隊列1)隊列描述技術（北京第 11 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計2) 返回5.3.2 取消1)2) 返回5.3.3 修改權限白1)技術（北京第 12 頁 共 16 頁文檔名稱：互聯網可編程browser os57112 其它總體設計2) 返