本文由馬蜂窩技術團隊電商交易基礎平臺研發(fā)工程師"Anti Walker"原創(chuàng)分享。

一、引言

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

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

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

另外：如果你對Go在高并發(fā)系統(tǒng)中的應用感興趣，即時通訊網(wǎng)的以下兩篇也值得一讀：

《Go語言構建千萬級在線的高并發(fā)消息推送系統(tǒng)實踐(來自360公司)》

《12306搶票帶來的啟示：看我如何用Go實現(xiàn)百萬QPS的秒殺系統(tǒng)(含源碼)》

系列文章：

《從游擊隊到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構演進之路》

《從游擊隊到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構演進和實踐總結》

《從游擊隊到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術實踐》（* 本文）

關于馬蜂窩旅游網(wǎng)： 

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

學習交流：

- 即時通訊/推送技術開發(fā)交流5群：215477170 [推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-2909-1-1.html）

二、相關文章

《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》

《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構方案》

《從零到卓越：京東客服即時通訊系統(tǒng)的技術架構演進歷程》

《蘑菇街即時通訊/IM服務器開發(fā)之架構選擇》

《以微博類應用場景為例，總結海量社交系統(tǒng)的架構設計步驟》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構方案設計實踐》

《騰訊QQ1.4億在線用戶的技術挑戰(zhàn)和架構演進之路PPT》

《微信技術總監(jiān)談架構：微信之道——大道至簡(演講全文)》

《如何解讀《微信技術總監(jiān)談架構：微信之道——大道至簡》》

《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》

《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構設計（整理自現(xiàn)場演講，有配套PPT）》

《阿里釘釘技術分享：企業(yè)級IM王者——釘釘在后端架構上的過人之處》

三、技術背景和問題

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

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

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

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

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

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

4.1、實現(xiàn)目標

1）業(yè)務解耦：

將業(yè)務邏輯與通信流程剝離，使 IM 服務架構更加清晰，實現(xiàn)與電商 IM 業(yè)務邏輯的完全分離，保證服務穩(wěn)定性。

2）接入方式靈活：

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

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

3）架構可擴展：

為了應對業(yè)務的持續(xù)增長給系統(tǒng)性能帶來的挑戰(zhàn)，我們考慮用分布式架構來設計即時通訊服務，使系統(tǒng)具有持續(xù)擴展及提升的能力。

4.2、語言選擇

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

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

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

4.3、架構設計

整體架構圖如下： 

名詞解釋：

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

架構分層：

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

4.4、服務流程

步驟一：

如上圖右側所示：

用戶客戶端與消息處理模塊建立 WebSocket 長連接；

通過負載均衡算法，使客戶端連接到合適的服務器（消息處理模塊的某個 Worker）；

連接成功后，記錄用戶連接信息，包括用戶角色（客人或商家）、客戶端平臺（移動端、網(wǎng)頁端、桌面端）等組成唯一 Key，記錄到 Redis 集群。

步驟二：

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

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

2）如果這個購買者之前沒有聊過天，則在業(yè)務服務器邏輯里需要有一個分配客服的過程，即建立購買者和商家的客服之間的連接關系。拿到這個客服的 ID，用來做業(yè)務消息下發(fā)；如果之前已經(jīng)聊過天，則略過此環(huán)節(jié)。

3）在業(yè)務服務器，消息會異步入數(shù)據(jù)庫。保證消息不會丟失。

步驟三：

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

步驟四：

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

1）分發(fā)模塊通過 RPC 方式把消息轉發(fā)到目標用戶連接的 Worker，RPC 的方式性能更快，而且傳輸?shù)臄?shù)據(jù)也少，從而節(jié)約了服務器的成本。

2）消息透傳 Worker 的時候，多種策略保障消息一定會下發(fā)到 Worker。

步驟五：

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

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

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

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

以上步驟的數(shù)據(jù)流轉大致如圖所示：

4.5、系統(tǒng)完整性設計

4.5.1 可靠性

（1）消息不丟失：

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

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

（2）多端消息同步：

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

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

4.5.2 可用性

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

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

1）Go STDRPC：Go 標準庫的 RPC，性能最優(yōu)，但是沒有治理；

2）RPCX：性能優(yōu)勢 2*GRPC + 服務治理；

3）GRPC：跨語言，但性能沒有 RPCX 好；

4）TarsGo：跨語言，性能 5*GRPC，缺點是框架較大，整合起來費勁；

5）Dubbo-Go：性能稍遜一籌, 比較適合 Go 和 Java 間通信場景使用。

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

兩個進程之間同樣需要通信，這里用到的是 ETCD 實現(xiàn)服務注冊發(fā)現(xiàn)機制。

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

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

在進行注冊中心的選型時，我們主要調研了 ETCD、ZooKeeper、Consul。

三者的壓測結果參考如下： 

 

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

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

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

4.5.3 擴展性

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

4.5.4 安全性

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

4.6、性能優(yōu)化和踩過的坑

4.6.1 性能優(yōu)化

1）JSON 編解碼：

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

以下是壓測對比的參考圖： 

2）time.After：

在壓測的時候，我們發(fā)現(xiàn)內存占用很高，于是使用 Go Tool PProf 分析 Golang 函數(shù)內存申請情況，發(fā)現(xiàn)有不斷創(chuàng)建 time.After 定時器的問題，定位到是心跳協(xié)程里面。

原來代碼如下： 

優(yōu)化后的代碼為：

優(yōu)化點在于 for 循環(huán)里不要使用 select + time.After 的組合。

3）Map 的使用：

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

4.6.2 踩坑經(jīng)驗

1）協(xié)程異常：

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

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

2）心跳設計：

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

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

3）每天分割日志： 

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

ZAP 的優(yōu)點包括：

1）顯示代碼行號這個需求，ZAP 支持而 Logrus 不支持，這個屬于提效的。行號展示對于定位問題很重要；

2）ZAP 相對于 Logrus 更為高效，體現(xiàn)在寫 JSON 格式日志時，沒有使用反射，而是用內建的 json encoder，通過明確的類型調用，直接拼接字符串，最小化性能開銷。

小坑：每天寫一個日志文件的功能，目前 ZAP 不支持，需要自己寫代碼支持，或者請求系統(tǒng)部支持。

五、性能表現(xiàn)

壓測 1：

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

壓測 2：

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

其中有一半是心跳包 另一半是日志結構體。在不同的壓力下的下行延遲數(shù)據(jù)如下： 

結論：

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

六、本文小結

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

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

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

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

[1] 有關IM架構設計的文章：

《淺談IM系統(tǒng)的架構設計》

《簡述移動端IM開發(fā)的那些坑：架構設計、通信協(xié)議和客戶端》

《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》

《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構方案》

《從零到卓越：京東客服即時通訊系統(tǒng)的技術架構演進歷程》

《蘑菇街即時通訊/IM服務器開發(fā)之架構選擇》

《騰訊QQ1.4億在線用戶的技術挑戰(zhàn)和架構演進之路PPT》

《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構設計實踐》

《微信技術總監(jiān)談架構：微信之道——大道至簡(演講全文)》

《如何解讀《微信技術總監(jiān)談架構：微信之道——大道至簡》》

《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》

《17年的實踐：騰訊海量產品的技術方法論》

《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《IM開發(fā)基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》

《IM開發(fā)基礎知識補課(三)：快速理解服務端數(shù)據(jù)庫讀寫分離原理及實踐建議》

《IM開發(fā)基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術實踐分享：32人工程團隊創(chuàng)造的技術神話》

《微信朋友圈千億訪問量背后的技術挑戰(zhàn)和實踐總結》

《王者榮耀2億用戶量的背后：產品定位、技術架構、網(wǎng)絡方案等》

《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》

《騰訊資深架構師干貨總結：一文讀懂大型分布式系統(tǒng)設計的方方面面》

《以微博類應用場景為例，總結海量社交系統(tǒng)的架構設計步驟》

《快速理解高性能HTTP服務端的負載均衡技術原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構師分享億級IM平臺的技術實踐》

《知乎技術分享：從單機到2000萬QPS并發(fā)的Redis高性能緩存實踐之路》

《IM開發(fā)基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》

《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》

《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》

《新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構方案設計實踐》

《阿里技術分享：深度揭秘阿里數(shù)據(jù)庫技術方案的10年變遷史》

《阿里技術分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》

《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現(xiàn)等》

《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》

《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背后的技術細節(jié)》

《社交軟件紅包技術解密(四)：微信紅包系統(tǒng)是如何應對高并發(fā)的》

《社交軟件紅包技術解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》

《社交軟件紅包技術解密(六)：微信紅包系統(tǒng)的存儲層架構演進實踐》

《社交軟件紅包技術解密(七)：支付寶紅包的海量高并發(fā)技術實踐》

《社交軟件紅包技術解密(八)：全面解密微博紅包技術方案》

《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構等》

《即時通訊新手入門：一文讀懂什么是Nginx？它能否實現(xiàn)IM的負載均衡？》

《即時通訊新手入門：快速理解RPC技術——基本概念、原理和用途》

《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》

《從游擊隊到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構演進之路》

《從游擊隊到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構演進和實踐總結》

《IM開發(fā)基礎知識補課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》

《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構設計（整理自現(xiàn)場演講，有配套PPT）》

《阿里釘釘技術分享：企業(yè)級IM王者——釘釘在后端架構上的過人之處》

>> 更多同類文章 ……

[2] 更多其它架構設計相關文章：

《騰訊資深架構師干貨總結：一文讀懂大型分布式系統(tǒng)設計的方方面面》

《快速理解高性能HTTP服務端的負載均衡技術原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構師分享億級IM平臺的技術實踐》

《知乎技術分享：從單機到2000萬QPS并發(fā)的Redis高性能緩存實踐之路》

《新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐》

《阿里技術分享：深度揭秘阿里數(shù)據(jù)庫技術方案的10年變遷史》

《阿里技術分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》

《達達O2O后臺架構演進實踐：從0到4000高并發(fā)請求背后的努力》

《優(yōu)秀后端架構師必會知識：史上最全MySQL大表優(yōu)化方案總結》

《小米技術分享：解密小米搶購系統(tǒng)千萬高并發(fā)架構的演進和實踐》

《一篇讀懂分布式架構下的負載均衡技術：分類、原理、算法、常見方案等》

《通俗易懂：如何設計能支撐百萬并發(fā)的數(shù)據(jù)庫架構？》

《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》

《從新手到架構師，一篇就夠：從100到1000萬高并發(fā)的架構演進之路》

《美團技術分享：深度解密美團的分布式ID生成算法》

《12306搶票帶來的啟示：看我如何用Go實現(xiàn)百萬QPS的秒殺系統(tǒng)(含源碼)》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-2909-1-1.html）