京東IM工具的架構(gòu)演進(jìn)
大小：0.3 MB 人氣： 2017-10-12 需要積分：1
推薦 + 挑錯(cuò) + 收藏(0) + 用戶評(píng)論（0）
標(biāo)簽：im工具(1797)
咚咚是什么？咚咚之于京東相當(dāng)于旺旺之于淘寶，它們都是服務(wù)于買(mǎi)家和賣(mài)家的溝通工具。 自從京東開(kāi)始為第三方賣(mài)家提供入駐平臺(tái)服務(wù)后，咚咚也就隨之誕生了。我們首先看看它誕生之初是什么樣的。1.0 誕生（2010 - 2011）
為了業(yè)務(wù)的快速上線，1.0 版本的技術(shù)架構(gòu)實(shí)現(xiàn)是非常直接且簡(jiǎn)單粗暴的。 如何簡(jiǎn)單粗暴法？請(qǐng)看架構(gòu)圖，如下。
圖 1 - 1.0 功能模塊交互圖
1.0 的功能十分簡(jiǎn)單，實(shí)現(xiàn)了一個(gè) IM 的基本功能，接入、互通消息和狀態(tài)。 另外還有客服功能，就是顧客接入咨詢時(shí)的客服分配，按輪詢方式把顧客分配給在線的客服接待。 用開(kāi)源 Mina 框架實(shí)現(xiàn)了 TCP 的長(zhǎng)連接接入，用 Tomcat Comet 機(jī)制實(shí)現(xiàn)了 HTTP 的長(zhǎng)輪詢服務(wù)。 而消息投遞的實(shí)現(xiàn)是一端發(fā)送的消息臨時(shí)存放在 Redis 中，另一端拉取的生產(chǎn)消費(fèi)模型。
這個(gè)模型的做法導(dǎo)致需要以一種高頻率的方式來(lái)輪詢 Redis 遍歷屬于自己連接的關(guān)聯(lián)會(huì)話消息。 這個(gè)模型很簡(jiǎn)單，簡(jiǎn)單包括多個(gè)層面的意思：理解起來(lái)簡(jiǎn)單；開(kāi)發(fā)起來(lái)簡(jiǎn)單；部署起來(lái)也簡(jiǎn)單。 只需要一個(gè) Tomcat 應(yīng)用依賴一個(gè)共享的 Redis，簡(jiǎn)單的實(shí)現(xiàn)核心業(yè)務(wù)功能，并支持業(yè)務(wù)快速上線。
但這個(gè)簡(jiǎn)單的模型也有些嚴(yán)重的缺陷，主要是效率和擴(kuò)展問(wèn)題。 輪詢的頻率間隔大小基本決定了消息的延時(shí)，輪詢?cè)娇煅訒r(shí)越低，但輪詢?cè)娇煜囊苍礁摺?這個(gè)模型實(shí)際上是一個(gè)高功耗低效能的模型，因?yàn)椴换钴S的連接在那做高頻率的無(wú)意義輪詢。 高頻有多高呢，基本在 100 ms 以內(nèi)，你不能讓輪詢太慢，比如超過(guò) 2 秒輪一次，人就會(huì)在聊天過(guò)程中感受到明顯的會(huì)話延遲。 隨著在線人數(shù)增加，輪詢的耗時(shí)也線性增長(zhǎng)，因此這個(gè)模型導(dǎo)致了擴(kuò)展能力和承載能力都不好，一定會(huì)隨著在線人數(shù)的增長(zhǎng)碰到性能瓶頸。
咚咚1.0 的時(shí)代背景正是京東技術(shù)平臺(tái)從 .NET 向 Java 轉(zhuǎn)型的年代，我也正是在這期間加入京東并參與了京東主站技術(shù)轉(zhuǎn)型架構(gòu)升級(jí)的過(guò)程。 之后開(kāi)始接手了京東咚咚，并持續(xù)完善這個(gè)產(chǎn)品，進(jìn)行了三次技術(shù)架構(gòu)演進(jìn)。
2.0 成長(zhǎng)（2012）
我們剛接手時(shí) 1.0 已在線上運(yùn)行并支持京東 POP（開(kāi)放平臺(tái)）業(yè)務(wù)，之后京東打算組建自營(yíng)在線客服團(tuán)隊(duì)并落地在成都。 不管是自營(yíng)還是 POP 客服咨詢業(yè)務(wù)當(dāng)時(shí)都起步不久，1.0 架構(gòu)中的性能和效率缺陷問(wèn)題還沒(méi)有達(dá)到引爆的業(yè)務(wù)量級(jí)。 而自營(yíng)客服當(dāng)時(shí)還處于起步階段，客服人數(shù)不足，服務(wù)能力不夠，顧客咨詢量遠(yuǎn)遠(yuǎn)超過(guò)客服的服務(wù)能力。 對(duì)于超出服務(wù)能力的顧客咨詢，當(dāng)時(shí)我們的系統(tǒng)統(tǒng)一返回提示客服繁忙，請(qǐng)稍后咨詢。 這種狀況導(dǎo)致高峰期大量顧客無(wú)論怎么刷新請(qǐng)求，都很可能無(wú)法接入客服，體驗(yàn)很差。 所以 2.0 重點(diǎn)放在了業(yè)務(wù)功能體驗(yàn)的提升上，如下圖所示。
圖 2 - 2.0 功能模塊交互圖
針對(duì)無(wú)法及時(shí)提供服務(wù)的顧客，可以排隊(duì)或者留言。 相比純文字溝通，提供了文件和圖片等更豐富的表達(dá)方式。 另外支持了客服轉(zhuǎn)接和快捷回復(fù)等方式來(lái)提升客服的接待效率。 總之，整個(gè) 2.0 就是圍繞提升客服效率和用戶體驗(yàn)。 而我們擔(dān)心的效率問(wèn)題在 2.0 高速發(fā)展業(yè)務(wù)的時(shí)期還沒(méi)有出現(xiàn)，但業(yè)務(wù)量正在逐漸積累，我們知道它快要爆了。 到 2012 年末，度過(guò)雙11后開(kāi)始了 3.0 的一次重大架構(gòu)升級(jí)。
3.0 爆發(fā)（2013 - 2014）
經(jīng)歷了 2.0 時(shí)代一整年的業(yè)務(wù)高速發(fā)展，實(shí)際上代碼規(guī)模膨脹得很快。 與代碼一塊膨脹的還有團(tuán)隊(duì)，從最初的 4 個(gè)人到近 30 人。 團(tuán)隊(duì)大了后，一個(gè)系統(tǒng)多人開(kāi)發(fā)，開(kāi)發(fā)人員層次不一，規(guī)范難統(tǒng)一，系統(tǒng)模塊耦合重，改動(dòng)溝通和依賴多，上線風(fēng)險(xiǎn)難以控制。 一個(gè)單獨(dú) tomcat 應(yīng)用多實(shí)例部署模型終于走到頭了，這個(gè)版本架構(gòu)升級(jí)的主題就是服務(wù)化。
非常好我支持^.^
(0) 0%
不好我反對(duì)
(0) 0%