默認
打賞 發表評論 0
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐
閱讀(4250) | 評論(0 收藏2 淘帖1 1

本文由馬蜂窩技術團隊電商交易基礎平臺研發工程師"Anti Walker"原創分享,原文鏈接見文末。


一、引言


即時通訊(IM)功能對于電商平臺來說非常重要,特別是旅游電商。

從商品復雜性來看,一個旅游商品可能會包括用戶在未來一段時間的衣、食、住、行等方方面面。從消費金額來看,往往單次消費額度較大。對目的地的陌生、在行程中可能的問題,這些因素使用戶在購買前、中、后都存在和商家溝通的強烈需求。可以說,一個好用的 IM 可以在一定程度上對企業電商業務的 GMV 起到促進作用。

本文我們將結合馬蜂窩旅游電商IM系統的發展歷程,單獨介紹基于Go重構分布式IM系統過程中的實踐和總結本文相當于《從游擊隊到正規軍(一):馬蜂窩旅游網的IM系統架構演進之路》一文的進階篇),希望可以給有相似問題的朋友一些借鑒。

另外:如果你對Go在高并發系統中的應用感興趣,即時通訊網的以下兩篇也值得一讀:


系列文章:


關于馬蜂窩旅游網:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_202441mfyfm2gcf2fw3jef.jpg

馬蜂窩旅游網是中國領先的自由行服務平臺,由陳罡和呂剛創立于2006年,從2010年正式開始公司化運營。馬蜂窩的景點、餐飲、酒店等點評信息均來自上億用戶的真實分享,每年幫助過億的旅行者制定自由行方案。


二、相關文章


三、技術背景和問題


與廣義上的即時通訊不同,電商各業務線有其特有業務邏輯,如客服聊天系統的客人分配邏輯、敏感詞檢測邏輯等,這些往往要耦合進通信流程中。隨著接入業務線越來越多,即時通訊服務冗余度會越來越高。同時整個消息鏈路追溯復雜,服務穩定性很受業務邏輯的影響。

之前我們 IM 應用中的消息推送主要基于輪詢技術,消息輪詢模塊的長連接請求是通過 php-fpm 掛載在阻塞隊列上實現。當請求量較大時,如果不能及時釋放 php-fpm 進程,對服務器的性能消耗很大。

為了解決這個問題,我們曾用 OpenResty+Lua 的方式進行改造,利用 Lua 協程的方式將整體的 polling 的能力從 PHP 轉交到 Lua 處理,釋放一部 PHP 的壓力。這種方式雖然能提升一部分性能,但 PHP-Lua 的混合異構模式,使系統在使用、升級、調試和維護上都很麻煩,通用性也較差,很多業務場景下還是要依賴 PHP 接口,優化效果并不明顯。

為了解決以上問題,我們決定結合電商 IM 的特定背景對 IM 服務進行重構,核心是實現業務邏輯和即時通訊服務的分離。

更多有關馬蜂窩旅游網的IM系統架構的演進過程,請詳讀:《從游擊隊到正規軍(一):馬蜂窩旅游網的IM系統架構演進之路》一文,在此不再贅述。

四、基于Go的雙層分布式IM架構


4.1、實現目標


1)業務解耦:

將業務邏輯與通信流程剝離,使 IM 服務架構更加清晰,實現與電商 IM 業務邏輯的完全分離,保證服務穩定性。

2)接入方式靈活:

之前新業務接入時,需要在業務服務器上配置 OpenResty 環境及 Lua 協程代碼,非常不便,IM 服務的通用性也很差。考慮到現有業務的實際情況,我們希望 IM 系統可以提供 HTTP 和 WebSocket 兩種接入方式,供業務方根據不同的場景來靈活使用。

比如已經接入且運行良好的電商定制化團隊的待辦系統、定制游搶單系統、投訴系統等下行相關的系統等,這些業務沒有明顯的高并發需求,可以通過 HTTP 方式迅速接入,不需要熟悉稍顯復雜的 WebSocket 協議,進而降低不必要的研發成本。

3)架構可擴展:

為了應對業務的持續增長給系統性能帶來的挑戰,我們考慮用分布式架構來設計即時通訊服務,使系統具有持續擴展及提升的能力。

4.2、語言選擇


目前,馬蜂窩技術體系主要包括 PHP,Java,Golang,技術棧比較豐富,使業務做選型時可以根據問題場景選擇更合適的工具和語言。

結合 IM 具體應用場景,我們選擇 Go 的原因包括:

  • 1)運行性能:在性能上,尤其是針對網絡通信等 IO 密集型應用場景。Go 系統的性能更接近 C/C++;
  • 2)開發效率:Go 使用起來簡單,代碼編寫效率高,上手也很快,尤其是對于有一定 C++ 基礎的開發者,一周就能上手寫代碼了。

4.3、架構設計


整體架構圖如下:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_1.jpg

名詞解釋:

  • 1)客戶:一般指購買商品的用戶;
  • 2)商家:提供服務的供應商,商家會有客服人員,提供給客戶一個在線咨詢的作用;
  • 3)分發模塊:即 Dispatcher,提供消息分發的給指定的工作模塊的橋接作用;
  • 4)工作模塊:即 Worker 服務器,用來提供 WebSocket 服務,是真正工作的一個模塊。

架構分層:

  • 1)展示層:提供 HTTP 和 WebSocket 兩種接入方式;
  • 2)業務層:負責初始化消息線和業務邏輯處理。如果客戶端以 HTTP 方式接入,會以 JSON 格式把消息發送給業務服務器進行消息解碼、客服分配、敏感詞過濾,然后下發到消息分發模塊準備下一步的轉換;通過 WebSocket 接入的業務則不需要消息分發,直接以 WebSocket 方式發送至消息處理模塊中;
  • 3)服務層:由消息分發和消息處理這兩層組成,分別以分布式的方式部署多個 Dispatcher 和 Worker 節點。Dispatcher 負責檢索出接收者所在的服務器位置,將消息以 RPC 的方式發送到合適的 Worker 上,再由消息處理模塊通過 WebSocket 把消息推送給客戶端;
  • 4)數據層:Redis 集群,記錄用戶身份、連接信息、客戶端平臺(移動端、網頁端、桌面端)等組成的唯一 Key。

4.4、服務流程


步驟一:

如上圖右側所示:

  • 用戶客戶端與消息處理模塊建立 WebSocket 長連接;
  • 通過負載均衡算法,使客戶端連接到合適的服務器(消息處理模塊的某個 Worker);
  • 連接成功后,記錄用戶連接信息,包括用戶角色(客人或商家)、客戶端平臺(移動端、網頁端、桌面端)等組成唯一 Key,記錄到 Redis 集群。

步驟二:

如圖左側所示,當購買商品的用戶要給管家發消息的時候,先通過 HTTP 請求把消息發給業務服務器,業務服務端對消息進行業務邏輯處理。

1)該步驟本身是一個 HTTP 請求,所以可以接入各種不同開發語言的客戶端。通過 JSON 格式把消息發送給業務服務器,業務服務器先把消息解碼,然后拿到這個用戶要發送給哪個商家的客服的。

2)如果這個購買者之前沒有聊過天,則在業務服務器邏輯里需要有一個分配客服的過程,即建立購買者和商家的客服之間的連接關系。拿到這個客服的 ID,用來做業務消息下發;如果之前已經聊過天,則略過此環節。

3)在業務服務器,消息會異步入數據庫。保證消息不會丟失。

步驟三:

業務服務端以 HTTP 請求把消息發送到消息分發模塊。這里分發模塊的作用是進行中轉,最終使服務端的消息下發給指定的商家。

步驟四:

基于 Redis 集群中的用戶連接信息,消息分發模塊將消息轉發到目標用戶連接的 WebSocket 服務器(消息處理模塊中的某一個 Worker)

1)分發模塊通過 RPC 方式把消息轉發到目標用戶連接的 Worker,RPC 的方式性能更快,而且傳輸的數據也少,從而節約了服務器的成本。

2)消息透傳 Worker 的時候,多種策略保障消息一定會下發到 Worker。

步驟五:

消息處理模塊將消息通過 WebSocket 協議推送到客戶端。

1)在投遞的時候,接收者要有一個 ACK(應答) 信息來回饋給 Worker 服務器,告訴 Worker 服務器,下發的消息接收者已經收到了。

2)如果接收者沒有發送這個 ACK 來告訴 Worker 服務器,Worker 服務器會在一定的時間內來重新把這個信息發送給消息接收者。

3)如果投遞的信息已經發送給客戶端,客戶端也收到了,但是因為網絡抖動,沒有把 ACK 信息發送給服務器,那服務器會重復投遞給客戶端,這時候客戶端就通過投遞過來的消息 ID 來去重展示。

以上步驟的數據流轉大致如圖所示:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_2.jpg

4.5、系統完整性設計


4.5.1可靠性


(1)消息不丟失:

為了避免消息丟失,我們設置了超時重傳機制。服務端會在推送給客戶端消息后,等待客戶端的 ACK,如果客戶端沒有返回 ACK,服務端會嘗試多次推送。

目前默認 18s 為超時時間,重傳 3 次不成功,斷開連接,重新連接服務器。重新連接后,采用拉取歷史消息的機制來保證消息完整。

(2)多端消息同步:

客戶端現有 PC 瀏覽器、Windows 客戶端、H5、iOS/Android,系統允許用戶多端同時在線,且同一端可以多個狀態,這就需要保證多端、多用戶、多狀態的消息是同步的。

我們用到了 Redis 的 Hash 存儲,將用戶信息、唯一連接對應值 、連接標識、客戶端 IP、服務器標識、角色、渠道等記錄下來,這樣通過 key(uid) 就能找到一個用戶在多個端的連接,通過 key+field 能定位到一條連接。

4.5.2可用性


上文我們已經說過,因為是雙層設計,就涉及到兩個 Server 間的通信,同進程內通信用 Channel,非同進程用消息隊列或者 RPC。綜合性能和對服務器資源利用,我們最終選擇 RPC 的方式進行 Server 間通信。

在對基于 Go 的 RPC 進行選行時,我們比較了以下比較主流的技術方案:

  • 1)Go STDRPC:Go 標準庫的 RPC,性能最優,但是沒有治理;
  • 2)RPCX:性能優勢 2*GRPC + 服務治理;
  • 3)GRPC:跨語言,但性能沒有 RPCX 好;
  • 4)TarsGo:跨語言,性能 5*GRPC,缺點是框架較大,整合起來費勁;
  • 5)Dubbo-Go:性能稍遜一籌, 比較適合 Go 和 Java 間通信場景使用。

最后我們選擇了 RPCX,因為性能也很好,也有服務的治理。

兩個進程之間同樣需要通信,這里用到的是 ETCD 實現服務注冊發現機制。

當我們新增一個 Worker,如果沒有注冊中心,就要用到配置文件來管理這些配置信息,這挺麻煩的。而且你新增一個后,需要分發模塊立刻發現,不能有延遲。

如果有新的服務,分發模塊希望能快速感知到新的服務。利用 Key 的續租機制,如果在一定時間內,沒有監聽到 Key 有續租動作,則認為這個服務已經掛掉,就會把該服務摘除。

在進行注冊中心的選型時,我們主要調研了 ETCDZooKeeperConsul

三者的壓測結果參考如下:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_3.jpg
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_4.jpg

結果顯示,ETCD 的性能是最好的。另外,ETCD 背靠阿里巴巴,而且屬于 Go 生態,我們公司內部的 K8S 集群也在使用。

綜合考量后,我們選擇使用 ETCD 作為服務注冊和發現組件。并且我們使用的是 ETCD 的集群模式,如果一臺服務器出現故障,集群其他的服務器仍能正常提供服務。

小結一下:通過保證服務和進程間的正常通訊,及 ETCD 集群模式的設計,保證了 IM 服務整體具有極高的可用性。

4.5.3擴展性


消息分發模塊和消息處理模塊都能進行水平擴展。當整體服務負載高時,可以通過增加節點來分擔壓力,保證消息即時性和服務穩定性。

4.5.4安全性


處于安全性考慮,我們設置了黑名單機制,可以對單一 uid 或者 ip 進行限制。比如在同一個 uid 下,如果一段時間內建立的連接次數超過設定的閾值,則認為這個 uid 可能存在風險,暫停服務。如果暫停服務期間該 uid 繼續發送請求,則限制服務的時間相應延長。

4.6、性能優化和踩過的坑


4.6.1性能優化


1)JSON 編解碼:

開始我們使用官方的 JSON 編解碼工具,但由于對性能方面的追求,改為使用滴滴開源的 Json-iterator,使在兼容原生 Golang 的 JSON 編解碼工具的同時,效率上有比較明顯的提升。

以下是壓測對比的參考圖:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_5.jpg

2)time.After:

在壓測的時候,我們發現內存占用很高,于是使用 Go Tool PProf 分析 Golang 函數內存申請情況,發現有不斷創建 time.After 定時器的問題,定位到是心跳協程里面。

原來代碼如下:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_6.jpg

優化后的代碼為:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_7.jpg

優化點在于 for 循環里不要使用 select + time.After 的組合。

3)Map 的使用:

在保存連接信息的時候會用到 Map。因為之前做 TCP Socket 的項目的時候就遇到過一個坑,即 Map 在協程下是不安全的。當多個協程同時對一個 Map 進行讀寫時,會拋出致命錯誤:fetal error:concurrent map read and map write,有了這個經驗后,我們這里用的是 sync.Map

4.6.2踩坑經驗


1)協程異常:

基于對開發成本和服務穩定性等問題的考慮,我們的 WebSocket 服務基于 Gorilla/WebSocket 框架開發。其中遇到一個問題,就是當讀協程發生異常退出時,寫協程并沒有感知到,結果就是導致讀協程已經退出但是寫協程還在運行,直到觸發異常之后才退出。

這樣雖然從表面上看不影響業務邏輯,但是浪費后端資源。在編碼時應該注意要在讀協程退出后主動通知寫協程,這樣一個小的優化可以這在高并發下能節省很多資源

2)心跳設計:

舉個例子:之前我們在閑時心跳功能的開發中走了一些彎路。最初在服務器端的心跳發送是定時心跳,但后來在實際業務場景中使用時發現,設計成服務器讀空閑時心跳更好。因為用戶都在聊天呢,發一個心跳幀,浪費感情也浪費帶寬資源。

這時候,建議大家在業務開發過程中如果代碼寫不下去就暫時不要寫了,先結合業務需求用文字梳理下邏輯,可能會發現之后再進行會更順利

3)每天分割日志:

從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_8.jpg

日志模塊在起初調研的時候基于性能考慮,確定使用 Uber 開源的 ZAP 庫,而且滿足業務日志記錄的要求。日志庫選型很重要,選不好也是影響系統性能和穩定性的。

ZAP 的優點包括:
  • 1)顯示代碼行號這個需求,ZAP 支持而 Logrus 不支持,這個屬于提效的。行號展示對于定位問題很重要;
  • 2)ZAP 相對于 Logrus 更為高效,體現在寫 JSON 格式日志時,沒有使用反射,而是用內建的 json encoder,通過明確的類型調用,直接拼接字符串,最小化性能開銷。

小坑:每天寫一個日志文件的功能,目前 ZAP 不支持,需要自己寫代碼支持,或者請求系統部支持。

五、性能表現


壓測 1:

上線生產環境并和業務方對接以及壓測,目前定制業務已接通整個流程,寫了一個 Client。模擬定期發心跳幀,然后利用 Docker 環境。開啟了 50 個容器,每個容器模擬并發起 2 萬個連接。這樣就是百萬連接打到單機的 Server 上。單機內存占用 30G 左右。

壓測 2:

同時并發 3000、4000、5000 連接,以及調整發送頻率,分別對應上行:60萬、80 萬、100 萬、200 萬, 一個 6k 左右的日志結構體。

其中有一半是心跳包 另一半是日志結構體。在不同的壓力下的下行延遲數據如下:
從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐_9.jpg

結論:

隨著上行的并發變大,延遲控制在 24-66 毫秒之間。所以對于下行業務屬于輕微延遲。另外針對 60 萬 5k 上行的同時,用另一個腳本模擬開啟 50 個協程并發下行 1k 的數據體,延遲是比沒有并發下行的時候是有所提高的,延遲提高了 40ms 左右。

六、本文小結


基于 Go 重構的 IM 服務在 WebSocket 的基礎上,將業務層設計為配有消息分發模塊和消息處理模塊的雙層架構模式,使業務邏輯的處理前置,保證了即時通訊服務的純粹性和穩定性;同時消息分發模塊的 HTTP 服務方便多種編程語言快速對接,使各業務線能迅速接入即時通訊服務。

最后,我還想為 Go 搖旗吶喊一下。很多人都知道馬蜂窩技術體系主要是基于 PHP,有一些核心業務也在向 Java 遷移。與此同時,Go 也在越來越多的項目中發揮作用。現在,云原生理念已經逐漸成為主流趨勢之一,我們可以看到在很多構建云原生應用所需要的核心項目中,Go 都是主要的開發語言,比如 Kubernetes,Docker,Istio,ETCD,Prometheus 等,包括第三代開源分布式數據庫 TiDB。

所以我們可以把 Go 稱為云原生時代的母語。「云原生時代,是開發者最好的時代」,在這股浪潮下,我們越早走進 Go,就可能越早在這個新時代搶占關鍵賽道。希望更多小伙伴和我們一起,加入到 Go 的開發和學習陣營中來,拓寬自己的技能圖譜,擁抱云原生。

原文鏈接:https://sa.sogou.com/sgsearch/sgs_tc_news.php?req=KlBwhcVz5sZ0ynR4_0JzmH4zls65LBxeE7NCEuFOpoU=

附錄:更多IM架構設計方面的文章


[1] 有關IM架構設計的文章:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
移動端IM中大規模群消息的推送如何保證效率、實時性?
現代IM系統中聊天消息的同步和存儲方案探討
IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?
IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議
IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token
WhatsApp技術實踐分享:32人工程團隊創造的技術神話
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等
IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
以微博類應用場景為例,總結海量社交系統的架構設計步驟
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐
社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐
社交軟件紅包技術解密(八):全面解密微博紅包技術方案
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途
多維度對比5款主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了
從游擊隊到正規軍(一):馬蜂窩旅游網的IM系統架構演進之路
從游擊隊到正規軍(二):馬蜂窩旅游網的IM客戶端架構演進和實踐總結
IM開發基礎知識補課(六):數據庫用NoSQL還是SQL?讀這篇就夠了!
瓜子IM智能客服系統的數據架構設計(整理自現場演講,有配套PPT)
阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處
>> 更多同類文章 ……

[2] 更多其它架構設計相關文章:
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
達達O2O后臺架構演進實踐:從0到4000高并發請求背后的努力
優秀后端架構師必會知識:史上最全MySQL大表優化方案總結
小米技術分享:解密小米搶購系統千萬高并發架構的演進和實踐
一篇讀懂分布式架構下的負載均衡技術:分類、原理、算法、常見方案等
通俗易懂:如何設計能支撐百萬并發的數據庫架構?
多維度對比5款主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了
從新手到架構師,一篇就夠:從100到1000萬高并發的架構演進之路
美團技術分享:深度解密美團的分布式ID生成算法
12306搶票帶來的啟示:看我如何用Go實現百萬QPS的秒殺系統(含源碼)
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:微信這樣的IM的附件用什么協議傳?aes加密是在網絡層完成嗎?下一篇:求助IM在鎖屏、后臺或結束進程情況下,能接收語音和視頻通知(像微信一樣)

本帖已收錄至以下技術專輯

推薦方案
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
股票配资平台都找股牛网