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