在5 月 27 日舉行的 Qcon 廣州站上，聲網(wǎng) Agora 資深技術(shù)架構(gòu)師吉奇 以《高并發(fā)場(chǎng)景下分布式實(shí)時(shí)信令系統(tǒng)的架構(gòu)實(shí)踐》作為話題，分享了 RTM SDK 背后的架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)。

以下為演講實(shí)錄：

大家好！我叫吉奇，來自聲網(wǎng)?，F(xiàn)在負(fù)責(zé)聲網(wǎng)RTM 實(shí)時(shí)信令云服務(wù)后臺(tái)及SDK技術(shù)架構(gòu)設(shè)計(jì)。這次演講會(huì)按照RTM的系統(tǒng)架構(gòu)上的分布或子系統(tǒng)的層級(jí)關(guān)系來展開。

首先，RTM 是一個(gè)通用的消息系統(tǒng)，主要是為了解決實(shí)時(shí)場(chǎng)景下信令的低延遲和高并發(fā)問題。我們聲網(wǎng)是業(yè)務(wù)遍布全球的平臺(tái)，因此在所有的后臺(tái)設(shè)計(jì)中，把分區(qū)作為一個(gè)比較重要的事情來看。目前 RTM 有幾個(gè)大區(qū)域，有美洲、亞洲、東南亞、中國大陸，還有歐洲、非洲幾個(gè)大區(qū)。區(qū)與區(qū)之間相對(duì)獨(dú)立，每個(gè)區(qū)會(huì)有跨區(qū)傳輸網(wǎng)絡(luò)。每個(gè)區(qū)之間由三個(gè)子系統(tǒng)組成，首先是消息核心（Message Core），還有事件中心（Event Center），最后是應(yīng)用服務(wù)（Application Services）。我會(huì)分別講一下各個(gè)子系統(tǒng)內(nèi)部的架構(gòu)實(shí)現(xiàn)，即消息核心、事件中心、應(yīng)用服務(wù)和跨區(qū)網(wǎng)絡(luò)。

消息核心（Message Core）

首先是消息核心，它是目前成熟度最高，也是最復(fù)雜的子系統(tǒng)。在該系統(tǒng)里面有幾個(gè)主要的組件，首先有接入服務(wù)器、點(diǎn)對(duì)點(diǎn)消息轉(zhuǎn)發(fā)服務(wù)、頻道消息的轉(zhuǎn)發(fā)服務(wù)、簡單的狀態(tài)管理（包括用戶狀態(tài)和頻道狀態(tài)），還有頻道分布狀態(tài)服務(wù)器。

在消息核心，所有的服務(wù)都是分布式，沒有一個(gè)單點(diǎn)或者中心式的情況，因此可以保證高可用，并且性能方面可以支持高吞吐量和低延遲。Messaging Core 有一個(gè)特點(diǎn)，具有非常大的擴(kuò)展性，但是它的問題是只支持基本核心的功能，剩下的都要放在其它子系統(tǒng)中。

分布式的信息核心有幾個(gè)優(yōu)勢(shì)特性：

?完全排除單點(diǎn)故障

?接近100%可用

?端到端延遲 < 100ms

?任何節(jié)點(diǎn)都可水平擴(kuò)展

?支持?jǐn)?shù)百萬人同頻道（無理論上限）

?大型活動(dòng)中支持?jǐn)?shù)百萬QPS消息下發(fā)

?核心功能超高響應(yīng)

所謂核心功能，目前消息核心支持的功能是點(diǎn)對(duì)點(diǎn)消息、頻道消息，可以加入頻道、退出頻道。用戶也可以同時(shí)加入多個(gè)頻道，使用一些頻道管理的功能，比如獲取用戶屬性、頻道狀態(tài)，能查詢頻道中有多少人，其他用戶是否在線等基本功能。

在此，以點(diǎn)對(duì)點(diǎn)消息為例，和大家分享一下擴(kuò)展性是怎么樣做的。首先 SDK 登錄系統(tǒng)的時(shí)候，會(huì)通過 DNS 來訪問我們的 AP 服務(wù)，AP 知道附近的邊緣節(jié)點(diǎn) R 的地址，會(huì)根據(jù)當(dāng)前的客戶端的地理分布，包括邊緣節(jié)點(diǎn)的負(fù)載情況來給 SDK 回一組地址。SDK 在拿到地址之后，可以登錄連接邊緣節(jié)點(diǎn)，然后發(fā)消息。這些消息到達(dá)邊緣節(jié)點(diǎn)后會(huì)投遞給本區(qū)的點(diǎn)對(duì)點(diǎn)消息轉(zhuǎn)發(fā)節(jié)點(diǎn) F。F 知道本區(qū)內(nèi)所有用戶登錄在哪個(gè)邊緣節(jié)點(diǎn)，這是由本區(qū)所有邊緣節(jié)點(diǎn) R 上報(bào)給轉(zhuǎn)發(fā)節(jié)點(diǎn) F 的。圖中的 U 是用戶在線狀態(tài)服務(wù)器，那么一個(gè)用戶給另外的用戶發(fā)消息，有三種情況，第一種情況，對(duì)端在線并且在同一個(gè)區(qū)里面，F(xiàn) 可以直接投遞；第二種情況對(duì)端在線但在別的區(qū)里面；第三種情況對(duì)端不在線。在后兩種情況中，消息轉(zhuǎn)發(fā)服務(wù)器 F 不知道該用戶的信息，也不知道在哪個(gè)節(jié)點(diǎn)上。這時(shí)候就可以通過 U 來獲取這些用戶狀態(tài)，因?yàn)?U 知道全網(wǎng)跨區(qū)情況下的用戶生命周期，也知道這個(gè)用戶是否在線，F(xiàn) 去問 U 是否在線，如果在線在哪個(gè)區(qū)里面，可以通過跨區(qū)投入到別的用戶。

這里的可擴(kuò)展體現(xiàn)在哪里呢？首先，所有的節(jié)點(diǎn)都是可以水平擴(kuò)展的，隨著業(yè)務(wù)量增長，可以增加部署。邊緣節(jié)點(diǎn)是可以隨意增加的，而核心節(jié)點(diǎn) F 和 U 不能做任意的水平擴(kuò)展，因?yàn)樗麄儽Ａ袅艘欢ǖ臓顟B(tài)，我們用了一個(gè)一致性哈希的分片方法，所以把所有用戶的賬號(hào)哈希之后產(chǎn)生一個(gè) 32 位的隨機(jī)數(shù)，想象把這些數(shù)放到一個(gè)環(huán)上，每個(gè)服務(wù)器各自產(chǎn)生一組隨機(jī)數(shù)，在環(huán)上均勻分布。這樣所有的消息會(huì)被映射到比自己的哈希值小的那一個(gè)服務(wù)器上面。所有的節(jié)點(diǎn)的 partition 都是可以動(dòng)態(tài)地增加和減少的。假如說有一個(gè)核心服務(wù)器故障或者下架了，那么它可以重新分布到別的服務(wù)器上，實(shí)際上我們地消息核心中除了邊緣節(jié)點(diǎn)R之外還有十幾種核心節(jié)點(diǎn)，它們都是做了分片的。這就是所謂的可擴(kuò)展性。

高可用怎么樣做呢？首先如上圖所示介紹一下頻道消息簡單的流程。假定邊緣服務(wù)器收到用戶的頻道消息，會(huì)把該消息投遞給 F，F(xiàn) 是點(diǎn)對(duì)點(diǎn)消息的轉(zhuǎn)發(fā)服務(wù)器，它看到是頻道消息的話會(huì)自動(dòng)拋給 D，D 專門負(fù)責(zé)頻道消息分發(fā)，D 采用是級(jí)聯(lián)的模式，每一個(gè)區(qū)都有一組總的頻道消息分發(fā)服務(wù)器，在每個(gè)數(shù)據(jù)中心會(huì)有一組機(jī)房級(jí)別的代理。區(qū)域級(jí)根服務(wù)器發(fā)消息到機(jī)房級(jí)別的代理服務(wù)器，機(jī)房級(jí)服務(wù)器往該機(jī)房所有的邊緣節(jié)點(diǎn) R 轉(zhuǎn)發(fā)，這樣可以保證在超大頻道下面的性能?，F(xiàn)在有一個(gè)問題，之前我說了 U 是保存用戶的生命周期的，而頻道的生命周期與用戶不一樣，頻道不是一個(gè)特定的個(gè)體。比如說用戶要么在中國或美國，不可能同時(shí)在中國和美國，但頻道可以。尤其當(dāng)頻道比較大的時(shí)候，分布會(huì)非常廣，很有可能是跨區(qū)頻道，甚至在中國、美國、歐洲都有用戶處于同一頻道。那么你該怎樣獲取某頻道的用戶分布呢？我們用頻道分布服務(wù)器 O 來處理。所有的 R 都會(huì)在本地頻道創(chuàng)建、銷毀的時(shí)候，把該事件通知給 O。O 把頻道分布的信息告訴頻道消息轉(zhuǎn)發(fā)服務(wù) D，D 會(huì)從中獲得兩個(gè)信息，第一個(gè)信息是對(duì)于某頻道來說，在本區(qū)內(nèi)該頻道的用戶分布在哪幾個(gè)邊緣服務(wù)器上，第二個(gè)信息是可以知道該頻道是否跨區(qū)，如果跨區(qū)的話，又是哪幾個(gè)區(qū)域。D 通過第一個(gè)信息可以判斷在本區(qū)投遞給哪些用戶，通過第二信息可以知道需要通過跨區(qū)傳輸網(wǎng)絡(luò)投遞給哪些別的區(qū)域的 D，讓它們?cè)趧e的區(qū)域來負(fù)責(zé)下發(fā)。

在這里高可用主要體現(xiàn)在 O 是對(duì)等部署的。我們每一條消息或者每一次狀態(tài)改變或者每一個(gè)查詢請(qǐng)求都會(huì)有一個(gè)全局唯一的 ID，這個(gè) ID 由兩部分組成，第一部分保證其唯一性，第二部分保證在某一個(gè) session 之內(nèi)前后的請(qǐng)求有一個(gè)單調(diào)遞增的大小關(guān)系。這樣的話，從多臺(tái)對(duì)等部署的 O 同步給 D 的頻道分布信息，就相當(dāng)于要保證一個(gè)單一來源但多路徑的信息同步的一致性問題，我們是可以通過這個(gè) ID 來做到版本控制和除重從而保證一致的。當(dāng)然對(duì)等部署只是其中一個(gè)手段，還有很多別的模式用到不同的服務(wù)上面，比如事件中心的高可用就是由雙數(shù)據(jù)中心主備切換來保證的。但消息核心中的服務(wù)一般都是采用的比較激進(jìn)的對(duì)等部署的方式，這樣的好處是任何一個(gè)服務(wù)器掛了都不會(huì)有切換的事件，保證服務(wù) 100% 可用。

事件中心（Event Center）

Messaging Core 下面是 Event Center。就像我在開頭說到的，Messaging Core 有一個(gè)限制，它是靠多重冗余和相對(duì)激進(jìn)的策略來保證低延遲和高可靠的系統(tǒng)，因此很多擴(kuò)展的功能沒有辦法做，所以會(huì)通過 Event Center 來支持這些擴(kuò)展功能。

舉個(gè)例子，比如用戶屬性是在消息核心中完成的，而頻道屬性在消息核心中就做不了。因?yàn)轭l道屬性和用戶屬性不一樣的地方在于，對(duì)于某一個(gè)用戶，他的用戶屬性只有他自己能夠編輯，他是該屬性的主人，由該用戶的客戶端來保證屬性的一致性。所以就算在服務(wù)端有多重冗余的情況下，該屬性也可以達(dá)到最終一致。但頻道屬性不同。頻道里可能同時(shí)有多個(gè)人在同時(shí)編輯頻道屬性，也可能同時(shí)有多個(gè)人在讀該屬性，怎樣達(dá)到一致性？這里就需要對(duì)頻道消息的編輯操作有一個(gè)統(tǒng)一的來源。但這個(gè)來源又不能是單點(diǎn)，否則很容易出故障也很容易成為瓶頸。

因此我們決定將所有的事件，包括狀態(tài)改變、消息的投遞都統(tǒng)一寫到 Event Center 里面。Event Center 分為兩個(gè)部分，Event Storage 和 Event Queue。我們的實(shí)現(xiàn)原則是傳輸與狀態(tài)隔離，數(shù)據(jù)與索引隔離。傳輸是 Messaging Core 和跨區(qū)傳輸網(wǎng)絡(luò)來負(fù)責(zé)，狀態(tài)是存在 Event Center，而 Application Services 是消費(fèi)的狀態(tài)，這樣可以做到傳輸與狀態(tài)的隔離。

那什么叫數(shù)據(jù)與索引隔離呢？對(duì)于所有的事件來說我們都會(huì)把它的 meta data，或者叫事件的 header 放到 Event Queue 里，這樣消費(fèi)者去消費(fèi)事件隊(duì)列的話就會(huì)很快，而事件的內(nèi)容本身則放在 Event Storage。我之前說過對(duì)于 RTM 的所有消息、事件、查詢都有一個(gè)ID，這樣的話就能建立一個(gè)事件 Header - 事件ID - 事件Body 之間的映射。消費(fèi)者可以通過 Event Queue 建立對(duì)事件 Header 的索引，通過這個(gè)索引來做各種業(yè)務(wù)邏輯，然后再通過 ID 來找到對(duì)應(yīng)的事件 Body。比如對(duì)于歷史消息的條件查詢就是這么做的。在這種模式下我們可以做到比如查詢當(dāng)前在線的所有用戶里屬性屬性滿足 "gender:female","age:24" 的用戶。

應(yīng)用服務(wù)（Application Services）

Application Services 是一個(gè)微服務(wù)的架構(gòu)，在 Event Center 的支持下可以支持很多的業(yè)務(wù)邏輯。還包括實(shí)時(shí)的監(jiān)控、計(jì)費(fèi)、問題調(diào)查、分析等。它的好處是易于開發(fā)，我們通過 Event Center 把傳輸和事件解耦了，讓我們可以更容易地實(shí)現(xiàn)更多的功能。目前已經(jīng)落地的功能包括頻道屬性和歷史消息，還有很多其他的功能在開發(fā)中。

下面講一下跨區(qū)傳輸網(wǎng)絡(luò)，它負(fù)責(zé)所有區(qū)域到區(qū)域之間的通信。我們有去中心化地實(shí)時(shí)路由計(jì)算策略，會(huì)根據(jù)延遲和負(fù)載來動(dòng)態(tài)挑選跨區(qū)路由。實(shí)際上你發(fā)現(xiàn)在很多場(chǎng)景下面，跨境傳輸是最難的問題，尤其是在教育場(chǎng)景下。例如，老師在東南亞某個(gè)地方，學(xué)生在國內(nèi)，他們之間建立連接、收發(fā)一些消息的過程中，穩(wěn)定性和到達(dá)率會(huì)遇到很多問題。聲網(wǎng)全球有 200 多個(gè)數(shù)據(jù)中心，我們通過智能路由來進(jìn)行實(shí)時(shí)傳輸，比如中國到菲律賓，當(dāng)前網(wǎng)絡(luò)不好的時(shí)候，我們可能會(huì)通過新加坡進(jìn)行中轉(zhuǎn)，如果新加坡到菲律賓好但是到國內(nèi)不好，我們會(huì)也許會(huì)通過國內(nèi)某個(gè)機(jī)房先中轉(zhuǎn)到新加坡。RTM SDK 今年上線后，從運(yùn)營數(shù)據(jù)來看高峰期的跨洋平均 RTT 是 250ms，該數(shù)據(jù)已經(jīng)比較接近實(shí)際網(wǎng)絡(luò)傳輸延遲。

如上圖所示是簡化版的跨區(qū)傳輸網(wǎng)絡(luò)，這個(gè)算法有點(diǎn)類似于 BGP 算法。自治域與自治域之間全連接，每個(gè)節(jié)點(diǎn)都有自己的路由表，每個(gè)節(jié)點(diǎn)會(huì)定期廣播自己的路由表到別的節(jié)點(diǎn)。比如 A 知道到自己到 B、C、D 的延遲是多少，一輪廣播之后 B、C、D 就會(huì)知道自己如果通過 A，到其他節(jié)點(diǎn)的延遲會(huì)有多少。各節(jié)點(diǎn)會(huì)選擇延時(shí)較短的路線傳輸。當(dāng)然，實(shí)際策略肯定不會(huì)這么簡單，因?yàn)槿绻泄?jié)點(diǎn)都采用相同策略，流量可能會(huì)匯集到某一些節(jié)點(diǎn)上去，在流量高峰期時(shí)會(huì)對(duì)這些節(jié)點(diǎn)造成沖擊。因此我們有一套很復(fù)雜的策略來進(jìn)行負(fù)載均衡。