一、從0到1

2020.7.31 anyRTC的信令服務1.0正式釋出，這一天距離專案啟動日僅過去1個半月左右。在這麼短的時間裡我們都做了什麼事情？

1，訊息流模式

我們的定位就是穩定可靠、低延時、高併發的全球信令服務，與傳統的即時通訊(IM)服務不同，信令服務主要構建實時應用場景，更專注於高併發和低延時。

訊息流模式是使用者A需要向B傳送一條訊息，首先服務會對B做使用者定址，然後將訊息路由到使用者B所在區域，最後傳送給B。

2，資料協議

由於不需要儲存帳戶、聯絡人等業務資料，因此協議的設計可以大幅簡化。但是在設計的一開始，我們也走了彎路。方案初期參考傳統的即時通訊的設計，客戶端記錄一個本地資料的備份，需要同步資料時，將備份的資料傳到服務端，服務端通過計算伺服器資料與傳上來的備份資料的差異，將差異資料發給客戶端，客戶端再儲存差異資料完成同步。不過這個方案有兩個問題：一是備份的資料量會隨著客戶端資料的增多變得越來越大，同步時流量開銷大；二是客戶端每次同步都要計算差異資料，會帶來額外的效能開銷和實現複雜度，同時影響了資料到達的實時性。後來我們設計了新的協議，我們稱之為RSync(路由同步)協議。

RSync協議的原理為發出的信令訊息有三個狀態，0：未送達，1：已發出，2：已收到；訊息的這三個狀態只有狀態2需要接收端Ack，既保證了不會丟失資料，又兼顧了信令訊息送達的速度；而服務與服務之間只負責訊息的分發路由。

3，雙活+多資料中心架構

雙活：
我們的雙活是Master-Master架構，沒有主從的區分，雙活能夠同時提供業務服務能力；既實現了容災的功能，又增加了系統的整體吞吐量。比如MSS管理服務，我們分別在香港和倫敦兩地分別部署了一套，負責全球各地資料中心之間的資料分發。同時每個資料中心都會部署兩套RSS服務；而IMS接入服務則是一地多套部署。

多資料中心：
在中國、日本、新加坡、孟買、法蘭克福、洛杉磯等地均部署了資料中心，這樣能更好的為本地化的APP提供服務。隨著中國的業務和出海業務的發展，未來還會在更多的地域進行資料中心部署。

4，RPC - TXP元件

anyRTC基於微服務設計理念，每個服務都是相對獨立的業務模組。服務與服務之間的資料互動使用RPC元件來進行，一開始我們使用了開源的ZMQ元件，看中的是ZMQ精簡的設計以及優良的效能表現；但在實際業務上線後，經過後臺監控發現，在全球部署的業務場景下，跨國通訊這塊的效能往往達不到我們的要求。因此我們開發了一套TXP協議元件，使用UDP實現的一個快速可靠協議，相比於TCP的傳輸速率提高了40%左右，特別是在跨國垮運營商等一些高延時高丟包的場景下，效能優勢更為顯著。

二、解決核心問題

1，C10K

任何一個高併發的服務都會面臨C10K問題。C10K的核心問題就是面臨大規模的Tcp連線時如何保證每一個使用者與服務之間的資料互動實時性，和經濟的系統資源開銷。

當然現在很多開源的專案都有C10K問題的解決方案。anyRTC的後臺服務結合自身的業務特徵，定製了適合自己的業務模型的方案；anyRTC都是基於Linux的C++服務，同時我們還支援UDP的連線，UDP的連線本身就沒有C10K問題；而TCP連線使用epoll來適用於大規模的應用場景。

2，資料一致性

使用者位置不確定性：
一個APP的應用的使用者遍佈全球，同時一個使用者也可以全世界到處跑，那是否允許使用者就近接入服務就對業務處理流程有很大影響。我們的設計是必須就近接入，信令服務和即時訊息服務不同，信令服務更追求訊息到達的速度，同時系統不記錄使用者的業務資料，因為我們不限定使用者使用的區域，所以就近接入是最優的方案。但是允許就近接入，就必須保證資料一致性不影響業務，也就意味著使用者資料需要全域性同步。

資料中心如何同步：
使用者資料全域性同步是一個很大的系統開銷，所以必須對所有的業務模組進行細分再細分，找到必須要全域性同步的業務模組，比如說群訊息；一個人在群裡發了一條訊息，必須保證全球任一資料中心的群內使用者都要收到此訊息。

anyRTC設計了一個數據管理服務，對全球使用者進行區域劃分，每個區域的資料中心可以把資料分發到管理服務，管理服務對資料進行全域性分發，避免每個資料中心進行資料直接互動。同時配合離線儲存服務，就可以既保證區域資料中心的業務精簡化，又保證了系統的資料完整性。

三、快速迭代

隨著業務的增長，需求也在增多；如何避免做出華而不實的過度設計，往往需要經過幾輪思考、討論、推翻的迭代過程。

1，簡化需求：

聚焦核心功能點，剝離實際業務的干擾。由於很多使用者還不是非常理解我們的信令服務和即時通訊服務到底有什麼不同；所以在面臨需求時，我們要做到需求與功能點相匹配，避免過度設計，將真實業務還給使用者。

2，微服務：

我們將系統分拆為接入服務，區域路由服務，管理服務，日誌服務，資料服務，統計服務，運維服務、上報服務等各種微服務，這樣可以保證功能迭代的速度。

3，相容老版本：

這是大多數業務系統升級都會面臨到的問題；與APP不同，我們是提供服務能力，不能夠隨時要求每個客戶去升級SDK模組，我們在設計初期就採用了重服務端、輕客戶端的方案，這樣在系統升級後，不會要求每個客戶端去升級SDK，對老版本使用者更加友好。

四、多區容災

傳統的資料中心級災備方案是“兩地三中心”，即同城有兩個互備的資料中心，異地再建設一個災備中心，這三個資料中心平時很可能只有一個在提供線上服務，故障時再將業務流量切換到其他資料中心。這裡的主要問題是災備資料中心無實際業務流量，在主資料中心故障時未必能正常切換到災備中心，並且在平時大量的備份資源不提供服務，也會造成大量的資源浪費。

多區容災的核心是多個數據園區同時提供服務，因此即便某園區整體故障，那另外幾個園區的業務流量也只會各增加一定比例。反過來說，只需讓每個園區的伺服器資源跑在容量上限的(N-1)/N，保留1/N的容量即可提供無損的容災能力，而傳統“兩地三中心”則有多得多的伺服器資源被閒置。此外，在平時多個園區同時對外服務，因此我們在故障時，可以隨時將流量切換到其他園區。

一個系統不能只有容災，必須有業務監控才能更好的避免故障。

產品剛上那段時間後臺故障很多。比故障更麻煩的是，因為監控的缺失，經常有些故障我們沒法第一時間發現，造成故障影響面被放大。

1，故障分析

每個故障不分大小，開發人員需要徹底覆盤故障過程，然後商定解決方案，補充出一份詳細的技術報告。這份報告側重於：如何避免同類型故障再次發生、提高故障主動發現能力、縮短故障響應和處理過程。

2，監控告警體系

監控體系實現思路非常簡單，允許業務程式碼在共享記憶體中對某個監控ID進行設定或累加報警閾值的功能。每臺機器上的上報服務會定時將所有ID-閾值上報到監控中心，監控中心對資料彙總入庫後就可以通過統一的監控頁面輸出監控曲線，並通過預先配置的監控規則產生報警。

五、專案依賴：

由於我們需要對信令服務做非常多的特殊處理，比如資料同步協議，資料一致性，異常恢復等等。所以anyRTC的信令服務並未直接使用任何第三方的服務。但是我們很多的設計理念都是參考了許多的成熟案例，比如redis中的叢集資料一致性設計；ZooKeeper的一些分散式服務排程理念等。

減少第三方服務的依賴的好處就是對系統環境的要求很低，可以快速上線服務，降低系統部署的複雜度，也會減小運維和升級成本。

六、客戶端能力

七、適用的場景

1，語音聊天室
麥位控制：麥位控制、排麥
房間管理：房間人數、房間名單、房間進出通知

2，視訊聊天
呼叫邀請：傳送和接收呼叫邀請
使用者管理：使用者線上狀態、使用者資訊

3，直播聊天室
房間管理：房間人數、房間名單、房間進出通知
互動控制：收發題目、連麥申請

4，線上教育
白板：畫筆軌跡
課堂管理：學生名單、課堂公告、舉手發言
信令控制：課件控制、舉手發言、麥克風禁言
課堂錄製：提供歷史訊息隨時回放課堂聊天內容與白板內容

5，物聯網
智慧家居控制信令
智慧車載遠端控制
智慧手錶收發訊息
虛擬現實（Virtual Reality，VR）/增強現實（Augmented Reality, AR） 實時標註

6，IM信令通道
訊息傳送
訊息同步
線上狀態維護
音視訊呼叫