摘要：自從京東開始為第三方賣家提供入駐平臺服務(wù)后，咚咚也就隨之誕生了。之后開始接手了京東咚咚，并持續(xù)完善這個產(chǎn)品，進(jìn)行了三次技術(shù)架構(gòu)演進(jìn)。涅槃至今年京東的組織架構(gòu)發(fā)生了很大變化，從一個公司變成了一個集團(tuán)，下設(shè)多個子公司。

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

為了業(yè)務(wù)的快速上線，1.0 版本的技術(shù)架構(gòu)實(shí)現(xiàn)是非常直接且簡單粗暴的。 如何簡單粗暴法？請看架構(gòu)圖，如下。

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)。

我們剛接手時 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)的提升上，如下圖所示。

針對無法及時提供服務(wù)的顧客，可以排隊(duì)或者留言。 針對純文字溝通，提供了文件和圖片等更豐富的表達(dá)方式。 另外支持了客服轉(zhuǎn)接和快捷回復(fù)等方式來提升客服的接待效率。 總之，整個 2.0 就是圍繞提升客服效率和用戶體驗(yàn)。 而我們擔(dān)心的效率問題在 2.0 高速發(fā)展業(yè)務(wù)的時期還沒有出現(xiàn)，但業(yè)務(wù)量正在逐漸積累，我們知道它快要爆了。 到 2012 年末，度過雙十一后開始了 3.0 的一次重大架構(gòu)升級。

經(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)險難以控制。 一個多帶帶 tomcat 應(yīng)用多實(shí)例部署模型終于走到頭了，這個版本架構(gòu)升級的主題就是服務(wù)化。

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

更細(xì)化的應(yīng)用服務(wù)和架構(gòu)分層方式可見下圖。

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

業(yè)務(wù)分級、核心、非核心業(yè)務(wù)隔離

多機(jī)房部署，流量分流、容災(zāi)冗余、峰值應(yīng)對冗余

讀庫多源，失敗自動轉(zhuǎn)移

寫庫主備，短暫有損服務(wù)容忍下的快速切換

外部接口，失敗轉(zhuǎn)移或快速斷路

Redis 主備，失敗轉(zhuǎn)移

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

改進(jìn)消息投遞模型

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

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

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

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

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

雖然在業(yè)務(wù)要求的時間點(diǎn)前完成了上線，但這樣做也帶來了明顯的問題：

復(fù)制工程，定制業(yè)務(wù)開發(fā)，多套源碼維護(hù)成本高

獨(dú)立部署，至少雙機(jī)房主備外加一個灰度集群，資源浪費(fèi)大

以前我們都是面向業(yè)務(wù)去架構(gòu)系統(tǒng)，如今新的業(yè)務(wù)變化形勢下我們開始考慮面向平臺去架構(gòu)，在統(tǒng)一平臺上跑多套業(yè)務(wù)，統(tǒng)一源碼，統(tǒng)一部署，統(tǒng)一維護(hù)。 把業(yè)務(wù)服務(wù)繼續(xù)拆分，剝離出最基礎(chǔ)的 IM 服務(wù)，IM 通用服務(wù)，客服通用服務(wù)，而針對不同的業(yè)務(wù)特殊需求做最小化的定制服務(wù)開發(fā)。 部署方式則以平臺形式部署，不同的業(yè)務(wù)方的服務(wù)跑在同一個平臺上，但數(shù)據(jù)互相隔離。 服務(wù)繼續(xù)被拆分的更微?；纬闪艘唤M服務(wù)矩陣（見下圖）。

而部署方式，只需要在雙機(jī)房建立兩套對等集群，并另外建一個較小的灰度發(fā)布集群即可，所有不同業(yè)務(wù)都運(yùn)行在統(tǒng)一平臺集群上，如下圖。

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

統(tǒng)一服務(wù)運(yùn)維提供了實(shí)用的內(nèi)部工具和庫來幫助開發(fā)更健壯的微服務(wù)。 包括中心配置管理，流量埋點(diǎn)監(jiān)控，數(shù)據(jù)庫和緩存訪問，運(yùn)行時隔離，如下圖所示是一個運(yùn)行隔離的圖示：

細(xì)粒度的微服務(wù)做到了進(jìn)程間隔離，嚴(yán)格的開發(fā)規(guī)范和工具庫幫助實(shí)現(xiàn)了異步消息和異步 HTTP 來避免多個跨進(jìn)程的同步長調(diào)用鏈。 進(jìn)程內(nèi)部通過切面方式引入了服務(wù)增強(qiáng)容器 Armor 來隔離線程， 并支持進(jìn)程內(nèi)的多帶帶業(yè)務(wù)降級和同步轉(zhuǎn)異步化執(zhí)行。而所有這些工具和庫服務(wù)都是為了兩個目標(biāo)：

讓服務(wù)進(jìn)程運(yùn)行時狀態(tài)可見

讓服務(wù)進(jìn)程運(yùn)行時狀態(tài)可被管理和改變

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

京東咚咚誕生之初正是京東技術(shù)轉(zhuǎn)型到 Java 之時，經(jīng)歷這些年的發(fā)展，取得了很大的進(jìn)步。 從草根走向?qū)I(yè)，從弱小走向規(guī)模，從分散走向統(tǒng)一，從雜亂走向規(guī)范。 本文主要重心放在了幾年來咚咚架構(gòu)演進(jìn)的過程，技術(shù)架構(gòu)多帶帶拿出來看我認(rèn)為沒有絕對的好與不好， 技術(shù)架構(gòu)總是要放在彼時的背景下來看，要考慮業(yè)務(wù)的時效價值、團(tuán)隊(duì)的規(guī)模和能力、環(huán)境基礎(chǔ)設(shè)施等等方面。 架構(gòu)演進(jìn)的生命周期適時匹配好業(yè)務(wù)的生命周期，才可能發(fā)揮最好的效果。

寫點(diǎn)程序世間的文字，畫點(diǎn)生活瞬間的畫兒。
微信公眾號「瞬息之間」，遇見了不妨就關(guān)注看看。