[[158634]]

咚咚是什么？咚咚之于京東相當于旺旺之于淘寶，它們都是服務于買家和賣家的溝通。 自從京東開始為第三方賣家提供入駐平臺服務后，咚咚也就隨之誕生了。 我們首先看看它誕生之初是什么樣的。

1.0 誕生（2010 – 2011)

為了業務的快速上線，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.0 就是圍繞提升客服效率和用戶體驗。 而我們擔心的效率問題在 2.0 高速發展業務的時期還沒有出現，但業務量正在逐漸積累，我們知道它快要爆了。 到 2012 年末，度過雙十一后開始了 3.0 的一次重大架構升級。

3.0 爆發（2013 – 2014）

經歷了 2.0 時代一整年的業務高速發展，實際上代碼規模膨脹的很快。 與代碼一塊膨脹的還有團隊，從最初的 4 個人到近 30 人。 團隊大了后，一個系統多人開發，開發人員層次不一，規范難統一，系統模塊耦合重，改動溝通和依賴多，上線風險難以控制。 一個單獨 tomcat 應用多實例部署模型終于走到頭了，這個版本架構升級的主題就是服務化。

服務化的第一個問題如何把一個大的應用系統切分成子服務系統。 當時的背景是京東的部署還在半自動化年代，自動部署系統剛起步，子服務系統若按業務劃分太細太多，部署工作量很大且難管理。 所以當時我們不是按業務功能分區服務的，而是按業務重要性級別劃分了 0、1、2 三個級別不同的子業務服務系統。 另外就是獨立了一組接入服務，針對不同渠道和通信方式的接入端，見下圖。

更細化的應用服務和架構分層方式可見下圖。

這次大的架構升級，主要考慮了三個方面：穩定性、效率和容量。 做了下面這些事情：

1. 業務分級、核心、非核心業務隔離

2. 多機房部署，流量分流、容災冗余、峰值應對冗余

3. 讀庫多源，失敗自動轉移

4. 寫庫主備，短暫有損服務容忍下的快速切換

5. 外部接口，失敗轉移或快速斷路

6. Redis 主備，失敗轉移

7. 大表遷移，MongoDB 取代 MySQL 存儲消息記錄

8. 改進消息投遞模型

前 6 條基本屬于考慮系統穩定性、可用性方面的改進升級。 這一塊屬于陸續迭代完成的，承載很多失敗轉移的配置和控制功能在上面圖中是由管控中心提供的。 第 7 條主要是隨著業務量的上升，單日消息量越來越大后，使用了 MongoDB 來單獨存儲量最大的聊天記錄。 第 8 條是針對 1.0 版本消息輪詢效率低的改進，改進后的投遞方式如下圖所示：

不再是輪詢了，而是讓終端每次建立連接后注冊接入點位置，消息投遞前定位連接所在接入點位置再推送過去。 這樣投遞效率就是恒定的了，而且很容易擴展，在線人數越多則連接數越多，只需要擴展接入點即可。 其實，這個模型依然還有些小問題，主要出在離線消息的處理上，可以先思考下，我們最后再講。

3.0 經過了兩年的迭代式升級，單純從業務量上來說還可以繼續支撐很長時間的增長。 但實際上到 2014 年底我們面對的不再是業務量的問題，而是業務模式的變化。 這直接導致了一個全新時代的到來。

4.0 涅槃（2015 至今 )

2014 年京東的組織架構發生了很大變化，從一個公司變成了一個集團，下設多個子公司。 原來的商城成為了其中一個子公司，新成立的子公司包括京東金融、京東智能、京東到家、拍拍、海外事業部等。 各自業務范圍不同，業務模式也不同，但不管什么業務總是需要客服服務。 如何復用原來為商城量身訂做的咚咚客服系統并支持其他子公司業務快速接入成為我們新的課題。

最早要求接入的是拍拍網，它是從騰訊收購的，所以是完全不同的賬戶和訂單交易體系。 由于時間緊迫，我們把為商城訂做的部分剝離，基于 3.0 架構對接拍拍又單獨訂做了一套，并獨立部署，像下面這樣。

雖然在業務要求的時間點前完成了上線，但這樣做也帶來了明顯的問題：

1. 復制工程，定制業務開發，多套源碼維護成本高

2. 獨立部署，至少雙機房主備外加一個灰度集群，資源浪費大

以前我們都是面向業務去架構系統，如今新的業務變化形勢下我們開始考慮面向平臺去架構，在統一平臺上跑多套業務，統一源碼，統一部署，統一維護。 把業務服務繼續拆分，剝離出最基礎的 IM 服務，IM 通用服務，客服通用服務，而針對不同的業務特殊需求做最小化的定制服務開發。 部署方式則以平臺形式部署，不同的業務方的服務跑在同一個平臺上，但數據互相隔離。 服務繼續被拆分的更微粒化，形成了一組服務矩陣（見下圖）。

而部署方式，只需要在雙機房建立兩套對等集群，并另外建一個較小的灰度發布集群即可，所有不同業務都運行在統一平臺集群上，如下圖。

更細粒度的服務意味著每個服務的開發更簡單，代碼量更小，依賴更少，隔離穩定性更高。 但更細粒度的服務也意味著更繁瑣的運維監控管理，直到今年公司內部彈性私有云、緩存云、消息隊列、部署、監控、日志等基礎系統日趨完善， 使得實施這類細粒度劃分的微服務架構成為可能，運維成本可控。 而從當初 1.0 的 1 種應用進程，到 3.0 的 6、7 種應用進程，再到 4.0 的 50+ 更細粒度的不同種應用進程。 每種進程再根據承載業務流量不同分配不同的實例數，真正的實例進程數會過千。 為了更好的監控和管理這些進程，為此專門定制了一套面向服務的運維管理系統，見下圖。

統一服務運維提供了實用的內部工具和庫來幫助開發更健壯的微服務。 包括中心配置管理，流量埋點監控，數據庫和緩存訪問，運行時隔離，如下圖所示是一個運行隔離的圖示：

細粒度的微服務做到了進程間隔離，嚴格的開發規范和工具庫幫助實現了異步消息和異步 HTTP 來避免多個跨進程的同步長調用鏈。 進程內部通過切面方式引入了服務增強容器 Armor 來隔離線程， 并支持進程內的單獨業務降級和同步轉異步化執行。而所有這些工具和庫服務都是為了兩個目標：

1. 讓服務進程運行時狀態可見

2. 讓服務進程運行時狀態可被管理和改變

最后我們回到前文留下的一個懸念，就是關于消息投遞模型的缺陷。 一開始我們在接入層檢測到終端連接斷開后，消息無法投遞，再將消息緩存下來，等終端重連接上來再拉取離線消息。 這個模型在移動時代表現的很不好，因為移動網絡的不穩定性，導致經常斷鏈后重連。 而準確的檢測網絡連接斷開是依賴一個網絡超時的，導致檢測可能不準確，引發消息假投遞成功。 新的模型如下圖所示，它不再依賴準確的網絡連接檢測，投遞前待確認消息 id 被緩存，而消息體被持久存儲。 等到終端接收確認返回后，該消息才算投妥，未確認的消息 id 再重新登陸后或重連接后作為離線消息推送。 這個模型不會產生消息假投妥導致的丟失，但可能導致消息重復，只需由客戶終端按消息 id 去重即可。

京東咚咚誕生之初正是京東技術轉型到 Java 之時，經歷這些年的發展，取得了很大的進步。 從草根走向專業，從弱小走向規模，從分散走向統一，從雜亂走向規范。 本文主要重心放在了幾年來咚咚架構演進的過程，技術架構單獨拿出來看我認為沒有絕對的好與不好， 技術架構總是要放在彼時的背景下來看，要考慮業務的時效價值、團隊的規模和能力、環境基礎設施等等方面。 架構演進的生命周期適時匹配好業務的生命周期，才可能發揮最好的效果。