京東咚咚架構演進

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

 

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