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