咚咚是什麼？咚咚之于京東相當于旺旺之于淘寶，它們都是服務于買家和賣家的溝通。 自從京東開始為第三方賣家提供入駐平台服務後，咚咚也就随之誕生了。 我們首先看看它誕生之初是什麼樣的。
為了業務的快速上線，1.0 版本的技術架構實作是非常直接且簡單粗暴的。 如何簡單粗暴法？請看架構圖，如下。
1.0 的功能十分簡單，實作了一個 IM 的基本功能，接入、互通消息和狀态。 另外還有客服功能，就是顧客接入咨詢時的客服配置設定，按輪詢方式把顧客配置設定給線上的客服接待。 用開源 Mina 架構實作了 TCP 的長連接配接接入，用 Tomcat Comet 機制實作了 HTTP 的長輪詢服務。 而消息投遞的實作是一端發送的消息臨時存放在 Redis 中，另一端拉取的生産消費模型。
這個模型的做法導緻需要以一種高頻率的方式來輪詢 Redis 周遊屬于自己連接配接的關聯會話消息。 這個模型很簡單，簡單包括多個層面的意思：了解起來簡單；開發起來簡單；部署起來也簡單。 隻需要一個 Tomcat 應用依賴一個共享的 Redis，簡單的實作核心業務功能，并支援業務快速上線。
但這個簡單的模型也有些嚴重的缺陷，主要是效率和擴充問題。 輪詢的頻率間隔大小基本決定了消息的延時，輪詢越快延時越低，但輪詢越快消耗也越高。 這個模型實際上是一個高功耗低效能的模型，因為不活躍的連接配接在那做高頻率的無意義輪詢。 高頻有多高呢，基本在 100 ms 以内，你不能讓輪詢太慢，比如超過 2 秒輪一次，人就會在聊天過程中感受到明顯的會話延遲。 随着線上人數增加，輪詢的耗時也線性增長，是以這個模型導緻了擴充能力和承載能力都不好，一定會随着線上人數的增長碰到性能瓶頸。
1.0 的時代背景正是京東技術平台從 .NET 向 Java 轉型的年代，我也正是在這期間加入京東并參與了京東主站技術轉型架構更新的過程。 之後開始接手了京東咚咚，并持續完善這個産品，進行了三次技術架構演進。
我們剛接手時 1.0 已線上上運作并支援京東 POP（開放平台）業務，之後京東打算組建自營線上客服團隊并落地在成都。 不管是自營還是 POP 客服咨詢業務當時都起步不久，1.0 架構中的性能和效率缺陷問題還沒有達到引爆的業務量級。 而自營客服當時還處于起步階段，客服人數不足，服務能力不夠，顧客咨詢量遠遠超過客服的服務能力。 超出服務能力的顧客咨詢，當時我們的系統統一傳回提示客服繁忙，請稍後咨詢。 這種狀況導緻高峰期大量顧客無論怎麼重新整理請求，都很可能無法接入客服，體驗很差。 是以 2.0 重點放在了業務功能體驗的提升上，如下圖所示。
針對無法及時提供服務的顧客，可以排隊或者留言。 針對純文字溝通，提供了檔案和圖檔等更豐富的表達方式。 另外支援了客服轉接和快捷回複等方式來提升客服的接待效率。 總之，整個 2.0 就是圍繞提升客服效率和使用者體驗。 而我們擔心的效率問題在 2.0 高速發展業務的時期還沒有出現，但業務量正在逐漸積累，我們知道它快要爆了。 到 2012 年末，度過雙十一後開始了 3.0 的一次重大架構更新。
經曆了 2.0 時代一整年的業務高速發展，實際上代碼規模膨脹的很快。 與代碼一塊膨脹的還有團隊，從最初的 4 個人到近 30 人。 團隊大了後，一個系統多人開發，開發人員層次不一，規範難統一，系統子產品耦合重，改動溝通和依賴多，上線風險難以控制。 一個單獨 tomcat 應用多執行個體部署模型終于走到頭了，這個版本架構更新的主題就是服務化。
服務化的第一個問題如何把一個大的應用系統切分成子服務系統。 當時的背景是京東的部署還在半自動化年代，自動部署系統剛起步，子服務系統若按業務劃分太細太多，部署工作量很大且難管理。 是以當時我們不是按業務功能分區服務的，而是按業務重要性級别劃分了 0、1、2 三個級别不同的子業務服務系統。 另外就是獨立了一組接入服務，針對不同管道和通信方式的接入端，見下圖。
更細化的應用服務和架構分層方式可見下圖。
這次大的架構更新，主要考慮了三個方面：穩定性、效率和容量。 做了下面這些事情：
業務分級、核心、非核心業務隔離
多機房部署，流量分流、容災備援、峰值應對備援
讀庫多源，失敗自動轉移
寫庫主備，短暫有損服務容忍下的快速切換
外部接口，失敗轉移或快速斷路
Redis 主備，失敗轉移
大表遷移，MongoDB 取代 MySQL 存儲消息記錄
改進消息投遞模型
前 6 條基本屬于考慮系統穩定性、可用性方面的改進更新。 這一塊屬于陸續疊代完成的，承載很多失敗轉移的配置和控制功能在上面圖中是由管控中心提供的。 第 7 條主要是随着業務量的上升，單日消息量越來越大後，使用了 MongoDB 來單獨存儲量最大的聊天記錄。 第 8 條是針對 1.0 版本消息輪詢效率低的改進，改進後的投遞方式如下圖所示：
不再是輪詢了，而是讓終端每次建立連接配接後注冊接入點位置，消息投遞前定位連接配接所在接入點位置再推送過去。 這樣投遞效率就是恒定的了，而且很容易擴充，線上人數越多則連接配接數越多，隻需要擴充接入點即可。 其實，這個模型依然還有些小問題，主要出在離線消息的處理上，可以先思考下，我們最後再講。
3.0 經過了兩年的疊代式更新，單純從業務量上來說還可以繼續支撐很長時間的增長。 但實際上到 2014 年底我們面對的不再是業務量的問題，而是業務模式的變化。 這直接導緻了一個全新時代的到來。
2014 年京東的組織架構發生了很大變化，從一個公司變成了一個集團，下設多個子公司。 原來的商城成為了其中一個子公司，新成立的子公司包括京東金融、京東智能、京東到家、拍拍、海外事業部等。 各自業務範圍不同，業務模式也不同，但不管什麼業務總是需要客服服務。 如何複用原來為商城量身訂做的咚咚客服系統并支援其他子公司業務快速接入成為我們新的課題。
最早要求接入的是拍拍網，它是從騰訊收購的，是以是完全不同的賬戶和訂單交易體系。 由于時間緊迫，我們把為商城訂做的部分剝離，基于 3.0 架構對接拍拍又單獨訂做了一套，并獨立部署，像下面這樣。
雖然在業務要求的時間點前完成了上線，但這樣做也帶來了明顯的問題：
複制工程，定制業務開發，多套源碼維護成本高
獨立部署，至少雙機房主備外加一個灰階叢集，資源浪費大
以前我們都是面向業務去架構系統，如今新的業務變化形勢下我們開始考慮面向平台去架構，在統一平台上跑多套業務，統一源碼，統一部署，統一維護。 把業務服務繼續拆分，剝離出最基礎的 IM 服務，IM 通用服務，客服通用服務，而針對不同的業務特殊需求做最小化的定制服務開發。 部署方式則以平台形式部署，不同的業務方的服務跑在同一個平台上，但資料互相隔離。 服務繼續被拆分的更微粒化，形成了一組服務矩陣（見下圖）。
而部署方式，隻需要在雙機房建立兩套對等叢集，并另外建一個較小的灰階釋出叢集即可，所有不同業務都運作在統一平台叢集上，如下圖。
更細粒度的服務意味着每個服務的開發更簡單，代碼量更小，依賴更少，隔離穩定性更高。 但更細粒度的服務也意味着更繁瑣的運維監控管理，直到今年公司内部彈性私有雲、緩存雲、消息隊列、部署、監控、日志等基礎系統日趨完善， 使得實施這類細粒度劃分的微服務架構成為可能，運維成本可控。 而從當初 1.0 的 1 種應用程序，到 3.0 的 6、7 種應用程序，再到 4.0 的 50+ 更細粒度的不同種應用程序。 每種程序再根據承載業務流量不同配置設定不同的執行個體數，真正的執行個體程序數會過千。 為了更好的監控和管理這些程序，為此專門定制了一套面向服務的運維管理系統，見下圖。
統一服務運維提供了實用的内部工具和庫來幫助開發更健壯的微服務。 包括中心配置管理，流量埋點監控，資料庫和緩存通路，運作時隔離，如下圖所示是一個運作隔離的圖示：
細粒度的微服務做到了程序間隔離，嚴格的開發規範和工具庫幫助實作了異步消息和異步 HTTP 來避免多個跨程序的同步長調用鍊。 程序内部通過切面方式引入了服務增強容器 Armor 來隔離線程， 并支援程序内的單獨業務降級和同步轉異步化執行。而所有這些工具和庫服務都是為了兩個目标：
讓服務程序運作時狀态可見
讓服務程序運作時狀态可被管理和改變
最後我們回到前文留下的一個懸念，就是關于消息投遞模型的缺陷。 一開始我們在接入層檢測到終端連接配接斷開後，消息無法投遞，再将消息緩存下來，等終端重連接配接上來再拉取離線消息。 這個模型在移動時代表現的很不好，因為移動網絡的不穩定性，導緻經常斷鍊後重連。 而準确的檢測網絡連接配接斷開是依賴一個網絡逾時的，導緻檢測可能不準确，引發消息假投遞成功。 新的模型如下圖所示，它不再依賴準确的網絡連接配接檢測，投遞前待确認消息 id 被緩存，而消息體被持久存儲。 等到終端接收确認傳回後，該消息才算投妥，未确認的消息 id 再重新登陸後或重連接配接後作為離線消息推送。 這個模型不會産生消息假投妥導緻的丢失，但可能導緻消息重複，隻需由客戶終端按消息 id 去重即可。
京東咚咚誕生之初正是京東技術轉型到 Java 之時，經曆這些年的發展，取得了很大的進步。 從草根走向專業，從弱小走向規模，從分散走向統一，從雜亂走向規範。 本文主要重心放在了幾年來咚咚架構演進的過程，技術架構單獨拿出來看我認為沒有絕對的好與不好， 技術架構總是要放在彼時的背景下來看，要考慮業務的時效價值、團隊的規模和能力、環境基礎設施等等方面。 架構演進的生命周期适時比對好業務的生命周期，才可能發揮最好的效果。