京東618技術解析之高可用多中心交易平臺

分流是應對互聯網業務流量峰值時保證系統高可用的常規方法，但涉及交易系統的分流是很難的。京東在備戰2015年618時就開始了多中心交易的改造，讓用戶就近訪問交易服務，并在2015年雙11之前完成了面向用戶的全部讀流量和小部分寫流量的多中心，而這次618備戰，京東又把交易流程涉及的幾乎所有系統的寫流量實現多中心架構。近日，京東商城交易平臺架構師肖飛接受CSDN記者專訪，介紹了京東交易平臺備戰618的技術挑戰、高可用架構的設計思路以及京東多中心架構的最新進展和具體實現。

京東多中心交易平臺有三個主要的目標：

• 在多個數據中心支持交易流程中讀流量和寫流量的水平擴容；
• 異地容災，任何一個中心出了故障之后，其全部的交易請求會被另外的中心無縫接管；
• 用戶體驗和性能優化，盡量規避異地的跨機房訪問延遲。

肖飛介紹，交易平臺在今年618備戰主要完成了三項任務：

幾乎所有的核心的交易流程所涉及的系統，以及寫流量的多中心的架構；

對支持多中心交易系統的底層核心數據庫復制中間件JingoBUS做了大量的工作，包括性能的優化和針對運維可視化的改進；

統一了交易流程中各個核心系統的流量可視化和故障切換（以前在分散各個系統里面分別實施），即把交易流程中的各種流量以及互相切換進行了一個標準化，以實現快速切換。

嘉賓簡介：

京東商城交易平臺架構師肖飛

肖飛于2011年8月份加入京東，曾親身參與到京東的應用性能監控、統一日志、流式計算、內存緩存、四層防攻擊等一些基礎技術平臺的研發和搭建工作，經歷了京東的技術系統從簡單粗放向復雜精細化的演變過程。目前主要工作為多中心交易項目中的數據復制中間件JingoBUS的研發。平時也會開發一些公共的平臺和工具，關注分布式系統的實現、程序設計、性能優化、開發語言等。

CSDN：京東經歷過了多次618和雙11，備戰的思路應該已經比較成熟，但京東的業務也在發展，今年618和之前的大促相比，技術挑戰有什么不同？

肖飛：如您所說，京東經歷了很多次大促了，現在備戰已經形成了一些套路。在大促之前兩三個月，會著重進行諸如系統容量預估、架構review和微調、風險點和監控點梳理、壓測和優化、各項預案的梳理和演練等工作。系統容量評估方面，各系統通過壓測來評估是否能夠支撐，無法滿足的要重點review，采取系統優化、擴容等方式來滿足，或根據系統情況準備限流或降級等預案。

大促期間，也就是緊盯監控，隨時應對各項突發事件。大促過后，我們會review大促過程中系統的各項性能指標，和先前的準備工作，查漏補缺，進行系統的下一個短期規劃（基本上是下一次的大促為目標）。數據增長量和容量方面，有些系統則會以2年或更長的時間來規劃。由于要不斷的滿足業務的各項需求和技術架構改造，系統到下一個大促前也會經歷比較多的變化，因此有必要按照上述列表重新梳理一遍，當然有些成熟的可以很快做完。

今年618的技術挑戰仍然是如何在保證大流量下的系統高可用。但是由于流量基礎越來越高，不能像以往的方式簡單地增加服務器資源來滿足系統峰值的需求。本次618，交易系統全面接入到Docker彈性云，以實現更便捷的進行擴容和縮容。另一方面，這給應用系統帶來的挑戰是，如何壓榨容器資源最大限度的滿足系統的性能指標。把物理機上混合部署的多實例應用，遷移到CPU隔離的容器上，促使我們做了一些合理的參數調整，配合壓測不斷優化。

CSDN：能否進一步談談京東高可用系統的設計理念，包括哪些層面？具體的技術指標是怎么樣的？

肖飛：高可用是個比較廣的話題。簡單地從字面理解，就是要保證從用戶請求到獲得響應這個鏈路上的所有的系統設施可用程度極高。通常是用幾個9來描述可靠程度。所以，高可用從鏈路上，包括了DNS、運營商網絡入口、LB、應用層、緩存、數據庫等軟件設施、連接和承載他們的硬件設施的高可用。每個層次都有自己的高可用方案和專業人員來實施。任何一個層次的故障都會導致可用程度下降。保障高可用最基本的前提是這些設施不能有單點。

可用，從系統的SLA角度，則是在某種并發量的前提下，穩定的耗時為多少的一種要求和承諾。穩定的耗時我們通常用TP99或TP999來描述，后者表示99.9%的請求在多長時間內返回。所以，可靠性、穩定性是我們高可用系統設計的前提。

關于高可用系統有一些耳熟能詳的架構設計原則：

• 分流。分流是通過調用鏈路上的系統設施的冗余，將請求路由到不同的設施上。比如根據終端將APP、PC端的流量分開到不同的后端服務；根據重要性，將核心系統和非核心系統的流量分開；根據用戶等級，劃分到不同的web服務；根據數據訪問特征和時間復雜度，將批量key和單key請求劃分到不同的緩存集群；將抽數分析和普通業務分到不同的數據庫；將大數據處理的專線帶寬和交易業務的專線帶寬在路由上做不同QOS設置；等等。流量會有邏輯和物理上的分組。最終，應用監控到的性能數據，應該可以看到不同流量分組下的指標。分流也是系統擴展性的結果。
• 故障切換。在可以分流的基礎上，當某個流量分組鏈路上的系統設施出現故障的時候，切換到另外分組的系統設施上，保證鏈路的通暢。切換時的手段和影響是系統設計時需要考慮的。SNA無狀態架構應用的故障切換很容易，有狀態則需要仔細設計切換的步驟。
• 隔離。和分流有點像。但是隔離是物理上的，比如秒殺系統，有獨立的服務器資源來部署一整套交易流程服務。
• 限流。上面談到的SLA，超出系統可承載的吞吐量時，穩定的耗時是沒法保證的。在已經做了分流和隔離的基礎上，資源仍然無法滿足，則有必要做限制。常見措施有LB層的請求頻率控制、RPC層的并發控制和CPU使用率的熔斷機制、數據庫層的連接池控制等等。
• 降級。當出現故障且切換成本較高時，針對非關鍵依賴進行降級?；蛘咧苯臃祷鼐彺娴姆菍崟r數據，或者直接返回異常，以便下游服務采取應對措施，等等。降級必須以不影響用戶核心體驗為標準。
• 并行和異步。在核心交易流程中，將一些沒有先后依賴關系的服務，可以進行異步并行的調用。或者某些非關鍵的依賴可以請求后不需等待直接返回。

交易系統一般會根據這些架構原則來設計系統，配合壓測來做性能的優化，運行時配合各個層面上的自動化/半自動化工具、監控平臺、部署系統等，來應對大流量、高并發的挑戰。

CSDN：多中心的系統范圍相比半年前的雙11備戰擴大了很多，能否介紹其中的主要技術突破？

肖飛：主要有以下幾個方面：

在一個數據中心時，用戶的數據已經按照用戶維度進行了分區。多中心之后，一些基礎數據如商品、價格等在每個中心仍然會是全量，存儲用戶路由的用戶基礎數據也會是全量。用戶產生的增速大的比如虛擬資產、訂單才需要在跨數據中心這個層面上做數據分片?？紤]到故障冗余，在現階段兩個主要的數據中心，這些數據也仍然保持全量，但是在穩定的用戶路由下，兩個中心都可寫入，不同用戶的寫入主節點不一樣。我們仍然是采取的傳統的數據分片、每個分片主從復制的方式來做。這樣的數據一致性容易控制。應用層需要根據穩定的用戶路由，保證同一個用戶數據不能同時寫入多個數據中心。

目前的兩個中心或即將上線的三中心，MySQL數據庫部署架構類似多Master，但是我們沒有采取MySQL自身的多Master機制。而是采用了數據復制中間件來做相互之間的同步。在數據復制中間件上我們考察和借鑒過開源社區的實現，例如Databus、Canal/Otter、OpenReplicator等，但最終還是自主實現了這個中間件（解析部分使用了Canal的DBSync），并根據我們在一期中的運維實踐，給中間件加了很多非常實用的功能，比如細粒度監控、自動化等等，并為應用提供API暴露相關的延遲等狀態信息。

多中心交易更多的是溝通協調層面的問題。由于在交易核心流程中，從入口到最后下單，系統非常多。所以我們也是在逐步地擴大這個核心流程中的系統改造范圍。用戶路由從入口到最后的結算服務，如果都能協調一致，減少或消除一些中間層的額外糾正，數據中心內流量閉環才能真正的實現。

CSDN：在多中心交易架構之下，可擴展性和高可用更有保障，但可能有異地跨機房的訪問延遲，京東如何解決？

肖飛：對于異地多中心部署，路由一致協調、機房內流量閉環是主要的工作。路由一致，讀你所寫的一致性很容易得到，用戶也感覺不到數據延遲帶來的短暫不一致。另一方面，數據復制中間件會在傳輸等環節做更進一步的優化，縮短數據不一致的故障時間窗口。

CSDN：在演練過程中，將流量切換到另一個機房，涉及有狀態服務的時候，京東是怎么做的？

肖飛：服務化對外隱藏狀態。我觀察到幾乎所有的交易系統對外提供的服務接口都是無狀態的。上面講到分流，本質上是一種帶權重的負載均衡，調用方按照流量分組標識來調用某一組服務接口，但是也是可以根據需要（比如故障或演練）切換調用另外一組服務接口實例。因此一個中間層系統的維護者，在做流量切換的時候，只需要保證對下游調用者的流量分組有可用實例，對依賴的上游服務做到可以隨時切換分組標識即可。服務框架層來處理一些負載均衡和故障切換細節。

那么每個服務化的系統只需要處理自己所直接依賴的狀態就可以，這些可能是數據庫、緩存、ES、分布式存儲等等。有些通過一些中間件比如各種無狀態的Proxy來解決，有些直接使用了分布式存儲提供的對外接口，這兩種方式也可以理解為直接利用了封裝狀態對外提供無狀態服務，他們本質上和大多數自己維護狀態的系統要解決的問題差不多。

基礎層的大多數系統還是直接面向存儲的。其中有一些系統所需要維護的狀態很簡單，比如接單系統，依賴一堆散列庫，只需要維護一個地址列表即可，Round-Robin的方式寫入訂單，某個庫故障是跳過即可，訂單落入到哪個庫都無所謂。

更多一些是需要維護固定路由的，比如分片地址、主從拓撲結構等信息。這類信息一般會通過配置系統來管理。在演練過程中，讀流量的切換比較簡單，無非切換應用系統的預設配置模板，將存儲從一個從集群切換到另外一個從集群。寫流量的切換涉及到主從拓撲信息變更，就需要非常小心。需要存儲層主從復制進度、應用寫切換窗口期處理、配置系統等協調起來。當然不同系統的細節也不一樣。

2016京東618技術系列：

• 扛過618全部流量，京東15萬Docker集群如何煉成
• 618前夕看京東IT基礎設施建設與無人機物流規劃
• 解構京東智慧物流：智能化設備+大數據技術

京東618/雙11技術演進：

• 京東11.11技術探秘(2014)
• 11·11單日1400萬單的背后：京東技術首次全解密(2014)
• 翁志：京東峰值系統設計（2014.11.11）
• 解密京東618技術：重構多中心交易平臺 11000個Docker支撐（2015）
• 京東11.11技術備戰解析：10萬級Docker、多交易中心與京東大腦（2015）
• 劉海鋒：從2014到2016，大規模內存數據庫演進之路（2015）

總結

以上是生活随笔為你收集整理的京东618技术解析之高可用多中心交易平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。