京東618技術(shù)解析之高可用多中心交易平臺(tái)

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

京東多中心交易平臺(tái)有三個(gè)主要的目標(biāo)：

• 在多個(gè)數(shù)據(jù)中心支持交易流程中讀流量和寫流量的水平擴(kuò)容；
• 異地容災(zāi)，任何一個(gè)中心出了故障之后，其全部的交易請(qǐng)求會(huì)被另外的中心無縫接管；
• 用戶體驗(yàn)和性能優(yōu)化，盡量規(guī)避異地的跨機(jī)房訪問延遲。

肖飛介紹，交易平臺(tái)在今年618備戰(zhàn)主要完成了三項(xiàng)任務(wù)：

幾乎所有的核心的交易流程所涉及的系統(tǒng)，以及寫流量的多中心的架構(gòu)；

對(duì)支持多中心交易系統(tǒng)的底層核心數(shù)據(jù)庫(kù)復(fù)制中間件JingoBUS做了大量的工作，包括性能的優(yōu)化和針對(duì)運(yùn)維可視化的改進(jìn)；

統(tǒng)一了交易流程中各個(gè)核心系統(tǒng)的流量可視化和故障切換（以前在分散各個(gè)系統(tǒng)里面分別實(shí)施），即把交易流程中的各種流量以及互相切換進(jìn)行了一個(gè)標(biāo)準(zhǔn)化，以實(shí)現(xiàn)快速切換。

嘉賓簡(jiǎn)介：

京東商城交易平臺(tái)架構(gòu)師肖飛

肖飛于2011年8月份加入京東，曾親身參與到京東的應(yīng)用性能監(jiān)控、統(tǒng)一日志、流式計(jì)算、內(nèi)存緩存、四層防攻擊等一些基礎(chǔ)技術(shù)平臺(tái)的研發(fā)和搭建工作，經(jīng)歷了京東的技術(shù)系統(tǒng)從簡(jiǎn)單粗放向復(fù)雜精細(xì)化的演變過程。目前主要工作為多中心交易項(xiàng)目中的數(shù)據(jù)復(fù)制中間件JingoBUS的研發(fā)。平時(shí)也會(huì)開發(fā)一些公共的平臺(tái)和工具，關(guān)注分布式系統(tǒng)的實(shí)現(xiàn)、程序設(shè)計(jì)、性能優(yōu)化、開發(fā)語(yǔ)言等。

CSDN：京東經(jīng)歷過了多次618和雙11，備戰(zhàn)的思路應(yīng)該已經(jīng)比較成熟，但京東的業(yè)務(wù)也在發(fā)展，今年618和之前的大促相比，技術(shù)挑戰(zhàn)有什么不同？

肖飛：如您所說，京東經(jīng)歷了很多次大促了，現(xiàn)在備戰(zhàn)已經(jīng)形成了一些套路。在大促之前兩三個(gè)月，會(huì)著重進(jìn)行諸如系統(tǒng)容量預(yù)估、架構(gòu)review和微調(diào)、風(fēng)險(xiǎn)點(diǎn)和監(jiān)控點(diǎn)梳理、壓測(cè)和優(yōu)化、各項(xiàng)預(yù)案的梳理和演練等工作。系統(tǒng)容量評(píng)估方面，各系統(tǒng)通過壓測(cè)來評(píng)估是否能夠支撐，無法滿足的要重點(diǎn)review，采取系統(tǒng)優(yōu)化、擴(kuò)容等方式來滿足，或根據(jù)系統(tǒng)情況準(zhǔn)備限流或降級(jí)等預(yù)案。

大促期間，也就是緊盯監(jiān)控，隨時(shí)應(yīng)對(duì)各項(xiàng)突發(fā)事件。大促過后，我們會(huì)review大促過程中系統(tǒng)的各項(xiàng)性能指標(biāo)，和先前的準(zhǔn)備工作，查漏補(bǔ)缺，進(jìn)行系統(tǒng)的下一個(gè)短期規(guī)劃（基本上是下一次的大促為目標(biāo)）。數(shù)據(jù)增長(zhǎng)量和容量方面，有些系統(tǒng)則會(huì)以2年或更長(zhǎng)的時(shí)間來規(guī)劃。由于要不斷的滿足業(yè)務(wù)的各項(xiàng)需求和技術(shù)架構(gòu)改造，系統(tǒng)到下一個(gè)大促前也會(huì)經(jīng)歷比較多的變化，因此有必要按照上述列表重新梳理一遍，當(dāng)然有些成熟的可以很快做完。

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

CSDN：能否進(jìn)一步談?wù)劸〇|高可用系統(tǒng)的設(shè)計(jì)理念，包括哪些層面？具體的技術(shù)指標(biāo)是怎么樣的？

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

可用，從系統(tǒng)的SLA角度，則是在某種并發(fā)量的前提下，穩(wěn)定的耗時(shí)為多少的一種要求和承諾。穩(wěn)定的耗時(shí)我們通常用TP99或TP999來描述，后者表示99.9%的請(qǐng)求在多長(zhǎng)時(shí)間內(nèi)返回。所以，可靠性、穩(wěn)定性是我們高可用系統(tǒng)設(shè)計(jì)的前提。

關(guān)于高可用系統(tǒng)有一些耳熟能詳?shù)募軜?gòu)設(shè)計(jì)原則：

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

交易系統(tǒng)一般會(huì)根據(jù)這些架構(gòu)原則來設(shè)計(jì)系統(tǒng)，配合壓測(cè)來做性能的優(yōu)化，運(yùn)行時(shí)配合各個(gè)層面上的自動(dòng)化/半自動(dòng)化工具、監(jiān)控平臺(tái)、部署系統(tǒng)等，來應(yīng)對(duì)大流量、高并發(fā)的挑戰(zhàn)。

CSDN：多中心的系統(tǒng)范圍相比半年前的雙11備戰(zhàn)擴(kuò)大了很多，能否介紹其中的主要技術(shù)突破？

肖飛：主要有以下幾個(gè)方面：

在一個(gè)數(shù)據(jù)中心時(shí)，用戶的數(shù)據(jù)已經(jīng)按照用戶維度進(jìn)行了分區(qū)。多中心之后，一些基礎(chǔ)數(shù)據(jù)如商品、價(jià)格等在每個(gè)中心仍然會(huì)是全量，存儲(chǔ)用戶路由的用戶基礎(chǔ)數(shù)據(jù)也會(huì)是全量。用戶產(chǎn)生的增速大的比如虛擬資產(chǎn)、訂單才需要在跨數(shù)據(jù)中心這個(gè)層面上做數(shù)據(jù)分片。考慮到故障冗余，在現(xiàn)階段兩個(gè)主要的數(shù)據(jù)中心，這些數(shù)據(jù)也仍然保持全量，但是在穩(wěn)定的用戶路由下，兩個(gè)中心都可寫入，不同用戶的寫入主節(jié)點(diǎn)不一樣。我們?nèi)匀皇遣扇〉膫鹘y(tǒng)的數(shù)據(jù)分片、每個(gè)分片主從復(fù)制的方式來做。這樣的數(shù)據(jù)一致性容易控制。應(yīng)用層需要根據(jù)穩(wěn)定的用戶路由，保證同一個(gè)用戶數(shù)據(jù)不能同時(shí)寫入多個(gè)數(shù)據(jù)中心。

目前的兩個(gè)中心或即將上線的三中心，MySQL數(shù)據(jù)庫(kù)部署架構(gòu)類似多Master，但是我們沒有采取MySQL自身的多Master機(jī)制。而是采用了數(shù)據(jù)復(fù)制中間件來做相互之間的同步。在數(shù)據(jù)復(fù)制中間件上我們考察和借鑒過開源社區(qū)的實(shí)現(xiàn)，例如Databus、Canal/Otter、OpenReplicator等，但最終還是自主實(shí)現(xiàn)了這個(gè)中間件（解析部分使用了Canal的DBSync），并根據(jù)我們?cè)谝黄谥械倪\(yùn)維實(shí)踐，給中間件加了很多非常實(shí)用的功能，比如細(xì)粒度監(jiān)控、自動(dòng)化等等，并為應(yīng)用提供API暴露相關(guān)的延遲等狀態(tài)信息。

多中心交易更多的是溝通協(xié)調(diào)層面的問題。由于在交易核心流程中，從入口到最后下單，系統(tǒng)非常多。所以我們也是在逐步地?cái)U(kuò)大這個(gè)核心流程中的系統(tǒng)改造范圍。用戶路由從入口到最后的結(jié)算服務(wù)，如果都能協(xié)調(diào)一致，減少或消除一些中間層的額外糾正，數(shù)據(jù)中心內(nèi)流量閉環(huán)才能真正的實(shí)現(xiàn)。

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

肖飛：對(duì)于異地多中心部署，路由一致協(xié)調(diào)、機(jī)房?jī)?nèi)流量閉環(huán)是主要的工作。路由一致，讀你所寫的一致性很容易得到，用戶也感覺不到數(shù)據(jù)延遲帶來的短暫不一致。另一方面，數(shù)據(jù)復(fù)制中間件會(huì)在傳輸?shù)拳h(huán)節(jié)做更進(jìn)一步的優(yōu)化，縮短數(shù)據(jù)不一致的故障時(shí)間窗口。

CSDN：在演練過程中，將流量切換到另一個(gè)機(jī)房，涉及有狀態(tài)服務(wù)的時(shí)候，京東是怎么做的？

肖飛：服務(wù)化對(duì)外隱藏狀態(tài)。我觀察到幾乎所有的交易系統(tǒng)對(duì)外提供的服務(wù)接口都是無狀態(tài)的。上面講到分流，本質(zhì)上是一種帶權(quán)重的負(fù)載均衡，調(diào)用方按照流量分組標(biāo)識(shí)來調(diào)用某一組服務(wù)接口，但是也是可以根據(jù)需要（比如故障或演練）切換調(diào)用另外一組服務(wù)接口實(shí)例。因此一個(gè)中間層系統(tǒng)的維護(hù)者，在做流量切換的時(shí)候，只需要保證對(duì)下游調(diào)用者的流量分組有可用實(shí)例，對(duì)依賴的上游服務(wù)做到可以隨時(shí)切換分組標(biāo)識(shí)即可。服務(wù)框架層來處理一些負(fù)載均衡和故障切換細(xì)節(jié)。

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

基礎(chǔ)層的大多數(shù)系統(tǒng)還是直接面向存儲(chǔ)的。其中有一些系統(tǒng)所需要維護(hù)的狀態(tài)很簡(jiǎn)單，比如接單系統(tǒng)，依賴一堆散列庫(kù)，只需要維護(hù)一個(gè)地址列表即可，Round-Robin的方式寫入訂單，某個(gè)庫(kù)故障是跳過即可，訂單落入到哪個(gè)庫(kù)都無所謂。

更多一些是需要維護(hù)固定路由的，比如分片地址、主從拓?fù)浣Y(jié)構(gòu)等信息。這類信息一般會(huì)通過配置系統(tǒng)來管理。在演練過程中，讀流量的切換比較簡(jiǎn)單，無非切換應(yīng)用系統(tǒng)的預(yù)設(shè)配置模板，將存儲(chǔ)從一個(gè)從集群切換到另外一個(gè)從集群。寫流量的切換涉及到主從拓?fù)湫畔⒆兏?#xff0c;就需要非常小心。需要存儲(chǔ)層主從復(fù)制進(jìn)度、應(yīng)用寫切換窗口期處理、配置系統(tǒng)等協(xié)調(diào)起來。當(dāng)然不同系統(tǒng)的細(xì)節(jié)也不一樣。

2016京東618技術(shù)系列：

• 扛過618全部流量，京東15萬Docker集群如何煉成
• 618前夕看京東IT基礎(chǔ)設(shè)施建設(shè)與無人機(jī)物流規(guī)劃
• 解構(gòu)京東智慧物流：智能化設(shè)備+大數(shù)據(jù)技術(shù)

京東618/雙11技術(shù)演進(jìn)：

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。