本文引用自馬蜂窩公眾號(hào)，由馬蜂窩技術(shù)團(tuán)隊(duì)原創(chuàng)分享。
一、引言
今天，越來(lái)越多的用戶被馬蜂窩持續(xù)積累的筆記、攻略、嗡嗡等優(yōu)質(zhì)的分享內(nèi)容所吸引，在這里激發(fā)了去旅行的熱情，同時(shí)也拉動(dòng)了馬蜂窩交易的增長(zhǎng)。在幫助用戶做出旅行決策、完成交易的過(guò)程中，IM 系統(tǒng)起到了重要的作用。
IM 系統(tǒng)為用戶與商家建立了直接溝通的渠道，幫助用戶解答購(gòu)買旅行產(chǎn)品中的問(wèn)題，既促成了訂單交易，也幫用戶打消了疑慮，促成用戶旅行愿望的實(shí)現(xiàn)。伴隨著業(yè)務(wù)的快速發(fā)展，幾年間，馬蜂窩 IM 系統(tǒng)也經(jīng)歷了幾次比較重要的架構(gòu)演化和轉(zhuǎn)型。
本文將分享馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)從零演進(jìn)的整個(gè)過(guò)程，希望能給你的IM技術(shù)選型和方案確定帶來(lái)啟發(fā)。
關(guān)于馬蜂窩旅游網(wǎng)：
馬蜂窩旅游網(wǎng)是中國(guó)領(lǐng)先的自由行服務(wù)平臺(tái)，由陳罡和呂剛創(chuàng)立于2006年，從2010年正式開始公司化運(yùn)營(yíng)。馬蜂窩的景點(diǎn)、餐飲、酒店等點(diǎn)評(píng)信息均來(lái)自上億用戶的真實(shí)分享，每年幫助過(guò)億的旅行者制定自由行方案。
學(xué)習(xí)交流：
- 即時(shí)通訊/推送技術(shù)開發(fā)交流4群：101279154[推薦]
- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-2675-1-1.html）
二、相關(guān)文章
三、IM 1.0：初期階段
初期為了支持業(yè)務(wù)快速上線，且當(dāng)時(shí)版本流量較低，對(duì)并發(fā)要求不高，IM 系統(tǒng)的技術(shù)架構(gòu)主要以簡(jiǎn)單和可用為目的，實(shí)現(xiàn)的功能也很基礎(chǔ)。
IM 1.0 使用 PHP 開發(fā)，實(shí)現(xiàn)了 IM 基本的用戶/客服接入、消息收發(fā)、咨詢列表管理功能。用戶咨詢時(shí)，會(huì)通過(guò)平均分配的策略分配給客服，記錄用戶和客服的關(guān)聯(lián)關(guān)系。用戶/客服發(fā)送消息時(shí)，通過(guò)調(diào)用消息轉(zhuǎn)發(fā)模塊，將消息投遞到對(duì)方的 Redis 阻塞隊(duì)列里。收消息則通過(guò) HTTP 長(zhǎng)連接調(diào)用消息輪詢模塊，有消息時(shí)即刻返回，沒(méi)有消息則阻塞一段時(shí)間返回，這里阻塞的目的是降低輪詢的間隔。
消息收發(fā)模型如下圖所示：
上圖模型中消息輪詢模塊的長(zhǎng)連接請(qǐng)求是通過(guò) php-fpm 掛載在阻塞隊(duì)列上，當(dāng)該請(qǐng)求變多時(shí)，如果不能及時(shí)釋放 php-fpm 進(jìn)程，會(huì)對(duì)服務(wù)器性能消耗較大，負(fù)載很高。
為了解決這個(gè)問(wèn)題，我們對(duì)消息輪詢模塊進(jìn)行了優(yōu)化，選用基于 OpenResty 框架，利用 Lua 協(xié)程的方式來(lái)優(yōu)化 php-fmp 長(zhǎng)時(shí)間掛載的問(wèn)題。Lua 協(xié)程會(huì)通過(guò)對(duì) Nginx 轉(zhuǎn)發(fā)的請(qǐng)求標(biāo)記判斷是否攔截網(wǎng)絡(luò)請(qǐng)求，如果攔截，則會(huì)將阻塞操作交給 Lua 協(xié)程來(lái)處理，及時(shí)釋放 php-fmp，緩解對(duì)服務(wù)器性能的消耗。
優(yōu)化的處理流程見下圖：
四、IM 2.0：需求定制階段
伴隨著業(yè)務(wù)的快速增長(zhǎng)，IM 系統(tǒng)在短期內(nèi)面臨著大量定制需求的增加，開發(fā)了許多新的業(yè)務(wù)模塊。面對(duì)大量的用戶咨詢，客服的服務(wù)能力已經(jīng)招架不住。
因此，IM 2.0 將重心放在提升業(yè)務(wù)功能體驗(yàn)上，比如：
1）在處理用戶的咨詢時(shí)，將從前單一的分配方式演變?yōu)椴捎闷骄?quán)重、排隊(duì)等多種方式；
2）為了提升客服的效率，客服的咨詢回復(fù)也增加了可選配置，例如自動(dòng)回復(fù)、FAQ 等。
以一個(gè)典型的用戶咨詢場(chǎng)景為例，當(dāng)用戶打開 App 或者網(wǎng)頁(yè)時(shí)，會(huì)通過(guò)連接層建立長(zhǎng)連接，之后在咨詢?nèi)肟诎l(fā)起咨詢時(shí)，會(huì)攜帶著消息線索初始化消息鏈路，建立一條可復(fù)用、可檢索的消息線；發(fā)送消息時(shí)，通過(guò)消息服務(wù)將消息存儲(chǔ)到 DB 中，同時(shí)會(huì)根據(jù)消息線檢索當(dāng)前咨詢是否被分配到客服，調(diào)用分配服務(wù)的目的是為當(dāng)前咨詢完善客服信息；最后將客服信息更新到鏈路關(guān)系中。
這樣，一條完整的消息鏈路就建立完畢，之后用戶/客服發(fā)出的消息通過(guò)轉(zhuǎn)發(fā)服務(wù)傳輸給對(duì)方。
以上處理流程如下圖所示：
五、IM 3.0：服務(wù)拆分階段
5.1、概述
業(yè)務(wù)量在不斷積累，隨著模塊增加，IM 系統(tǒng)的代碼膨脹得很快。由于代碼規(guī)范沒(méi)有統(tǒng)一、接口職責(zé)不夠單一、模塊間耦合較多等種原因，改動(dòng)一個(gè)需求很可能會(huì)影響到其它模塊，使新需求的開發(fā)和維護(hù)成本都很高。
為了解決這種局面，IM 系統(tǒng)必須要進(jìn)行架構(gòu)升級(jí)，首要任務(wù)就是服務(wù)的拆分。目前，經(jīng)過(guò)拆分后的 IM 系統(tǒng)整體分為 4 塊大的服務(wù)，包括客服服務(wù)、用戶服務(wù)、IM 服務(wù)、數(shù)據(jù)服務(wù)。
如下圖所示：
如上圖，我們來(lái)進(jìn)行一下解讀：
1）客服服務(wù)：圍繞提升客服效率和用戶體驗(yàn)提供多種方式，如提供群組管理、成員管理、質(zhì)檢服務(wù)等來(lái)提升客服團(tuán)隊(duì)的運(yùn)營(yíng)和管理水平；通過(guò)分配服務(wù)、轉(zhuǎn)接服務(wù)來(lái)使用戶的接待效率更靈活高效；支持自動(dòng)回復(fù)、FAQ、知識(shí)庫(kù)服務(wù)等來(lái)提升客服咨詢的回復(fù)效率等；
2）用戶服務(wù)：分析用戶行為，為用戶做興趣推薦及用戶畫像，以及統(tǒng)計(jì)用戶對(duì)馬蜂窩商家客服的滿意度；
3）IM 服務(wù)：支持單聊和群聊模式，提供實(shí)時(shí)消息通知、離線消息推送、歷史消息漫游、聯(lián)系人、文件上傳與存儲(chǔ)、消息內(nèi)容風(fēng)控檢測(cè)等；
4）數(shù)據(jù)服務(wù)：通過(guò)采集用戶咨詢的來(lái)源入口、是否咨詢下單、是否有客服接待、用戶咨詢以及客服回復(fù)的時(shí)間信息等，定義數(shù)據(jù)指標(biāo)，通過(guò)數(shù)據(jù)分析進(jìn)行離線數(shù)據(jù)運(yùn)算，最終對(duì)外提供數(shù)據(jù)統(tǒng)計(jì)信息。主要的指標(biāo)信息有 30 秒、1 分鐘回復(fù)率、咨詢?nèi)藬?shù)、無(wú)應(yīng)答次數(shù)、平均應(yīng)答時(shí)間、咨詢銷售額、咨詢轉(zhuǎn)化率、推薦轉(zhuǎn)化率、分時(shí)接待壓力、值班情況、服務(wù)評(píng)分等。
5.2、用戶狀態(tài)流轉(zhuǎn)
現(xiàn)有的 IM 系統(tǒng) 中，用戶咨詢時(shí)一個(gè)完整的用戶狀態(tài)流轉(zhuǎn)如下圖所示：
如上圖所示：
1）用戶點(diǎn)擊咨詢按鈕觸發(fā)事件，此時(shí)用戶狀態(tài)進(jìn)入初始態(tài)；
2）發(fā)送消息時(shí)，系統(tǒng)更改用戶狀態(tài)為待分配，通過(guò)調(diào)用分配服務(wù)分配了對(duì)應(yīng)的客服后，用戶狀態(tài)更改為已分配、未解決；
3）當(dāng)客服解決了用戶或者客服回復(fù)后用戶長(zhǎng)時(shí)間未說(shuō)話，觸發(fā)系統(tǒng)自動(dòng)解決的操作，此時(shí)用戶狀態(tài)更改為已解決，一個(gè)咨詢流程結(jié)束。
5.3、IM 服務(wù)的重構(gòu)
在服務(wù)拆分的過(guò)程中，我們需要考慮特定服務(wù)的通用性、可用性和降級(jí)策略，同時(shí)需要盡可能地降低服務(wù)間的依賴，避免由于單一服務(wù)不可用導(dǎo)致整體服務(wù)癱瘓的風(fēng)險(xiǎn)。
在這期間，公司其它業(yè)務(wù)線對(duì) IM 服務(wù)的使用需求也越來(lái)越多，使用頻次和量級(jí)也開始加大。初期階段的 IM 服務(wù)當(dāng)連接量大時(shí)，只能通過(guò)修改代碼實(shí)現(xiàn)水平擴(kuò)容；新業(yè)務(wù)接入時(shí)，還需要在業(yè)務(wù)服務(wù)器上配置 Openresty 環(huán)境及 Lua 協(xié)程代碼，業(yè)務(wù)接入非常不便，IM 服務(wù)的通用性也很差。
考慮到以上問(wèn)題，我們對(duì) IM 服務(wù)進(jìn)行了全面重構(gòu)，目標(biāo)是將 IM 服務(wù)抽取成獨(dú)立的模塊，不依賴其它業(yè)務(wù)，對(duì)外提供統(tǒng)一的集成和調(diào)用方式。考慮到 IM 服務(wù)對(duì)并發(fā)處理高和損耗低的要求，選擇了 Go 語(yǔ)言來(lái)開發(fā)此模塊。
新的 IM 服務(wù)設(shè)計(jì)如下圖：
其中，比較重要的 Proxy 層和 Exchange 層提供了以下服務(wù)：
1）路由規(guī)則：例如 ip-hash、輪詢、最小連接數(shù)等，通過(guò)規(guī)則將客戶端散列到不同的 ChannelManager 實(shí)例上；
2）對(duì)客戶端接入的管理：接入后的連接信息會(huì)同步到 DispatchTable 模塊，方便 Dispatcher 進(jìn)行檢索；
3）ChannelManager 與客戶端間的通信協(xié)議：包括客戶端請(qǐng)求建立連接、斷線重連、主動(dòng)斷開、心跳、通知、收發(fā)消息、消息的 QoS 等；
4）對(duì)外提供單發(fā)、群發(fā)消息的 REST 接口：這里需要根據(jù)場(chǎng)景來(lái)決定是否使用，例如用戶咨詢客服的場(chǎng)景就需要通過(guò)這個(gè)接口下發(fā)消息。
針對(duì)上述第“4）”點(diǎn)，主要原因在以下 3 點(diǎn)：
1）發(fā)消息時(shí)會(huì)有創(chuàng)建消息線、分配管家等邏輯，這些邏輯目前是 PHP 實(shí)現(xiàn)，IM 服務(wù)需要知道 PHP 的執(zhí)行結(jié)果，一種方式是使用 Go 重新實(shí)現(xiàn)，另外一種方式是通過(guò) REST 接口調(diào)用 PHP 返回，這樣會(huì)帶來(lái) IM 服務(wù)和 PHP 業(yè)務(wù)過(guò)多的網(wǎng)絡(luò)交互，影響性能；
2）轉(zhuǎn)發(fā)消息時(shí)，ChannelManager 多個(gè)實(shí)例間需要互相通信，例如 ChannelManager1 上的用戶 A 給 ChannelManager2 上的客服 B 發(fā)消息，如果實(shí)例間無(wú)通信機(jī)制，消息無(wú)法轉(zhuǎn)發(fā)。當(dāng)要再擴(kuò)展 ChannelManager 實(shí)例時(shí)，新增實(shí)例需要和其它已存在實(shí)例分別建立通信，增加了系統(tǒng)擴(kuò)展的復(fù)雜度；
3）如果客戶端不支持 WebSocket 協(xié)議，作為降級(jí)方案的 HTTP 長(zhǎng)連接輪循只能用來(lái)收消息，發(fā)消息需要通過(guò)短連接來(lái)處理。其它場(chǎng)景不需要消息轉(zhuǎn)發(fā)，只用來(lái)給 ChannelManager 傳輸消息的場(chǎng)景，可通過(guò) WebSocket 直接發(fā)送。
5.4、改造后的 IM 服務(wù)調(diào)用流程
初始化消息線及分配客服過(guò)程由 PHP 業(yè)務(wù)完成。需要消息轉(zhuǎn)發(fā)時(shí)，PHP 業(yè)務(wù)調(diào)用 Dispatcher 服務(wù)的發(fā)消息接口，Dispatcher 服務(wù)通過(guò)共享的 Dispatcher Table 數(shù)據(jù)，檢索出接收者所在的 ChannelManager 實(shí)例，將消息通過(guò) RPC 的方式發(fā)送到實(shí)例上，ChannelManager 通過(guò) WebSocket 將消息推送給客戶端。
IM 服務(wù)調(diào)用流程如下圖所示：
當(dāng)連接數(shù)超過(guò)當(dāng)前 ChannelManager 集群承載的上限時(shí)，只需擴(kuò)展 ChannelManager 實(shí)例，由 ETCD 動(dòng)態(tài)的通知到監(jiān)聽側(cè)，從而做到平滑擴(kuò)容。目前瀏覽器版本的 JS-SDK 已經(jīng)開發(fā)完畢，其它業(yè)務(wù)線通過(guò)接入文檔，就能方便的集成 IM 服務(wù)。
在 Exchange 層的設(shè)計(jì)中，有 3 個(gè)問(wèn)題需要考。
1）多端消息同步：
現(xiàn)在客戶端有 PC 瀏覽器、Windows 客戶端、H5、iOS/Android，如果一個(gè)用戶登錄了多端，當(dāng)有消息過(guò)來(lái)時(shí)，需要查找出這個(gè)用戶的所有連接，當(dāng)用戶的某個(gè)端斷線后，需要定位到這一個(gè)連接。
上面提到過(guò)，連接信息都是存儲(chǔ)在 DispatcherTable 模塊中，因此 DispatcherTable 模塊要能根據(jù)用戶信息快速檢索出連接信息。DispatcherTable 模塊的設(shè)計(jì)用到了 Redis 的 Hash 存儲(chǔ)，當(dāng)客戶端與 ChannelManager 建立連接后，需要同步的元數(shù)據(jù)有 uid(用戶信息)、uniquefield(唯一值，一個(gè)連接對(duì)應(yīng)的唯一值)、wsid(連接標(biāo)示符)、clientip(客戶端 ip)、serverip(服務(wù)端 ip)、channel(渠道)，對(duì)應(yīng)的結(jié)構(gòu)大致如下:
這樣通過(guò) key(uid) 能找到一個(gè)用戶多個(gè)端的連接，通過(guò) key+field 能定位到一條連接。連接信息的默認(rèn)過(guò)期時(shí)間為 2 小時(shí)，目的是避免因客戶端連接異常中斷導(dǎo)致服務(wù)端沒(méi)有捕獲到，從而在 DispatcherTable 中存儲(chǔ)了一些過(guò)期數(shù)據(jù)。
2）用戶在線狀態(tài)同步：
比如一個(gè)用戶先后和 4 個(gè)客服咨詢過(guò)，那么這個(gè)用戶會(huì)出現(xiàn)在 4 個(gè)客服的咨詢列表里。當(dāng)用戶上線時(shí)，要保證 4 個(gè)客服看到用戶都是在線狀態(tài)。
要做到這一點(diǎn)有兩種方案：
一種是客服通過(guò)輪詢獲取用戶的狀態(tài)，但這樣當(dāng)用戶在線狀態(tài)沒(méi)有變化時(shí)，會(huì)發(fā)起很多無(wú)效的請(qǐng)求；
另外一種是用戶上線時(shí)，給客服推送上線通知，這樣會(huì)造成消息擴(kuò)散，每一個(gè)咨詢過(guò)的客服都需要擴(kuò)散通知。
我們最終采取的是第二種方式，在推送的過(guò)程中，只給在線的客服推送用戶狀態(tài)。
3）消息的不丟失，不重復(fù)：
為了避免消息丟失，對(duì)于采用長(zhǎng)連接輪詢方式的我們會(huì)在發(fā)起請(qǐng)求時(shí)，帶上客戶端已讀消息的 ID，由服務(wù)端計(jì)算出差值消息然后返回；使用 WebSocket 方式的，服務(wù)端會(huì)在推送給客戶端消息后，等待客戶端的 ACK，如果客戶端沒(méi)有 ACK，服務(wù)端會(huì)嘗試多次推送。
這時(shí)就需要客戶端根據(jù)消息 ID 做消息重復(fù)的處理，避免客戶端可能已收到消息，但是由于其它原因?qū)е?ACK 確認(rèn)失敗，觸發(fā)重試，導(dǎo)致消息重復(fù)。
5.5、IM 服務(wù)的消息流
上文提到過(guò) IM 服務(wù)需要支持多終端，同時(shí)在角色上又分為用戶端和商家端，為了能讓通知、消息在輸出時(shí)根據(jù)域名、終端、角色動(dòng)態(tài)輸出差異化的內(nèi)容，引入了 DDD （領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）的建模方法來(lái)對(duì)消息進(jìn)行處理。
處理過(guò)程如下圖所示：
六、小結(jié)和展望
伴隨著馬蜂窩「內(nèi)容+交易」模式的不斷深化，IM 系統(tǒng)架構(gòu)也經(jīng)歷著演化和升級(jí)的不同階段，從初期粗曠無(wú)序的模式走向統(tǒng)一管理，逐漸規(guī)范、形成規(guī)模。
我們?nèi)〉昧艘恍┻M(jìn)步，當(dāng)然，還有更長(zhǎng)的路要走。未來(lái)，結(jié)合公司業(yè)務(wù)的發(fā)展腳步和團(tuán)隊(duì)的技術(shù)能力，我們將不斷進(jìn)行 IM 系統(tǒng)的優(yōu)化。
目前我們正在計(jì)劃將消息輪詢模塊中的服務(wù)端代碼用 Go 替換，使其不再依賴 PHP 及 OpenResty 環(huán)境，實(shí)現(xiàn)更好地解耦；另外，我們將基于 TensorFlow 實(shí)現(xiàn)向智慧客服的探索，通過(guò)訓(xùn)練數(shù)據(jù)模型、分析數(shù)據(jù)，進(jìn)一步提升人工客服的解決效率，提升用戶體驗(yàn)，更好地為業(yè)務(wù)賦能。
附錄：更多架構(gòu)設(shè)計(jì)文章
[1] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡(jiǎn)述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》
《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》
《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐》
《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》
《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》
《即時(shí)通訊新手入門：一文讀懂什么是Nginx？它能否實(shí)現(xiàn)IM的負(fù)載均衡？》
《即時(shí)通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》
《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》
《從游擊隊(duì)到正規(guī)軍：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》
>> 更多同類文章 ……
[2] 更多其它架構(gòu)設(shè)計(jì)相關(guān)文章：
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《達(dá)達(dá)O2O后臺(tái)架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請(qǐng)求背后的努力》
《優(yōu)秀后端架構(gòu)師必會(huì)知識(shí)：史上最全MySQL大表優(yōu)化方案總結(jié)》
《小米技術(shù)分享：解密小米搶購(gòu)系統(tǒng)千萬(wàn)高并發(fā)架構(gòu)的演進(jìn)和實(shí)踐》
《一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類、原理、算法、常見方案等》
《通俗易懂：如何設(shè)計(jì)能支撐百萬(wàn)并發(fā)的數(shù)據(jù)庫(kù)架構(gòu)？》
《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》
《從新手到架構(gòu)師，一篇就夠：從100到1000萬(wàn)高并發(fā)的架構(gòu)演進(jìn)之路》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2675-1-1.html）