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