引言

云計算的出現為企業(yè)的管理、業(yè)務開展、資源整合等帶來了極大的便利性，也是數字化建設的核心基建之一。而高可用性和穩(wěn)定性是衡量一家云服務廠商最核心的標準之一。

環(huán)信作為全球領先的互聯網消息云服務商，提供全面SLA 99.95%的全球公有云方 案，以及SLA99.99% 的全球專有云方案。如何做好全球網絡服務支撐，構建超低 延時的SD-GMN 網絡，保持全球用戶100毫秒以內的最佳用戶體驗。本次將向您講述服務背后的技術故事，包括環(huán)信全球實時消息網絡的的整體規(guī)劃、運維監(jiān)測和服務、技術迭代以及持續(xù)優(yōu)化。

目錄

一、全球實時消息網絡的主要挑戰(zhàn)

二、環(huán)信全球實時消息網絡整體規(guī)劃

三、運維監(jiān)測和服務

四、擁抱邊緣計算和持續(xù)迭代優(yōu)化

五、結語

一、全球實時消息網絡的主要挑戰(zhàn)

環(huán)信作為國內最早提供全球消息云服務的廠商，在提供全球實時消息網絡方面面臨諸多挑戰(zhàn)，  主要包括新興市場國家基礎設施差、延時高， 以及 DNS 錯誤等問題。其中，消息的到達率和消息的延遲是最重要的核心指標之一。

面對國內用戶的時候，基于國內的 5G 基礎設施的領先性，消息延遲基本不算問題， 國內整體網絡延時整體可控。根據數據統(tǒng)計顯示：“國內最慢的重慶市時延中值 84ms，那收發(fā)消息單次往返就是 84ms，再加上幾十毫秒的服務器處理時間，整體 時間控制在 100ms 左右，用戶幾乎感受不到延遲帶來的交互問題?！?/p>

以上數據來自 speedtest.cn

早在2014年當環(huán)信向海外客戶提供服務之時，受制于國外網絡基礎設施良莠不齊， 我們會發(fā)現海外的整體網絡延遲差異巨大，無法跟國內一樣通過部署3線、8 線 bgp 的機房就能基本可用，或者使用自己攢的多線機房方案。環(huán)信全球實時消息定義我們 收發(fā)的消息每次延時都是在 1s 內，一旦超過 1s 我們就會感覺到有明顯的延遲。因此 我們的目標就是單個客戶端發(fā)送消息到達服務器端不能超過 100ms。最終這個問題就演變成了我們在面對海外網絡的情況下如何進行解決處理來達到這個標準。

以上數據來自

https://www.cable.co.uk/broadband/world-wide-speed-league/2022/worldwide_speed_league_data.xlsx

從上面數據雖然無法看出各個國家的手機網絡延時，以及由于某些國家的網絡出口原 因導致結果并不完全準確，但是大體上我們可以看出來網絡慢的都是一些新興市場的 國家和地區(qū)。這些地區(qū)主要是非洲、南美、中亞以及西亞等地區(qū)。

我們再來計算一下網絡的傳輸速率，由于國際網絡基本都是光纖來進行傳遞的。光纖 延時計算：t=n*L/c，c 為光速，其中光速約為 c=30 萬公里 / 秒；光纖的材料是二氧 化硅，其折射率 n 為 1.44 左右，計算延遲的時候可以近似認為1.5。我們用這個公式可以計算下北京到上海的延遲:最快就是 11ms 往返。但是實際情況可能就是這個數 字要乘以 2或乘以 3的數值。因為這里會有各個路由節(jié)點的損耗，以及光纖從北京到 上?？赡懿⒉皇侵本€，而比如中美海底光纜這樣的，由于有標注整體的長度，因此很 容易計算整體延時。

以下這個網站是根據 Wikipedia 整理的現在已有和在建的海底光纜。這里我們可以比 較清楚的看到，  國際光纜主要是在亞洲和北美之間的太平洋，北美和歐洲之間的大西 洋。(數據來源參考網址：

  https://cablemap.info/_default.aspx )

現在，我們已經找到了核心問題，同時定義好了目標，那就擼起袖子加油干吧！

從以上信息中我們可以看到，我們需要解決的是三個問題：

• - 更近的數據中心

• - 非發(fā)達國家的 Last mile 優(yōu)化

• - 路徑選擇

最后我們也將介紹一下聲網環(huán)信集團的網絡基礎設施矩陣。

二、環(huán)信全球實時消息網絡整體規(guī)劃

第一：更近的數據中心

因為所有網絡傳輸的延時最終都是跟光纖距離有關，所以我們需要將數據中心盡可能 的離用戶更近。于是我們分別在北美、歐洲、東南亞選取了 3 個地點作為海外的核心 數據中心，分別覆蓋各自本地的區(qū)域。非洲地區(qū)因為歷史原因，非洲國家的出口網絡 很多都是繞道英國、法國這些發(fā)達國家。

有一種聲音認為代理也可以解決，可是代理并不能解決實際數據傳輸的距離問題，只 能是提升網絡的穩(wěn)定性。

因此我們在出海的選擇上就選擇了如下幾個區(qū)域：

• 新加坡：覆蓋東南亞、東亞、南亞、非地中海區(qū)域的西亞國家、南非、大洋洲

• 德國：覆蓋歐洲、西亞、北非、東非、西非、中亞

• 美國 : 覆蓋北美、南美

基本上環(huán)信數據中心到這些地區(qū)都控制在 10000里以內，這樣往返加上 Last mile 的速度，基本上單程收或發(fā)消息的中值我們可以控制在100ms 內。

新加坡數據中心主要覆蓋的地區(qū)：

德國數據中心覆蓋的地區(qū)：

美國數據中心覆蓋的地區(qū):

環(huán)信全球實時消息網絡 SD-GMN 實測數據展示：

第二: Last mile優(yōu)化

這里分為兩個問題點：

一個是本地跨運營商的，比如印度當地基本上每個邦都有自己的運營商，比較好的是他們基本都跟 AWS 這些大的運營商進行 IX(Internet Exchange Point，互聯網交 換)。但問題點是一旦超過 IX 的容量就會產生擁塞。

環(huán)信的 IM SDK 不光使用 AWS GA 這些服務，同時也使用自己的 FPA(終端網絡加速) 方案。而 FPA 使用的方式是在主要的邦都使用本地的運營商來進行接入，這樣在網絡 高峰時期會更可靠，畢竟 IX 通常的帶寬上限都不太高。

另外一個問題點是手機網絡的不穩(wěn)定性。這個問題在一些新興市場國家中尤為明顯。而  FPA 可以有效的進行弱網對抗，有效的避免了終端網絡不穩(wěn)定性。同時 FPA 也提 供了水晶球的展示，這樣方便觀測來自各個地區(qū)，各個運營商的接入情況。

第三: 路徑選擇

路徑選擇分為兩步：

1、找到離用戶最快的接入地址

這個我們可以看到很多友商都會使用智能 DNS 這樣的方式來進行處理。這樣的準 確性并不太高。這里主要會產生如下問題。

• - 用戶自定義 DNS Server 跟他自己的運營商不匹配，雖然現在 bind 有擴展是支持傳遞用戶 IP 的，但是還是有很多 DNS Server 是不支持的。

• - 有些 DNS Server 地址對于智能 DNS 服務提供商會有誤判。

• - DNS 解析本身耗時。

環(huán)信首先會使用實際出口的 IP 來進行作為判斷依據，因此我們全球部署了上百個 邊緣的解析節(jié)點保證就近接入。這些解析不光是按照運營商，地域這些來進行分 配地址，同時也會根據 RTT，傳輸大小來進行智能的調配。

同時為了解決一些新興市場國家弱網的情況，我們同時支持 tcp 和 udp 不同的方 式來進行獲取。

2、支持多條路徑

環(huán)信 IM SDK 支持多種路徑選擇，于是產生了路徑選擇的問題。前期在環(huán)信IM SDK 里其實默認包含了

3 種路徑，包括直連、GA、FPA 這 3 種不同的方案，后期我們也將增加新的鏈路路徑。

比如我們很多友商都是接入了 AWS GA，AWS 也顯示了他們 102 個加速節(jié)點的地址。但是我們也看到了這里有一些不合理的地方。比如我們前面列的那些網絡速度慢的 地區(qū)，AWS 基本沒有做覆蓋，作為創(chuàng)業(yè)公司在前期可以正常使用可能問題不明顯, 但 對于真正要面向全球化的公司后期就有點力不從心了。

就算用 Azure 和 google cloud platform 也是一樣，這幾家主要覆蓋歐美、日 韓和新加坡地區(qū)。而這些區(qū)域其實就算直連，它們的網絡延時也都挺好。

下面這個是 AWS GA 網絡加速節(jié)點：

除了 AWS GA，還有一些廠商在新興市場國家擁有更多的節(jié)點：

環(huán)信相對于友商的核心優(yōu)勢是除了會用到這些公有云廠商的節(jié)點，我們也使用自建的 Agora FPA 網絡，我們自建的終端加速網絡覆蓋了全球 230 多個國家和地區(qū)。當我們 SDK 支持多條路徑選擇的時候，我們就需要有相應的路徑選擇能力，這些能力使我們 掌握了更多的調度主動權。

但這些都是需要我們有足夠的數據來支撐和驗證 :

• - 我們使用了 250+ 的 FPA 節(jié)點來采集延遲數據。

• - 用戶主動上報來的延遲數據。 

我們也建立了全球 250+ 節(jié)點的監(jiān)測網絡，這樣從全球 200 個國家到我們核心機房的 延時和丟包率我們都可以做到實時監(jiān)測，這些數據將作為我們鏈路調度的核心依據。

在 2022 年上半年的時候，太平洋海底爆發(fā)了地震，導致從南美到新加坡的海底光纜 出現了異常。當時環(huán)信的監(jiān)控系統(tǒng)迅速的發(fā)現了這個異常情況，我們就迅速的切換了 南美到新加坡的路徑，不從太平洋走，而是改道歐洲，再到亞洲。這樣雖然整體的延 時提高了，但是根據監(jiān)控和客戶反饋幾乎沒有發(fā)生丟包現象。

我們也同時迅速報告了相關的大運營商，他們也很快的修改了整個路由走向，大家都 是一樣犧牲了延時來保證了穩(wěn)定性。

在 2022 年下半年，某海外運營商從歐洲到新加坡突然完全不可用，而當時很多使用 了我們多鏈路的客戶就基本沒有影響，只是有可能在第一次連接的時候產生失敗后會 立刻重試后面的鏈路，保證了整體服務的可用性。我們也立刻告知了大運營商，但是 這次運營商由于對端鏈路宣告的原因一直過了 1 個多小時才恢復。

綜上所述，如何來調度顯得至關重要，網絡調度里最核心的部分就是延遲和丟包，而 延遲主要是由路由走向來決定的。

環(huán)信通過建立了對應的監(jiān)測節(jié)點來監(jiān)測主干網絡的情況。通常情況下，來的路由和去 的路由走向是不一樣的，所以通過使用 fping 來 ping 全球所有的網段，這種結果并 不完全準確，最后我們通過模擬客戶網絡來  ping 過來會更準確，這樣就完成雙向的 路由統(tǒng)計，同時我們也會使用用戶上報的方式來查看各個網段情況。

第四：基礎設施矩陣，機房全球分布、五地三中心資源覆蓋

基礎資源選點：集團 SD-RTN? 在全球部署了 250+ 數據中心，覆蓋全球 200多個國 家與地區(qū)，對于主要區(qū)域的最低要求是五地三中心的資源覆蓋，每個區(qū)域采用核心節(jié)點 +POP 點的方式。這樣一旦某區(qū)域其中一個或兩個機房發(fā)生故障，依靠技術可以將 故障城市的流量全部切換到運行正常的機房。

供應鏈管理:不依賴單家供應商的基礎資源 ( 包括:機房、硬件、網絡等 )，當一家 供應商出現問題，可以快速切換到其他服務正常的供應商。

眾所周知，基礎設施會因為突發(fā)的網絡擁塞、硬件故障、不可抗力等因素導致或大或 小的一段時間的不可用。在這樣的前提下，集團 SD-RTN? 大網的架構師團隊從設計 之初就充分考慮到了基礎設施的不穩(wěn)定因素。如果要用幾個關鍵詞來描述 SD-RTN? ， 那就是全球覆蓋、故障實時感知與智能調度、超低延時、彈性能力、異地多活、超高 并發(fā)，而一旦基礎設施出現故障，SD-RTN? 的故障實時感知與智能調度能力以及異 地多活的構建方式將發(fā)揮重要作用，保障服務的高可用。

1、故障實時感知與智能調度：從全球來看，公網網絡的波動是較為頻繁的， SD-RTN? 的網絡嗅探服務能夠實時的感知網絡的質量，結合 AI Ops ( 智能運維 ) 的分析能力，能夠實現分鐘級的用戶遷移，保障用戶的音視頻體驗。

2、異地多活：  SD-RTN? 大網將全球資源劃分為多個 Region ( 區(qū)域 )，在 Region 內依然能夠做到最低 N+3 ( 即：在最大的 3 個資源集群不可用的情況下，剩余的 資源依然能夠承接當前 Region 的負載 ) 資源冗余的要求，不僅如此，Region 之 間依然能夠形成互補的態(tài)勢，某個 Region 故障時，可以通過互補 Region 進行 承接。

3、靈活的彈性擴縮容能力：  SD-RTN? 大網的每個 Region 至少具備 200% 的實時 彈性擴縮容能力，具備應對突發(fā)事件的能力，配合智能調度能夠充分合理的進行資 源使用。

三、運維監(jiān)測和服務

隨著微服務化的浪潮，運維復雜度在迅速增加，傳統(tǒng)運維已經捉襟見肘，為此，環(huán)信 投入了巨大的資源和人力解決了傳統(tǒng)運維的痛點，從運維監(jiān)測的角度來看，我們主要 從以下幾個方面來梳理:

1. 從最終的效果來作為評判標準，選取業(yè)務上最核心的指標

1.1 用戶連接 5 秒失敗率。

1.2 用戶收發(fā)消息 1 秒失敗率。

1.3 在線用戶數。

1.4 在線消息數。

1.5 以上數據再通過運營商，國家地區(qū)等多種維度來進行分類。

2. 梳理收發(fā)消息的完整調用鏈

但是隨著業(yè)務越來越復雜，基礎組件也越來越多，微服務化又會導致現在單個 api 的整體調用鏈會非常冗長。而由于虛擬化、容器化，導致現在的網絡問題點也是越 來越多，運維在做研發(fā)評審的時候也要重點關注。

因此我們一般分為網絡監(jiān)控，基礎監(jiān)控和調用鏈的監(jiān)控。

2.1 網絡監(jiān)控

我們需要確定各個節(jié)點之間的延時和丟包率，以及帶寬的使用率，這個是需要 做到秒級。

- 內部延時和丟包，這里要特別注意要區(qū)分好物理層網絡的丟包延時以及虛擬容 器層網絡的丟包和延時。

- 外部網絡供應商的延時和丟包。這個在監(jiān)控的時候要注意區(qū)分大小包以及不同的協議。對于有多個運營商組成起來的線路，最好是分段去監(jiān)測，這樣后期可以快速判斷。

2.2 基礎監(jiān)控

- 服務器級別，操作系統(tǒng)級別。這里需要注意的是 Linux 有些監(jiān)控指標我們需要多個角度去判斷。

- 基 礎 組 件 級 別 監(jiān) 控，包 括 Redis、 tendis、 kafka、 rabbitmq、 nginx、 haproxy、consul 等 等，得 益 于 整 個 prometheus 的 生 態(tài) 非 常 好，都 有 對 應 的 exporter 來監(jiān)控。但是其實問題不是在監(jiān)控，  而是在部署架構上就需要考 慮好高可用和快速的擴縮容上。

- 應用服務自身的 qps，  負載，jvm，  以及內部邏輯核心指標的上報接口的采集 和監(jiān)控。

2.3 調用鏈監(jiān)控

- 需要有一個統(tǒng)一的 traceid 來覆蓋整個調用流程。

- 調用流程需要包含 connect、read、response 的時間，以及請求次數。

- 要進行抽樣，但是要保證單一鏈條完整性。

3. 第三方撥測

3.1 從外部角度來模擬監(jiān)控。

3.2 覆蓋多種場景和地域。

4. 全時區(qū)服務

針對不同時區(qū)客戶的需求，環(huán)信建立了全時區(qū)運維保障團隊，7*24H 值班，及時 處理和反饋。并在印度、美國和國內建立了一支英文的技術專家團隊，為海外客戶 提供英文的技術和方案支持。

四、擁抱邊緣計算和持續(xù)迭代優(yōu)化

1. 真正的邊緣計算

相對于傳統(tǒng)的管理方便的數據中心，環(huán)信正在利用邊緣計算來持續(xù)優(yōu)化網絡服務。我們看到了諸如 Mastodon 這些項目，就是從一個星形的網絡架構變成一個網狀的網絡架構。這樣對于最終用戶的收發(fā)消息的延時就會有極大的提高。舉個例子，原 先一個阿根廷的用戶發(fā)送消息到阿根廷的用戶，網絡上會匯總到美國集群，然后再 分發(fā)下來。這樣整個延時就得 200ms 以上了。但是如果是一個網狀架構，那它可 能就是使用阿根廷的邊緣節(jié)點就直接傳輸了。

但這并不是說不需要中心端了，  中心端會依舊保留，包括一些管理功能，離線功能 等。在邊緣計算的實踐方面最近環(huán)信在和國內某頭部運營商相關項目上做了一些非 常重大的落地。

2. 自動化運維

如今行業(yè)都有一個共識，即運維復雜度在迅速增加，然而傳統(tǒng)運維已經捉襟見肘， 為此，環(huán)信持續(xù)迭代整個監(jiān)控和報警系統(tǒng)。從早期的 Ganglia、nagios、zabbix 搭配 opentsdb、in?uxdb，到現在的 Prometheus 一統(tǒng)天下。

為了解決傳統(tǒng)運維的痛點：7*24H 不間斷保障 ; 高一致性和高質量的執(zhí)行結果 ; 統(tǒng) 一高效的運維效率。環(huán)信引入了 stackstorm  自動化執(zhí)行框架來保證常見的故障可 以自動化高一致性的處理完成。

同時，我們投入了巨大的資源和人力在 AIOps 的落地上。AIOps ( 智能運維 ) 能在1分 鐘 之 內 ( 包 含 了 數 據 聚 合 、上 報 、判 斷 、執(zhí) 行 、恢 復 等 整 體 端 到 端 時 間 ) 識 別 機 房 異 常并且自動運維。我們在具體實現中主要是快速識別問題點，這個原先是非常依賴業(yè) 務運維人員的經驗，以前我們內部統(tǒng)計的時候就發(fā)現找到問題原因平均時間為10多 分鐘，而現在真正處理故障或者規(guī)避故障在幾分鐘內就能迅速完成。

五、結語

目前環(huán)信已經服務了 30 多萬家國內用戶和數百家海外頭部客戶，作為 2013 年國內最早的即時通訊云服務商，我們早在 2014 年就最先在硅谷設立了團隊提供海外服務支持，環(huán)信國內和海外用戶積累以及技術口碑的建立與我們的持續(xù)技術迭代優(yōu)化息息相關。

“寫代碼，是一件愉快的事”，這不僅是環(huán)信官網上的一句 slogan，也是環(huán)信在成功 路上不可缺少的一種特質。對于環(huán)信的團隊來說，技術的創(chuàng)新不僅僅是一份工作、一 個 KPI，更是一種理想追求。日拱一卒無有盡，環(huán)信一直在為了用戶體驗努力前進！

（免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）