京東的交易系統 之 高併發架構分享

本文根據京東商城交易平臺的楊超在「第一期蝴蝶沙龍：揭祕618電商大促背後的高併發架構」會議上的演講整理而成。

你們好！我是來自京東商城交易平臺的楊超，今天特別高興可以來給你們作這個分享。我是 2011 年加入京東，5 年中我經歷了很多技術架構的演進，也看到了很多變化。此次分享首先介紹京東商城的服務、京東交易結構，而後介紹針對618備戰，咱們作的一些事情，以及從2011年到如今，京東交易平臺經歷的變化。

商城服務

 

 

如圖所示是京東交易平臺的一張大的漁網圖。從主頁面網站開始，到後面提交訂單、購物車、結算頁、訂單中心等的整個生產過程，大致可分爲三個部分。第一部分是訂單提交前，就是俗稱的購物車，結算頁。第二部分是訂單預處理部分，生成訂單以後、到物流以前，還會有一些預處理過程，好比生鮮、你們電、奢侈品、易碎品等商品。第三部分是訂單履約部分。今天我講的主要內容是，交易平臺的提交之前和預處理部分。

(點擊放大圖像)

 

京東交易平臺，包括單品頁的價格、庫存，購物車、促銷，結算頁的下單，再到訂單中心線。

以下圖所示，2011年京東的訂單量是30萬，2015年訂單量就已經到了3000多萬，京東的流量每一年不斷地翻倍。訂單從30萬到100萬是三倍增加，實際上訪問流量的翻番，多是10倍、50倍，甚至上百倍。好比，用戶購買東西從單品頁進入，而後查詢不少信息，包括價格、評價。商品加入購物車後，用戶會不停地比對各種商品。刷新購物車，從前端到後端全部的服務基本上都會刷新。那麼，當你刷新一次，調動服務就會承受一次動態的調用。當訂單量翻三倍的時候，實際服務訪問量最少是要翻20倍。

我見過的京東目前最大的前端流量是，一分鐘幾千萬，一個正常前端服務訪問量是在幾千萬，幾億、幾十億，一天的PV。

那爲了應對如此大的調動量，每一年的61八、雙11，京東都作了什麼？

下面我會詳細講61八、雙11備戰後面，每年所作的不一樣改變。這是一個總體的大概分析，咱們從哪些方面作優化，去提升系統的容災性，提升系統應對峯值流量的能力。

實際上每一年京東內部的正常狀況是，領導層會給出一個大概的預期值，就是但願當年的大促中，須要達到幾百億，或者幾十億的預期銷售額。那麼，根據這個銷售額，根據客單價（電商的訂單的平均價格，稱爲客單價）換算成訂單量。另外在以往的61八、雙11中，咱們都會統計出訂單量和調用量，即前端價格須要訪問多少次，購物車須要訪問多少次，促銷引擎須要訪問多少次，整個流程須要多大的量。有了大概的方向以後，就會把具體系統的量換算出來。第一輪會作壓測，壓測分爲線上壓測和線下壓測兩部分。這些都是準備工做，根據一些指標往年的增加量估算出一個預期值。

壓測

這是真正進入第一波。首先，每一年的大促前，都會經歷半年業務迭代期，整個系統會有不少變動。咱們會進行第一輪的壓測系統，壓測以後會知道當前線上真正可以承載的訪問量有多大，距離預期有多遠。壓測分爲線上壓測跟線下壓測。壓測場景分爲讀業務和寫業務，壓測方案有集羣縮減服務、模擬流量、流量泄洪。

講到壓測，先說說壓測的來歷吧。2011年時候沒有線上壓測，線下壓測也不是很全。真正引入線上壓測是在2014年，訂單量已經接近2000萬。以前的大促備戰，是經過組織架構師、優秀的管理人員，優秀的技術人員，一塊兒去評估優化系統，由於在迭代代碼的同時，咱們會知道系統哪裏容易出現問題，而後對數據庫、Web或者業務服務作一堆優化。

在2014年，訂單量到了上千萬，換算成爲訪問量，天天的PV大漲，集羣也更大偏大，若是仍是隻依靠技術人員去優化，可能會不足。因而就衍生出壓測，咱們想知道系統的極限值。這樣，當系統承受不住訪問請求的時候，咱們就會知道哪裏出現瓶頸，好比，服務器的CPU、內存、鏈接速度等。咱們經過第一輪壓測找到第一波的優化點，開始了線上的壓測。

當時第一波作線上壓測是在凌晨一兩點，把整個線上的流量剝離小部分機器上。把集羣剝離出來，而後再作壓測。全部的服務器、全部的配置就是用線上徹底真實的場景去作壓測，就可以獲得線上服務器在真實狀況，再優化。

曾經作redis壓測，把進程綁定到單核CPU，redis是單進程程序，當時集羣的性能就提高了5%。由於機器的每次CPU切換，都須要損耗資源，當時把進程直接綁定到固定的CPU上，讓它高壓下不頻繁地切換CPU進程。就這樣一個改變，性能提高了5%。當量很大的時候，真正底層細節的小改變，整個性能就會有很大的改進。這是咱們從2014年引進線上壓測和線下壓測以後的一個真實感覺。

壓測完以後獲得容量，獲得交易系統的購物車、結算頁大概承受值，以後會進行一輪優化，包括對NoSQL緩存的優化。京東在2012年的時候自建CDN網絡，Nginx層作了不少模塊加Nginx+lua的改造。應用程序層也會作不少緩存，把數據存在Java虛擬器裏面。數據層的緩存，主要有redis、 NoSQL的使用，另外會剝離出一些獨立的數據存儲。

緩存 壓縮

CDN域名切換的問題，原來外部CDN切換IP，須要15-20分鐘，整個CDN才能生效。咱們的運維作了不少的改進，自建了CDN，內網VIP等等進行緩存壓縮。Nginx自己就有介質層的緩存和GZIP壓縮功能，把靜態js、CSS文件在Nginx層直接攔掉返回，這樣就節省了後面服務的服務器資源。GZIP壓縮能壓縮傳輸的文件以及數據，節省了網絡資源的開銷（GZIP壓縮主力損耗CPU，機器內部資源的平衡）。前面就直接壓縮返回圖片、文件系統等靜態資源。流量到部署集羣系統時，只須要處理動態資源的計算，這樣就將動態靜態分離集中處理這些專向優化。

真正的計算邏輯，服務自身的組裝、如購物車的促銷商品、服務用戶，基本上全部資源都耗費在此。好比，鏈接數都會耗費在跟促銷，商品，用戶服務之間調用，這是真實的數據服務。若是不分離，你用DOS攻擊直接訪問JS，而後傳一個大的包，就會徹底佔用帶寬，鏈接和訪問速度就會很是慢。這也是一種防禦措施，在大促中會作不少緩存、壓縮這些防禦。

(點擊放大圖像)

購物車從2010年就開始Java改造，總體結構的劃分主體有，促銷引擎、商品、用戶。系統結構在2012年已經成型。到13年，加入了購物車服務的存儲。原來購物車存儲的商品是在瀏覽器端的Cookie裏的，用戶更換一臺設備，以前加入的商品就會丟失掉。爲了解決這個需求，咱們作了購物車服務端存儲，只要登陸，購物車存儲就會從服務端拿取。而後經過購車服務端存儲打通了手機端與PC端等的存儲結構，讓用戶在A設備加入商品，在另一個設備也能結算，提升用戶體驗。

異步 異構

2013年以後，接入了不少其餘業務，如跟騰訊合做，有微信渠道，咱們會把存儲分爲幾份，容量就會逐步地放大。這是異步的存儲，手機端會部署一套服務，PC端會部署一套服務，微信端會部署一套服務。就會隔離開來，互不影響。

購物車就是這麼作的。購物車整個數據異步寫的時候都是全量寫的。上一次操做可能異步沒寫成功，下一次操做就會傳導都寫成功了。不會寫丟，可是可能會有一下延時，這些數據仍是會同步過來。好比，從PC端加入商品以後沒有當即同步到移動端，再勾選下購物車，購物車的存儲又會發生變動，就會直接把所有數據同步到移動端。這樣，咱們的數據不多會出現丟失的狀況。

異步寫的數據是進行了不少的壓縮的。第一層壓縮從前端開始，整個前端是一個接口串，到後面購物車服務，先把它壓縮爲單個字母的接口串，後面又會壓縮成字節碼，使字節流真正存儲到redis層裏面。當存儲壓縮得很小的時候，性能也會提升。

緩存壓縮只是爲提高縱向性能作的改進。後面還會進行橫向異步異構的改進，購物車把移動端存儲剝離出去，移動端的存儲在一組redis上，PC端的存儲在另一組上。PC端和移動端是異步去寫，這樣相互不影響，雖然它們的數據是同步的。這是針對多中心用戶所作的一些改進。

外層的異步，是作一些不重要的服務的異步，就從購物車前端看到的地址服務、庫存狀態服務。庫存狀態服務在購物車只是一些展現，它不會影響主流層、用戶下單。真正到用戶提交的時候，庫存數據纔是最準確的。這樣，咱們會優先保證下單流程。

接下來說講接單的異步。提交訂單，提交一次訂單原來須要寫10多張表。當訂單量提升到一分鐘10萬的時候，系統就沒法承受。咱們就把整個提交訂單轉成XML，這樣只寫一張表，後面再去作異步。接單的第一步，先是把整個訂單全部信息存儲下來，而後再經過狀態機異步寫原來的10多張表數據。

關於訂單中心的異步異構，訂單中心原來都是從訂單表直接調出的。隨着體量增大，系統沒法承載訪問，咱們異構出訂單中心的存儲，支付臺賬存儲等。 異構出來數據都具備業務針對性存儲。數據體量會變小，這樣對總體的優化提高提供很好的基礎。

這樣的存儲隔離，對訂單狀態更新壓力也會減少，對支付的臺賬、對外部展現的性能也會提高。你們會疑問，這些數據可能會寫丟。咱們從第一項提交開始，直接異步寫到訂單中心存儲，到後面訂單狀態機會補全。若是拆分不出來，後面就生產不了。也就是說，到不了訂單中心，數據生產不了，一些異步沒成功的數據就會在這個環節補全。

而後是商品的異步異構。2013年，商品團隊面臨的訪問量，已是幾十億。如何去應對這個狀況呢？不少商品數據貫穿了整個交易，包括交易的分析、各個訂單的系統都會調商品系統。咱們會針對系統優化。好比，針對促銷系統調用，促銷系統主要調用特殊屬性，咱們把這些屬性存到促銷系統的特有存儲。庫存系統也類推。調用的特殊屬性的方法也不同。譬如你們電的長寬高這些特有屬性，不像前端商品頁裏只是基本屬性。這樣就把全部的屬性異構處理，針對商品緯度、商品ID等全部數據會異構一份到庫存、促銷、單品頁，後面進行改造的時候，又將數據分A包、B包、C包。京東的業務很複雜，有自營，又有平臺數據，A包多是基礎數據，B包多是擴展數據，C包多是更加偏的擴展數據。這樣，促銷系統可能調用的是B包的擴展屬性，也有可能調用的是A包的基礎屬性。單品頁訪問A包、B包，調的集羣是不同的。這樣存儲的容量就能夠提升兩倍，系統的容災承載力也會提升。

商品原來是一個單表，後來慢慢發展成爲了一個全量的商品系統，包括前端、後端整個一套的流程。異步異構完了以後，系統可進行各方面的優化，這樣系統的容量也會慢慢接近預期值。而後找到系統容量的最大值，若是超過這個值，整個系統就會宕機。那麼，咱們會作分流和限流，來保證系統的可用性。不然，這種大流量系統一旦倒下去，須要很長的時間才能恢復正常，會帶來很大的損失。

分流限流

在61八、雙11時候，手機、筆記本會有很大力度的促銷，不少人都會去搶去刷。有不少商販利用系統去刷，系統流量就不像用戶一秒鐘點三四次，而是一分鐘能夠刷到一兩百萬。怎樣預防這部分流量？咱們會優先限掉系統刷的流量。

• Nginx層： 經過用戶IP、Pin，等一下隨機的key進行防刷。

• Web 層： 第一層，Java應用實列中單個實列每分鐘，每秒只能訪問多少次；第二層 ，業務規則防刷，每秒單用戶只能提交多少次，促銷規則令牌防刷。

從Nginx，到Web層、業務邏輯層、數據邏輯層，就會分流限流，真正落到實際上的流量是很小的，這樣就會起到保護做用，不會讓後端的存儲出現崩潰。從前面開始，可能訪問價格或者購物車的時間是10毫秒，保證20臺的機器一分鐘的流量是一百萬、兩百萬。若是是40臺機器的話，承載能力會很強，會透過Java的服務，壓倒存儲，這樣會引起更大的問題，龐大存儲一旦出現問題很難一下恢復。若是從前面開始一層一層往下限，就能夠起到保護底層的做用。中間層出問題比較容易處理，如Web層，限流會消耗不少CPU，會一步步加入更多機器，這樣就可以解決這個問題。

咱們須要降級分流限流。

下面結合秒殺系統來說講如何限流分流。2014年才產生秒殺系統。當時，在同一時刻可能有1500萬人預定搶一件商品，搶到系統不能訪問。後端服務都沒有出現這些問題，有的服務費不能正常展示。後來就專爲搶購設計了一個秒殺系統。正常狀況下，有大批量用戶須要在同一時間訪問系統，那麼就從系統結構上分出去這些流量。秒殺系統儘可能不影響主流層的入口，這樣就分離出來一部分數據。

接下來說講促銷和價格。主力調用價格的服務主要在促銷引擎，限流主要是經過購物車服務，購物車到促銷引擎又會限流，促銷引擎裏面會有令牌。好比，有5000個庫存，發50萬個令牌到前端去，確定這5000個庫存會被搶完，不可能再把其餘服務的量打到後面，這樣會保護促銷引擎，這是一種總令牌模式的保護。後面的分流性能，會分集羣式、重要程度去作。另外，一些廣告的價格服務，咱們會優先降級，若是出問題的話會限制。另外，有一部分刷引擎刷價格服務的數據，正常狀況下是保證它正常使用，可是一旦出現問題，咱們會直接把它降級，這樣就保護了真實用戶的最好體驗，而不是直接清除程序的應用。

容災降級

每次雙11活動，咱們會作不少的容災和降級，有多中心交易、機房容災、業務容災等各類緯度的容災。大概統計了一下作過的一些容災方案。

首先是網絡容災。前面說到SB中間件、域名解析，咱們運維本身會作了核心交換機兩層專線。這是咱們運維部作的一些網絡架構圖，兩邊相互容災的一個結構。有LVS、HA、域名及解析，只是單服務掛了，經過交換機，咱們能夠從一個機房切換到另外一個機房，由於會作一些域名的解析和切換。

(點擊放大圖像)

應用系統相互調用容災和降級：結算的容災和降級。應用系統大部分可以降，好比庫存狀態。若是像優惠券這些不重要的服務，備註信息，可直接降級服務，不用去訪問它，直接提交就行。在提交訂單時候，首先咱們會保證必要服務，這些服務都會有不少的保護措施。每一個應用裏面，應用級別、服務級別的容災，好比地址服務、庫存狀態容災能夠直接先降級。到提交的時候，咱們直接對庫存作限制。

(點擊放大圖像)

應用內部的容災。庫存就是結算前面的系統應用的服務，再到細一層的咱們的庫存服務，這是每個服務的容災降級。從庫存狀態這邊的話，從網絡設備內層，有網絡容災降級。應用內部有對於預算服務的降級，預算服務會有預算庫存，原來是寫MySQL數據庫。正常狀況下，預算庫存是寫MASIC預算庫，當出現問題的時候，咱們會異步堆列到本地機器，裝一個程序去承載這個異步MySQL數據的落地，而後再經過Work把它寫到MySQL服務裏面。正常狀況下，是雙寫MySQL、redis，當MySQL承載不住的時候，咱們會把MySQL異步寫到裏面。

這裏面都會有開關係統去控制。當提交訂單產生變動的時候，纔會把庫存狀態從這邊推到這個庫存狀態這邊，由於庫存狀態的調用量跟價格同樣很大。今年咱們看到的最大調用量是一分鐘2600萬。這樣不可能讓它直接回原到MySQL，跟直接庫存的現實存儲裏面。經過預算系統把這個狀態從左邊算好，直接在推送過到真正的存儲，這樣就把這個存儲剝離出來，這也算一種異步異構，這樣咱們會提高它的容量。

這是原來的結構，就是redis直接同步，而後直接訪問。如今把它改爲是，直接讓左邊的預算服務去推送到狀態服務裏面。

監控

最後主要就是監控系統，咱們運維提供了網絡監控、機器監控。

網絡監控包括咱們看到的SBR，以及一些專線網絡監控，如交換機、櫃頂交換機、核心交換機的監控。

接下來是應用的系統監控。機器監控有CPU、磁盤、網絡、IO等各方面系統的監控。業務緯度的監控，有訂單量、登錄量、註冊量等的監控。京東機房微屏專線的一個網絡平臺的監控，裏面有不少專線，它們相互之間的流量是怎麼樣？圖中是咱們監控系統，是機器之間的監控，包括機器直接對應的交換機、前面的櫃機交換機等的網絡監控等。

這是應用系統裏面的方法監控，後面是業務級別的監控。訂單級別的包括註冊量、庫存、域站，或者區域的訂單、金額、調用量的監控都會在這裏體現。真正到大促的時候，不可能常常去操做咱們的系統，去修改它的配置。正常狀況下都是去查看這些監控系統。2012年以後，監控系統一點一點積累起來。當量愈來愈大，機器資源愈來愈多以後，這些監控都會直接影響正常服務，服務用戶的質量會降低，可能20臺機器宕了一臺機器，不會影響所有效果。因此，監控的精準性是一步步慢慢提升的。

(點擊放大圖像)

 

轉載：https://segmentfault.com/p/12100000069523481