互聯(lián)網(wǎng)時代最常見的遠(yuǎn)程溝通和協(xié)同辦公模式——云會議，每天為成千上萬的參會方提供線上面對面溝通平臺，它把人們從辦公室中解放出來，無論參會者身處何方，使用任何終端入會，都能夠輕松愉悅地聊天討論。

隨著云會議場景不斷豐富，會議需求愈加復(fù)雜，遠(yuǎn)程溝通日趨頻繁的當(dāng)下，原有服務(wù)平臺系統(tǒng)已難以支撐日益增加的業(yè)務(wù)需求，全時對云會議服務(wù)系統(tǒng)進(jìn)行了升級優(yōu)化。

突破原有平臺瓶頸

滿足持續(xù)增長的用戶和業(yè)務(wù)需求

全時云會議平臺包含網(wǎng)絡(luò)會議跟電話會議兩部分，每天有數(shù)十萬用戶基于此平臺召開遠(yuǎn)程視頻會議，不過隨著不斷增長的用戶和業(yè)務(wù)需求，原有會議平臺架構(gòu)服務(wù)之間高度耦合、相互依賴、部分業(yè)務(wù)出現(xiàn)故障……都會導(dǎo)致整個平臺服務(wù)不穩(wěn)定，業(yè)務(wù)快速迭代能力變差，再加上有部分核心服務(wù)一直單點運行，在性能和穩(wěn)定性上出現(xiàn)多處性能瓶頸，給全時的運營帶來了不小挑戰(zhàn)。

最明顯體現(xiàn)在跨地區(qū)/跨國會議上，當(dāng)入會方太龐大數(shù)據(jù)壓力太大令線路突然中斷，就會令場面十分尷尬。

為了支撐快速增長的用戶和會議業(yè)務(wù)需求，實現(xiàn)遠(yuǎn)程多方入會的方便與穩(wěn)定，提升會議質(zhì)量，全時云平臺開始了一次大規(guī)模的分布式以及服務(wù)化改造升級，從根本上解決了數(shù)據(jù)服務(wù)單點化、各個服務(wù)器之間數(shù)據(jù)不共享、模塊之間耦合度偏大等問題。

云平臺架構(gòu)全新升級

化繁為簡 分而治之

為了突破這個瓶頸，新版云會議平臺對整個架構(gòu)做了比較大的調(diào)整優(yōu)化，對各個業(yè)務(wù)服務(wù)模塊之間化繁為簡分而治之，并通過負(fù)載均衡技術(shù)對部分核心業(yè)務(wù)去除單點，集群化運行，易于擴展，在性能穩(wěn)定性以及業(yè)務(wù)快速迭代能力上做了較大優(yōu)化。

全時云服務(wù)化分布式會議平臺的整體技術(shù)架構(gòu)

在服務(wù)之間的通訊方面，由于會議平臺業(yè)務(wù)服務(wù)目前使用的開發(fā)語言較多，有基于C++開發(fā)的服務(wù)（例如音視頻），基于JAVA或Go開發(fā)的API服務(wù)等。而我們主要采用RPC和MQ結(jié)合的方式，統(tǒng)一使用Thrift協(xié)議，并把集群服務(wù)之間的通信模式統(tǒng)一抽象為請求-響應(yīng)、發(fā)布-訂閱、管道-通信三種模式，開發(fā)底層公共通信模塊庫（tang-mq），在底層對集群間的通信進(jìn)行統(tǒng)一管理，簡化上層服務(wù)通信邏輯。

共享緩存使用Redis Cluster，開發(fā)該模式下支持pipeline等操作的tang-cache庫，并對業(yè)務(wù)數(shù)據(jù)模型進(jìn)行統(tǒng)一的抽象和邏輯簡化整理，結(jié)合新的通訊模塊，對各各服務(wù)進(jìn)行了比較好的解耦，使用客戶端負(fù)載均衡的方式實現(xiàn)部分核心服務(wù)如會議業(yè)務(wù)服務(wù)（會議管理以及傳輸管理）的集群化支持。

對單場會議、單個服務(wù)、單個業(yè)務(wù)以及整個服務(wù)實施不同的限流降級策略，會議信令根據(jù)優(yōu)先級分成不同的等級，使用漏桶限流算法，對于觸發(fā)不同等級限流閾值的情況實施不同的策略，進(jìn)行降級熔斷處理，精細(xì)化控制，以增加整體服務(wù)的穩(wěn)定性，防止因單場會議或單個服務(wù)業(yè)務(wù)異常觸發(fā)雪崩效應(yīng)，導(dǎo)致其他會議甚至整個服務(wù)不穩(wěn)定。

對于錄制，混音等消耗計算資源比較大的服務(wù)，定時上報資源使用率，優(yōu)化分配和切換算法，支持動態(tài)擴容縮容，增加服務(wù)的穩(wěn)定性和可運維性。

我們是怎么解決的

會議節(jié)點分布式部署

就近接入
會議系統(tǒng)是一個RTC（Real-time Communications）實時音視頻通信系統(tǒng)，網(wǎng)絡(luò)延時、抖動等因素都會對我們的會議質(zhì)量帶來較大的影響，所以我們采用“就近接入”策略選擇最優(yōu)會議節(jié)點，減少網(wǎng)絡(luò)延遲、抖動。

數(shù)據(jù)采集
客戶端: 服務(wù)器會根據(jù)一些策略（就近接入）結(jié)合當(dāng)時服務(wù)容量或者負(fù)載情況，下發(fā)一系列的服務(wù)器IP地址列表，客戶端自身會根據(jù)一定的算法對這些服務(wù)ip地址進(jìn)行測速，并將網(wǎng)絡(luò)類型，比如（WIFI，2/3/4G）；訪問目標(biāo)服務(wù)時的測速數(shù)據(jù)（IO次數(shù)，每次IO字節(jié)和耗時，RTT估算值等）和服務(wù)質(zhì)量數(shù)據(jù)將一并生成記錄上傳到后端大數(shù)據(jù)中心。
服務(wù)器: 服務(wù)器這邊采集接入IP歸屬，比如電信，聯(lián)通，移動，海外及其所屬省市；用戶開會的規(guī)模，同一個會中所有參會人的分布情況，語音接入VoIP，PSTN的占比等等數(shù)據(jù)上傳到后端大數(shù)據(jù)中心。
大數(shù)據(jù)中心基于采集的數(shù)據(jù)，通過規(guī)則對用戶打上各種標(biāo)簽，生成用戶畫像，智能選擇最優(yōu)鏈路上的會議節(jié)點，最終提供給用戶最優(yōu)的體驗。

混合部署
有很多客戶有自己的私有云，他們的需求是將會議系統(tǒng)部署到他們企業(yè)內(nèi)部，這就是混合部署。隨著混合部署需求的越來越多，問題主要集中在資源、部署跟維護(hù)上。目前全時云提供了一套輕部署方案, 部署一個會議節(jié)點即可加入全時云開會，但媒體流包括錄制等重要文件都在企業(yè)內(nèi)部，這樣就保證了絕對的安全跟私密性。

分布式整體架構(gòu)圖

電話會議優(yōu)先

優(yōu)化電話系統(tǒng)整體可用性

近些年來，隨著業(yè)務(wù)需求的發(fā)展，如何更有效的進(jìn)行公司內(nèi)部、公司跟客戶/供應(yīng)商之間的溝通，成為困擾很多公司的問題，隨之興起的遠(yuǎn)程溝通會議系統(tǒng)，也從最開始簡單的多方電話模式，演進(jìn)到異地多方接入、網(wǎng)絡(luò)會議融合等模式。

電話會議目前面臨的主要需求和問題

全時電話會議系統(tǒng)，上線至今服務(wù)過幾百萬電話用戶，面對用戶規(guī)模的持續(xù)增長，全時歷經(jīng)幾次大的架構(gòu)改進(jìn)，目前已形成一套高可用可擴展的電話會議系統(tǒng)， 以下是全時云服務(wù)分布式會議平臺電話會議系統(tǒng)目前的架構(gòu)：
這個架構(gòu)目前也正處在不斷演進(jìn)的過程中，除了最基礎(chǔ)的核心功能單元之外，我們在電話會議的分布式管理、會議/線路監(jiān)控切換、多地同一會議接入、會議/電話實時監(jiān)控等方面也做了優(yōu)化工作，保證電話會議服務(wù)的整體可用和穩(wěn)定。
電話服務(wù)分布式管理：全時采用多運營商、多地區(qū)相結(jié)合的方式接入線路，在地域電話路由服務(wù)中增加線路監(jiān)控、負(fù)載監(jiān)控，之后統(tǒng)一加入多電話會議服務(wù)中心，并采用優(yōu)化過的負(fù)載算法及健康檢查服務(wù)，當(dāng)?shù)赜蚍?wù)和電話服務(wù)中心線路不穩(wěn)定的情況出現(xiàn)時，電話服務(wù)中心就能動態(tài)切換會議呼入線路，讓線路不穩(wěn)定問題的影響削減到最小。多區(qū)接入同一會議：在國內(nèi)及國外進(jìn)行分布式多點部署，就能夠讓接入方就近匹配站點，實現(xiàn)多地就近呼入同一場會議。異地節(jié)點之間的動態(tài)互聯(lián)則采用專線+多路線路優(yōu)化的方式，能夠使音頻延遲及音頻傳輸質(zhì)量達(dá)到最高級別。會議/電話實時監(jiān)控：實時監(jiān)控各服務(wù)中心及硬件資源情況，以實現(xiàn)動態(tài)預(yù)警，使軟件服務(wù)及會議硬件資源能動態(tài)負(fù)載，資源負(fù)載小的組，可以動態(tài)承載移接過來的會議，當(dāng)總體資源預(yù)警時，服務(wù)資源能夠及時有效得到擴充。對內(nèi)接口及服務(wù)：根據(jù)服務(wù)功能級別，定義HTTP及RPC（TCP）級別接口，使用Nginx或LVS等實現(xiàn)負(fù)載均衡，同時提供對外MQ級別的事件通知機制，外部服務(wù)按需調(diào)取相關(guān)數(shù)據(jù)，對電話核心服務(wù)提供保護(hù)。
未來為適應(yīng)應(yīng)用多樣化需求，全時云會議將集成接入各種應(yīng)用端包括插件的呼入呼出，承載更多電話接入方，使云會議服務(wù)更加穩(wěn)定，我們的服務(wù)可用性SLA高達(dá)4個9以上的級別。

資源監(jiān)控與統(tǒng)計分析
傳統(tǒng)對機器資源的監(jiān)控、進(jìn)程的監(jiān)控方式已滿足不了日益精細(xì)化的管理需求，我們需要對會議信令進(jìn)行更細(xì)化的監(jiān)控和統(tǒng)計分析，以便及時發(fā)現(xiàn)系統(tǒng)設(shè)計或者業(yè)務(wù)邏輯可能存在的問題，比如在業(yè)務(wù)服務(wù)、入口管理、數(shù)據(jù)鏈路層及消息中間件等多處地方進(jìn)行分析，查看各種信令數(shù)據(jù)是否異常，包括監(jiān)測單個會議是否正常、入口調(diào)用超時/TPS分析、客戶端數(shù)據(jù)鏈路數(shù)據(jù)狀態(tài)等。

實際使用時，除了常規(guī)的監(jiān)控以外，我們選用了業(yè)界比較流行的ELK+FileBeat等組合工具，對于某些業(yè)務(wù)的分析，采用自建數(shù)據(jù)模型+自主實現(xiàn)的方式，讓產(chǎn)生的數(shù)據(jù)統(tǒng)一輸出到ELK；對MQ中流轉(zhuǎn)的會議信令采用對正常業(yè)務(wù)影響較小的方式，從MQ中新增加一組消息分析業(yè)務(wù)，橫向縱向?qū)Ρ确治鰳I(yè)務(wù)服務(wù)數(shù)據(jù)，以便于在服務(wù)器或客戶端版本的更新迭代中提前發(fā)現(xiàn)并解決問題。