本文由轉(zhuǎn)轉(zhuǎn)王棕生分享，原題“IM系列(一)：轉(zhuǎn)轉(zhuǎn)IM系統(tǒng)架構(gòu)探秘”，下文進(jìn)行了排版和內(nèi)容優(yōu)化。
1、引言
轉(zhuǎn)轉(zhuǎn)是二手電商平臺(tái)，在這個(gè)平臺(tái)上，人人可以是買家，人人也可以是賣家。轉(zhuǎn)轉(zhuǎn)從最初的信息模式升級(jí)為一個(gè)閉環(huán)的交易模式，IM打通了買家與賣家之間的通道。本文描述了轉(zhuǎn)轉(zhuǎn)IM為整個(gè)平臺(tái)提供的支撐能力，給出了系統(tǒng)的整體架構(gòu)設(shè)計(jì)，分析了系統(tǒng)架構(gòu)的特性。
2、系列文章
本文是系列文章中的第1篇，本系列文章的大綱如下：
3、本文作者
王棕生：轉(zhuǎn)轉(zhuǎn)架構(gòu)平臺(tái)部高級(jí)研發(fā)工程師，負(fù)責(zé)IM系統(tǒng)、推送系統(tǒng)和分布式存儲(chǔ)系統(tǒng)。
4、系統(tǒng)能力定義
轉(zhuǎn)轉(zhuǎn)IM需要提供如下的支撐能力：
1）有的用戶習(xí)慣使用APP、有的用戶習(xí)慣免安裝的小程序；還有的用戶習(xí)慣于在“58同城”APP上搜索二手；所以IM需要支持APP、小程序、M端等各種終端類型，以及由轉(zhuǎn)轉(zhuǎn)平臺(tái)衍生出的其他垂類APP。
2）IM是轉(zhuǎn)轉(zhuǎn)平臺(tái)中的一個(gè)獨(dú)立系統(tǒng)，需要向平臺(tái)中的其他系統(tǒng)（如客服系統(tǒng)、風(fēng)控系統(tǒng)）提供“聯(lián)系人”和“私信”等IM能力。
3）在轉(zhuǎn)轉(zhuǎn)平臺(tái)的各種運(yùn)營活動(dòng)中，需要借助于IM通道將商品消息、訂單消息、交易消息及活動(dòng)通知等實(shí)時(shí)的發(fā)送給用戶。
總之：IM為轉(zhuǎn)轉(zhuǎn)平臺(tái)提供一個(gè)可靠和穩(wěn)定的通道，為用戶與用戶之間、業(yè)務(wù)系統(tǒng)與用戶之間、平臺(tái)與用戶之間打造一個(gè)可以即時(shí)通訊的環(huán)境。
5、系統(tǒng)架構(gòu)概覽
轉(zhuǎn)轉(zhuǎn)IM系統(tǒng)架構(gòu)設(shè)計(jì)如下圖所示，自上而下包括四層：用戶層、入口層、邏輯層和原子存儲(chǔ)層。
轉(zhuǎn)轉(zhuǎn)IM系統(tǒng)架構(gòu)設(shè)計(jì)圖：
6、系統(tǒng)架構(gòu)之“用戶層”
用戶層是IM服務(wù)的調(diào)用者，用戶層支撐各類業(yè)務(wù)應(yīng)用，包括APP、小程序、M端、平臺(tái)運(yùn)營類業(yè)務(wù)系統(tǒng)和ZZRPC。
APP基于TCP協(xié)議與IM服務(wù)端進(jìn)行消息傳輸，小程序和M端則是通過HTTP協(xié)議。
ZZRPC是轉(zhuǎn)轉(zhuǎn)平臺(tái)使用Java語言自研的RPC框架，而轉(zhuǎn)轉(zhuǎn)IM系統(tǒng)是使用C++語言進(jìn)行研發(fā)的，所以IM需要通過適配支持ZZRPC服務(wù)的相互調(diào)用。
7、系統(tǒng)架構(gòu)之“入口層”
入口層是IM系統(tǒng)的入口網(wǎng)關(guān)，包括：
- 1）Entry
- 2）Http-Entry
- 3）轉(zhuǎn)轉(zhuǎn)自研的分布式消息中間件ZZMQ；
- 4）IMUI。
Entry：負(fù)責(zé)維護(hù)與APP之間的TCP連接，把APP發(fā)送的業(yè)務(wù)請(qǐng)求包向后直接轉(zhuǎn)發(fā)到邏輯層進(jìn)行處理。Entry邏輯較為簡(jiǎn)單，不參與具體的業(yè)務(wù)處理，這樣設(shè)計(jì)的原因是為了避免Entry因業(yè)務(wù)改造升級(jí)進(jìn)行模塊重啟，而丟失與APP之間的TCP連接，影響大量用戶。
Http-Entry：是HTTP版的Entry實(shí)現(xiàn)，Http-Entry負(fù)責(zé)維護(hù)的是與小程序和M端之間通過HTTP協(xié)議模擬的“長連接”。
HTTP“長連接”的實(shí)現(xiàn)原理是：小程序發(fā)送http_request到Http-Entry，Http-Entry會(huì)hold住連接不返回、不釋放；當(dāng)產(chǎn)生了該用戶的私信數(shù)據(jù)時(shí)或hold住連接超過一定時(shí)間（如15秒）時(shí)，Http-Entry則返回http_response到小程序；小程序收到http_response時(shí)需要立即再次發(fā)送http_request到Http-Entry......。
ZZMQ：是轉(zhuǎn)轉(zhuǎn)自研的分布式消息隊(duì)列，接收平臺(tái)各個(gè)運(yùn)營類業(yè)務(wù)系統(tǒng)生產(chǎn)的系統(tǒng)消息、廣播消息和推送類消息，然后由IM邏輯模塊進(jìn)行消費(fèi)處理。ZZMQ解耦了平臺(tái)業(yè)務(wù)系統(tǒng)和IM系統(tǒng)。
IMUI：用于IM系統(tǒng)適配ZZRPC的調(diào)用；IMUI作為ZZRPC服務(wù)的提供者，接收ZZRPC客戶端的請(qǐng)求后，按照IM系統(tǒng)的內(nèi)部協(xié)議格式同步訪問邏輯層，再將邏輯層的操作結(jié)果按ZZRPC協(xié)議進(jìn)行封裝，然后返回到ZZRPC的客戶端。
8、系統(tǒng)架構(gòu)之“邏輯層”
邏輯層包括Logic和Extlogic兩個(gè)模塊組件：
- 1）Logic負(fù)責(zé)實(shí)現(xiàn)IM系統(tǒng)核心的和輕量級(jí)的業(yè)務(wù)邏輯，如用戶登錄、獲取未讀數(shù)、發(fā)送私信等；
- 2）非核心的和重量級(jí)的業(yè)務(wù)由Extlogic進(jìn)行實(shí)現(xiàn)；
- 3）Logic和Extlogic兩個(gè)邏輯模塊通過ZZMQ進(jìn)行解耦。
例如：在私信邏輯處理流程中，Logic接收私信和用戶在線時(shí)的私信推送，而對(duì)于離線私信Logic則會(huì)通過ZZMQ通知Extlogic進(jìn)行離線消息的召回邏輯處理。
9、系統(tǒng)架構(gòu)之“原子存儲(chǔ)層”
IM需要持久化存儲(chǔ)的數(shù)據(jù)包括私信消息、系統(tǒng)消息和聯(lián)系人等。
這些數(shù)據(jù)通過傳統(tǒng)的關(guān)系型數(shù)據(jù)庫MySQL和NewSQL數(shù)據(jù)庫TiDB進(jìn)行保存：
- 1）TiDB是分布式數(shù)據(jù)庫，具有天然的彈性擴(kuò)容特性；
- 2）MySQL通過通用的分庫分表策略來應(yīng)對(duì)存儲(chǔ)和查詢負(fù)載。
Das接收邏輯層對(duì)持久化數(shù)據(jù)的讀寫請(qǐng)求，將請(qǐng)求放入本地隊(duì)列中，然后按順序?qū)?shù)據(jù)庫進(jìn)行同步讀寫操作。
ZZRedis是轉(zhuǎn)轉(zhuǎn)自研的分布式緩存系統(tǒng)，負(fù)責(zé)對(duì)用戶的在線信息進(jìn)行緩存。
Jtransit與IMUI類似，用于適配ZZRPC服務(wù)；Jtransit作為ZZRPC服務(wù)的調(diào)用，接收邏輯層的請(qǐng)求后，按照ZZRPC協(xié)議格式訪問平臺(tái)其他系統(tǒng)提供的服務(wù)，獲取數(shù)據(jù)后封裝成IM系統(tǒng)的協(xié)議數(shù)據(jù)返回到邏輯層。
10、架構(gòu)特性1：伸縮性
對(duì)轉(zhuǎn)轉(zhuǎn)IM系統(tǒng)架構(gòu)設(shè)計(jì)，從伸縮性、高可用、可靠性、可擴(kuò)展性和高性能分別進(jìn)行分析。
當(dāng)轉(zhuǎn)轉(zhuǎn)并發(fā)訪問的用戶量不斷增加，IM系統(tǒng)資源緊張時(shí)，需要通過增加機(jī)器進(jìn)行水平彈性擴(kuò)容，主要是通過服務(wù)管理平臺(tái)控制中心進(jìn)行實(shí)施的。入口層、邏輯層和原子層服務(wù)之間相互調(diào)用的關(guān)系如下表所示。
Entry和Http-Entry會(huì)作為調(diào)用方調(diào)用Logic的服務(wù)，Logic和Extlogic會(huì)作為調(diào)用方調(diào)用Das的服務(wù)和Entry與Http-Entry的服務(wù)，這些服務(wù)之間的關(guān)系通過控制中心進(jìn)行管理。
首先：
- 1）服務(wù)方組件與控制中心建立TCP長連接，將服務(wù)內(nèi)容包括本實(shí)例ip、端口、服務(wù)接口等等注冊(cè)到控制中心；
- 2）調(diào)用方組件與控制中心建立TCP長連接，從控制中心輪詢服務(wù)列表；
- 3）服務(wù)方組件增加機(jī)器彈性擴(kuò)容時(shí)，新的實(shí)例會(huì)注冊(cè)到控制中心，進(jìn)而被調(diào)用方實(shí)時(shí)拉取到。
另外：
- 1）App通過域名連接Entry時(shí)會(huì)首先訪問TGW，由TGW轉(zhuǎn)發(fā)請(qǐng)求到Entry，所以增加Entry實(shí)例時(shí)需要在TGW進(jìn)行注冊(cè)；
- 2）小程序到Http-Entry的HTTP請(qǐng)求都是由Nginx進(jìn)行中轉(zhuǎn)，所以增加Http-Entry機(jī)器需要在Nginx上進(jìn)行配置；
- 3）Extlogic作為ZZMQ的消費(fèi)者，可以自由增加實(shí)例。
存儲(chǔ)層擴(kuò)容：
- 1）數(shù)據(jù)庫MySQL通過分庫和分表的方式進(jìn)行擴(kuò)容；
- 2）分布式數(shù)據(jù)庫TiDB以及分布式緩存ZZRedis；
- 3）還有分布式消息隊(duì)列ZZMQ自身具有天然的彈性伸縮特性。
11、架構(gòu)特性2：高可用
1）入口層高可用：入口層Entry和Http-Entry的可用性分別由TGW和Nginx進(jìn)行探活和遷移。
2）Logic高可用：Logic的可用性由入口層實(shí)例進(jìn)行控制；為了保證同一用戶消息的順序性，Entry和Http-Entry會(huì)將同一個(gè)用戶的請(qǐng)求通過哈希算法打到相同的Logic實(shí)例；若一索引號(hào)為x的Logic實(shí)例掛掉以后，Entry和Http-Entry會(huì)在重試后將請(qǐng)求打到索引號(hào)為(x+p)%n的Logic實(shí)例上（n為Logic實(shí)例數(shù)目，p的取值區(qū)間為[1,n) ）；注意p的取值不能固定，否則很容易將瞬時(shí)流量打到固定的Logic實(shí)例，引起雪崩效應(yīng)。
3）Extlogic高可用：Extlogic負(fù)責(zé)消費(fèi)消息隊(duì)列ZZMQ中的消息，掛掉任意一個(gè)實(shí)例后，不影響業(yè)務(wù)的正常處理。
4）Das高可用：Das的高可用由Logic和Extlogic進(jìn)行控制，原理與Logic高可用一致，在掛掉任意一個(gè)Das實(shí)例后，Logic和Extlogic會(huì)將請(qǐng)求打到索引號(hào)為(x+p)%n的Das實(shí)例上。
5）存儲(chǔ)層高可用：MySQL通過一主兩備模式保證其高可用，在主庫掛掉以后，其中的一個(gè)備庫變?yōu)橹鲙炖^續(xù)對(duì)Das提供服務(wù)；分布式數(shù)據(jù)庫TiDB、分布式緩存ZZRedis，分布式消息隊(duì)列ZZMQ自身具有天然的高可用特性。
12、架構(gòu)特性3：可靠性
程序的正確處理保證系統(tǒng)的可靠性，影響IM系統(tǒng)可靠性的因素主要是瞬時(shí)高峰導(dǎo)致的邏輯層Logic實(shí)例的系統(tǒng)資源被用光和原子層Das對(duì)數(shù)據(jù)庫的訪問超時(shí)。
1）Logic可靠性：邏輯層實(shí)例的系統(tǒng)資源被用光發(fā)生在業(yè)務(wù)的相互影響；例如瞬時(shí)大量用戶登錄IM系統(tǒng)時(shí)，Logic大部分或全部線程被調(diào)度用于處理用戶登錄業(yè)務(wù)，而沒有足夠的資源去處理私信等業(yè)務(wù)。提高Logic可靠性的方案，可以根據(jù)微服務(wù)思想對(duì)Logic按功能職責(zé)進(jìn)行拆分，如拆分成Login_Logic、Msg_Logic、Contact_Logic等。
2）Das可靠性：對(duì)數(shù)據(jù)庫的訪問超時(shí)發(fā)生在數(shù)據(jù)庫負(fù)載較高時(shí)，例如推送千萬級(jí)廣播系統(tǒng)消息時(shí)，會(huì)有大量的更新操作落到數(shù)據(jù)庫上，此時(shí)數(shù)據(jù)庫響應(yīng)較慢或超時(shí)；因?yàn)镈as對(duì)數(shù)據(jù)庫的操作是同步的，所以會(huì)造成Das內(nèi)部隊(duì)列請(qǐng)求的堆積，其他業(yè)務(wù)請(qǐng)求也會(huì)被堆積而導(dǎo)致超時(shí)。提高Das可靠性的方案，可以根據(jù)業(yè)務(wù)類型在Das內(nèi)部分別創(chuàng)建不同的請(qǐng)求隊(duì)列，從而避免業(yè)務(wù)的相互影響。
13、架構(gòu)特性4：可擴(kuò)展性和高性能
1）可擴(kuò)展性：轉(zhuǎn)轉(zhuǎn)IM系統(tǒng)架構(gòu)的可擴(kuò)展性體現(xiàn)在邏輯層，邏輯層Logic和Extlogic通過消息隊(duì)列ZZMQ進(jìn)行解耦，定制類的功能需求在Extlogic中進(jìn)行實(shí)現(xiàn)，避免對(duì)核心業(yè)務(wù)Logic的影響。
ZZMQ除了解耦Logic和Extlogic外，還對(duì)平臺(tái)的業(yè)務(wù)系統(tǒng)和IM系統(tǒng)進(jìn)行解耦。
2）高性能：分析IM系統(tǒng)架構(gòu)，入口層和邏輯層主要是計(jì)算模塊，原子存儲(chǔ)層主要是IO模塊，系統(tǒng)的性能瓶頸集中在數(shù)據(jù)庫端。提升性能方案有：通過增強(qiáng)機(jī)器配置、增加機(jī)器、研究和新的存儲(chǔ)方式，如用戶聯(lián)系人可以通過KList引擎進(jìn)行存儲(chǔ)。
14、本文小結(jié)
轉(zhuǎn)轉(zhuǎn)IM為用戶與用戶之間、客服與用戶之間、平臺(tái)與用戶之間打造了一個(gè)高效和可靠的通訊通道。
按微服務(wù)私信和分層模式對(duì)IM系統(tǒng)架構(gòu)進(jìn)行分布式設(shè)計(jì)，架構(gòu)中每個(gè)組件模塊的功能職責(zé)明確。
具體的功能職責(zé)如下：
- 1）Entry負(fù)責(zé)維護(hù)TCP連接；
- 2）Http-Entry負(fù)責(zé)維護(hù)HTTP連接；
- 3）Logic負(fù)責(zé)處理核心的輕量級(jí)業(yè)務(wù)，Logic要求服務(wù)穩(wěn)定；
- 4）Extlogic負(fù)責(zé)處理非核心的重量級(jí)業(yè)務(wù)，Extlogic要求服務(wù)可擴(kuò)展；
- 5）Das負(fù)責(zé)對(duì)數(shù)據(jù)庫進(jìn)行讀寫訪問；
- 6）IMUI和Jtransit負(fù)責(zé)對(duì)平臺(tái)的RPC框架ZZRPC進(jìn)行適配；
- 7）MySQL、TiDB和ZZRedis負(fù)責(zé)持久化和緩存數(shù)據(jù)；
- 8）ZZMQ負(fù)責(zé)對(duì)平臺(tái)的業(yè)務(wù)系統(tǒng)和IM系統(tǒng)，以及Logic和Extlogic之間進(jìn)行解耦。
轉(zhuǎn)轉(zhuǎn)IM的系統(tǒng)架構(gòu)具有伸縮性、高可用、可靠性、功能擴(kuò)展性和高性能。
15、參考資料
[1] 淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)
[2] 簡(jiǎn)述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端
[3] 一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)
[4] 一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案
[5] 從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程
[6] 蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇
[7] 現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討
[8] 一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐
[9] 馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路
[10] 瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)（整理自現(xiàn)場(chǎng)演講，有配套PPT）
[11] 阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過人之處
[12] 一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等
[13] 從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)
[14] 閑魚億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路
[15] 基于實(shí)踐：一套百萬消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)
[16] 一套十萬級(jí)TPS的IM綜合消息系統(tǒng)的架構(gòu)實(shí)踐與思考
[17] vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實(shí)踐
[18] 一套分布式IM即時(shí)通訊系統(tǒng)的技術(shù)選型和架構(gòu)設(shè)計(jì)
[19] 微信團(tuán)隊(duì)分享：來看看微信十年前的IM消息收發(fā)架構(gòu)，你做到了嗎
[20] 攜程技術(shù)分享：億級(jí)流量的辦公I(xiàn)M及開放平臺(tái)技術(shù)實(shí)踐
（本文已同步發(fā)布于：http://www.52im.net/thread-4764-1-1.html）