京東咚咚架構演進

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

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

如果想學習Java工程化、高性能及分佈式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加Java進階群：582505643，群裡有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

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

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

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

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

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

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

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

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

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

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

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

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

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

京東峰值系統設計

有別於社交網絡、搜索和遊戲等網站，電商網站的用戶流量具有操作性強、隨時令變化等特點。在歐美國家，Black Friday和Cyber Monday標誌著節假日消費的高峰。影響電商流量峰值的主要因素是搶購、促銷和惡意攻擊，尤其是京東618店慶和雙11等大規模的促銷活動。高流量、高併發情況下，如何保證整個系統的可靠性和穩定性，是眾多電商企業研發團隊都在思考的問題。

京東電商系統的設計是圍繞系統穩定性、可靠性、高併發和可擴展性為核心開展的。如何在峰值來臨時，保證用戶有平滑流暢的體驗，且系統不會出現異常呢？我們先來看看京東系統的一些特點（圖1）。

圖1 系統架構龐大複雜

京東的業務種類繁多，涉及SKU幾千萬種，這使得系統龐大，外部需要對接供應商、消費者和第三方商家三大板塊。內部系統包括了商品供應鏈中除商品設計和生產外的幾乎所有環節，包括登錄、交易、後臺、供應鏈、倉配、客服等。所有這些涉及大小系統幾千個，造就了一個極其複雜龐大的體系。除此之外，京東系統交互強，各個功能模塊之間關聯性強，牽一髮而動全身，做任何修改都需要慎之又慎。因此，一切優化方案都以保持系統穩定為前提。

為了在複雜的系統基礎之上，儘量緩解峰值帶來的壓力，京東峰值系統的設計主要從性能提升、流量控制、災備降級、壓測預案四個角度來進行。

性能提升

切分業務系統

我們先將整個業務體系拆分為幾個相對獨立的子系統如SSO、交易平臺、POP平臺、訂單下傳系統、WMS和倉儲配送（圖2）。每個子系統又可細分為若干部分，逐級簡化，直至可操作可優化的層級。例如，交易平臺包括價格、購物車、結算、支付和訂單中心等；網站系統包括首頁、登錄、列表頻道、單品和搜索等。接下來，針對每個功能模塊的關鍵部分進行切分，有針對性地做性能優化。

圖2 業務切分方案

例如，交易的秒殺系統，原來是根植於普通交易系統之內的，缺點非常明顯。當流量突然增大時，不僅會導致秒殺系統反應遲鈍，而且會影響普通交易系統的正常運作。於是我們將其與其他業務系統物理分開，成為相對獨立的子系統。並且針對秒殺的特性，減少對後臺存儲的依賴。同時優化中間層存儲機制，使得相對熱點分散部署。甚至支持單一SKU多點部署，從而大大提升了秒殺系統的吞吐量和可靠性。

分佈式

分佈式的交易系統是電商的未來。分佈式系統解決兩大難題：提高用戶體驗和增強容錯能力。由於分佈式系統設計時就會留有相當的流量增長空間，所以當一處數據中心飽和時，可以將其餘的流量切入其他相對寬鬆的數據中心去，從而達到互為備份、互相支持的目的。與此同時，由於為提供用戶就近服務，所以減少了網絡延時，頁面反應速度加快了。舉一個例子，Google搜索是全球服務，歐亞美各地都有不同的IP提供服務。當其中的某一個IP出現故障時，Google能夠從容地將其服務切換至最近的IP，繼續搜索服務。對於電商來說，情況更復雜一些，需要同步的數據要求更精確，數據量較大，對延時的容忍度更低，建設週期也就更長。京東正在此方面著力改進，從只讀的系統入手，一步一步實現系統的分佈式。

API服務化

在各個系統中，總是有很多相同的組件。前端的負載均衡自不必說，中間件的處理就是非常典型的例子。如何高效統一地管理這些組件，API服務化是我們的答案。最好由一個訓練有素的團隊集中管理這些組件並對外提供接口服務，將軟件的使用複雜性隱藏起來，調用的是簡單利索的API。讓專業人員去處理複雜邏輯，確保系統的可用性和擴展性，既能大大降低出錯概率，又能實現規模效益。

Redis是我們常用的緩存組件。 過去都是由各個業務實現團隊進行分別維護，專業性不強，使用多有不當之處。後來我們進行了集中管理，統一定製開發新功能和升級，並通過API服務化提供給各級用戶。這樣不僅豐富了應用場景，還提升了性能和可靠性。

架構，代碼優化

一個合理的電商系統架構是與一家公司的研發水平和技術管理水平密不可分的，這直接決定了可支撐峰值流量的多少和未來能達到的高度。選取適合自身發展的框架，既能充分發揮其效能，又可節約資源。代碼優化也能提高效能，例如對於SQL語句的優化，能更好地利用索引；Java/C++邏輯的優化，減少了不必要的循環和複雜的操作；算法優化，使之更高效；功能實現邏輯的優化，變得更簡潔和清晰；等等。但代碼優化終究不能衝破極限， 難以追求極致，適可為止為宜。

系統虛擬彈性化

當磁盤I/O不是瓶頸時，解決系統水平擴展就會變得容易許多。可以通過ZooKeeper或類ZooKeeper將軟件棧有機地串聯起來，並配以有效的性能監管。當事務處理成為瓶頸時，利用當今流行的虛擬化技術（如LXC或VM）可以在沒有人為干預的狀況下自動進行彈性擴展。