京東通天塔——京東中間件如何支撐起每一場大促

每次大促都是考驗各電商架構的最好時機，然而一般電商大促時，我們可能更關注系統架構如何降級如何限流等經典手段。這次換個視角，中間件在《京東技術解密》一書中被京東喻為大促通天塔，而京東作為中國互聯網電商主角之一，我們看看中間件技術如何撐起京東每一場大促的。

InfoQ：您擁有18年的研發經驗，能否介紹這段時間自己的程序員經歷？是否面臨過幾次關鍵選擇？

何小鋒：18年，一直沒有脫離Coding，積累了很多的系統架構經驗，在2011年加入京東，被京東面臨的技術挑戰所吸引。整個coding生涯中有過2次關鍵選擇：

1. 從傳統的電子政務行業轉到互聯網行業；

2. 選擇了京東，給自己一個挑戰發揮的平臺。

由于自己很喜歡技術，而且喜歡中間件、高并發分布式和彈性計算這三大領域本身帶來的技術挑戰，目前這些技術已經是公司的核心支撐系統，是京東抗大流量的關鍵。

另外這幾大領域需要掌握軟件、操作系統、硬件和網絡等多方面的知識才能更上一層樓，并且有很多需要專研的地方，需要長時間的專注才能做好。

InfoQ：中間件技術部門承擔了怎樣的任務和職責？落地基于Docker的彈性云給部門帶來怎樣的影響？

何小鋒：中間件技術部門承擔中間件研發和運維支持工作，確保現有系統穩定，持續優化滿足業務需求，跟進業界技術發展，孵化新的中間件產品解決業務問題。

目前京東中間件最核心的3大產品如下：

1. JSF，自主研發高性能分布式的RPC微服務框架，是京東服務化、開放化的技術標準；

2. JIMDB，自主研發高性能分布式的緩存，基于Docker架構，具有彈性伸縮、快速故障遷移等能力；

3. JMQ，自主研發的高性能分布式的消息隊列

彈性云落地對中間件研發架構有很大的促進，JIMDB基于Docker實現彈性伸縮能力。另外中間件還要適應容器的環境，如準確獲取CPU數量便于控制線程數，避免頻繁的線程切換。流量均勻也是后續要改善的方向，容器的規格小，前后申請不一致，物理機硬件配置不一樣，造成每個實例的承載能力不一樣，需要中間件能自動負載均勻。

InfoQ：目前京東微服務框架JSF調用規模在日常和大促時分別處于什么量級，JSF的主要核心部件如何實現高可用？

何小鋒：JSF日常調用在千億規模，大促期間會翻2-5倍。

實現高可用方面，以注冊中心為例，注冊中心以異步持久化到數據庫中，通過本地全量緩存來提升性能，節點直接通過事件總線同步，可以做到橫向擴容。如果數據庫宕機，可以通過緩存繼續提供讀取服務。

另外每個機房都會部署若干節點，客戶端通過目錄服務優先拿到本機房的注冊中心節點列表，后續通過定時更新注冊中心列表。

當服務有變化的時候，注冊中心回調客戶端，推送變化給客戶端，客戶端會在內存中緩存一份服務地址，在本地會存儲一些備份文件。如果注冊中心連接不上，客戶端可以依賴本地緩存繼續調用。

監控中心提供的是JSF服務，數據直接通過ES存儲。

實現高可用過程中為了 深挖單實例性能 ，我們做了優化序列化協議，傳輸數據進行壓縮，并且通過RingBuffer進行組提交，采用NIO/EPOLL，優化線程模型，提升并發能力。

InfoQ：JSF目前是否還存在瓶頸？

何小鋒：JSF到目前已經很成熟，性能、穩定性和易用性都很高。

JSF提供了強大的服務治理功能，包括常見的分組、上下線、黑白名單、路由等，也做到了例如動態分組、同機房優先、配置下發、調用限流、授權調用等等功能，并且開放了部分服務治理API，供開發者自行調用。

JSF未來會持續在治理和監控上進行改進，完善分布式跟蹤，便于快速定位問題。另外HTTP網關會通過支持HTTP/2協議來優化性能。

InfoQ：目前京東消息中間件從開源軟件的JQ、ActiveMQ發展到自研的JMQ，能否簡述這段演進過程？基于怎樣的判斷和背景會開始對下一代的籌備？

何小鋒：JQ嚴格意義上來說還算不上一個消息中間件，它基于數據庫實現，當時的用戶也比較少。

隨著公司SOA化工作開展，迫切需要成熟的高可用消息中間件來支持，我們采用開源的ActiveMQ來作為第一代分布式消息平臺。在其基礎上做了一系列的平臺化改造，包括應用治理、監控報警、分布式客戶端、歸檔、重試、存儲復制，我們對這些功能也進行了優化和更新。

隨著業務量的快速增長，它的性能成了很大的瓶頸，存儲邏輯復雜，消息積壓后對性能影響很大，已經很難進行優化。通過積累的研發和運營經驗，我們決定自助研發JMQ。 JMQ在存儲、網絡通信、消息處理、數據復制等方面進行了很大的優化改進 。另外在升級的過程中，考慮了兼容性，例如JMQ兼容AMQ客戶端協議，做到了平滑過渡。

為什么沒有一步到位？每一代消息中間件都是基于業務的發展需要的，京東這些年發展之快，業務又有其不確定性，所以我們在這過程中也是不斷的探索，不斷的重構。

至于何時開始下一代消息中間件的籌備，我們會主要基于高可用、性能和自動化運維瓶頸等方面考量。JMQ我們目前正在做 兼容Kafka協議 ，大幅提升自動化運維能力，減少備戰工作。

InfoQ：以您的判斷來看，互聯網企業是否會逐漸擺脫開源軟件的依賴，走向自主研發以獲得徹底的掌控力？

何小鋒：這個是根據業務發展的需要的，成熟穩定的開源系統還會持續支撐，滿足不了需求的開源軟件會逐步被自研替換。我的建議是控制好收益，加強內外交流，最后要回饋開源社區。

InfoQ：JMQ在大促時能處理多少的寫入、投遞高峰？后端消費不穩定的情況下如何保證消息投放穩定？

何小鋒：JMQ在大促時單個分片同步復制和刷到磁盤，能達到寫入1K消息，TPS可以超過4萬每秒。針對日志等場景，通過 配置異步復制和刷盤 還可以大幅度提升性能。我們預計整個平臺，雙11當天消息投遞量會達到千億規模。

消費者采用拉模型，處理速度完全由消費者控制，如果處理速度慢，消息會保留在服務端，保留時間為2天。由于大促的需要，每個系統都會進行大流量壓測軍演，不會存在2天都消費不了的消息。

JMQ的存儲模型，消息積壓在服務端，對寫入和消費性能沒有影響。積壓了會給用戶進行報警，如果存儲空間不夠了，會停用當前實例的寫入，進行擴容。

InfoQ：能否談談在大促期間中間件團隊所做的工作？在接下來的大促會做哪些準備和調整？以前的大促遇到過哪些問題以及應對方案？

何小鋒：中間件會成立專門的項目來推薦大促的備戰工作，主要包括如下幾塊工作

1. 系統梳理工作：整理現有部署架構，核心客戶，每日巡檢；

2. 部署擴容：資源評估、核心客戶擴容、容災部署；

3. 應急預案：整理和評估應急預案；

4. 壓測演練：模擬故障演練，性能壓測；

5. 對發現的問題就改進優化；

6. 24小時值班監控

每次大促發現的問題都會作為后續研發改進的需求，例如AMQ性能不好，后續自研JMQ。

面對以后的大促，我們會大幅提升自動化運維來滿足大促的需求，包括彈性擴容，更豐富的監控報警，更迅速可控的故障切換、自動化容災、核心客戶物理隔離等等。

另外隨著業務的發展，如何更好地支持業務海量數據緩存需求，我們也在規劃新版的JIMDB。

InfoQ：能否簡單概述自動擴容縮容中數據遷移的技術原理？中間件實現快速故障切換和彈性伸縮能力的難點在哪里，最后如何解決的？

何小鋒：JIMDB提供 基于Docker的彈性伸縮能力 。目前JIMDB一個分片有2G內存數據，當需要遷移時，節點會先把已有的數據按照一定的規則全量復制一份到新的shard上，在全量復制過程中會有增量的數據產生，這部分數據另外保存一份到指定的緩沖區中，當全量復制完成后馬上同步緩沖區中的數據，當緩存區中需要同步的數據比較少時，會阻塞待分裂節點的寫入直到增量數據也同步完成。

快速故障切換和彈性伸縮能力的難點主要如下：

1.準確及時的故障定位，包括軟件宕機、網絡、硬件等方面的故障。我們通過Agent秒級采集監控數據，對新出現的故障通過錄入關鍵詞來自動學習，宕機/網絡不通則 采用多個決策者投票 決定。

2.資源的合理調度，包括容災，確保資源調度均勻、并發控制，核心業務做到隔離，相關的具體實踐有：

• 應用接入的時候要完善信息，能識別是否是核心業務，是否需要隔離，業務的吞吐量需求等等;

• 通過資源標簽來匹配滿足業務的資源;

• 通過識別機房、機架信息來滿足容災的需求;

• 通過資源樂觀鎖來實現對相同資源的并發控制;

 

 

來自：http://www.infoq.com/cn/news/2016/11/Jingdong-middleware-support-prom