本文根據闫文廣老師在〖deeplus直播第242期〗線上分享演講内容整理而成。
闫文廣
京東到家背景研發部架構師
- 從事支付系統、計費系統和訂單履約系統等背景領域的研發，現專注于訂單中心架構優化和研發相關的工作。
大家好，我是京東到家背景研發部的架構師闫文廣，今天将給大家分享京東到家訂單系統的高可用架構及演變過程。
京東到家是達達集團旗下中國最大的本地即時零售平台之一，目标就是實作一個小時配送到家的業務。一直到2019年京東到家覆寫700個縣區市，合作門店近10萬家，服務數千萬消費者。随着訂單量的增長、業務複雜度的提升，訂單系統也在不斷演變進化，從早期一個訂單業務子產品到現在分布式可擴充的高并發、高性能、高可用訂單系統。整個發展過程中，訂單系統經曆了幾個明顯的階段，通過不同的技術優化方案解決業務上遇到的問題。
下面我将為大家逐一介紹我們遇到了哪些問題及如何解決，主要分為以下三部分：
- 京東到家系統架構
- 訂單系統架構演進
- 訂單系統穩定性保障實踐
一、京東到家系統架構
業務架構
首先來看以下這張流程圖，這個系統架構主要由幾個部分構成：使用者端分别是C端使用者和B端使用者。B端使用者針對的是像沃爾瑪、永輝超市等的一些商家，商家生産需要用到我們的一些揀貨APP和揀貨助手，後面商家履約完成會用到配送端，配送端就是給騎手接單搶單，最後是結算部分，分别給騎手和商家結算。
C端針對的是使用者，使用者進來浏覽、下單到支付，整個過程是使用者的操作行為。基于使用者的操作行為，我們有幾大子產品來支撐，首先是京東到家APP的後端業務支撐的基礎服務，另外就是營銷系統、業務系統等等。基于上面這些，我們需要有很多系統來支撐，比如營運支撐系統、管理背景的支撐系統、對商家的履約支撐系統。這些業務系統的底層大概有三塊的持久化，分别是緩存（LocalCache、Redis等）、DB（MySQL、MongoDB等資料庫）、ES。這就是京東到家簡版的業務架構圖。
營運支撐業務架構
京東到家的營運支撐業務架構主要分為商家管理、CMS管理、營銷管理、财務管理、營運資料這五大子產品，每塊包含的内容具體如下圖所示：
後端架構
接下來是我們C端APP的一些網關後端的接口及基礎服務的支撐。首先所有的請求都會經過網關協定，網關下面分為業務系統，包括首頁、門店頁、購物車、結算頁以及提單系統、支付系統和個人訂單系統，這些系統的支撐都離不開我們的基礎服務的支撐，比如庫存、商品、門店、價格等等，這些是一些重要的基礎服務支撐，來保證使用者可以流暢的下單以及到結算。
業務支撐包含了很多業務系統，比如使用者、定位、位址庫、運費、promise、推薦、搜尋、收銀台、風控等。
上面說到了營銷的一些管理系統，其實營銷還有一些後端的基礎服務系統，比如優惠券、滿減、秒殺、首單等。
訂單資料入庫流程
使用者提單以後資料怎麼流轉？提單其實是一個把使用者下單資料存儲到資料庫，提單系統做了一些分庫分表。那麼提完單的資料怎麼下發到訂單系統生産？首先我們會有一個管道，提單通過一個分布式異步任務來下發訂單管道裡。所有的訂單下來都會放到管道裡，我們通過一個異步的任務，按照一定的速率，均勻地把訂單下發到訂單生産系統。這樣設計有一個好處，比如像大促時可能會有大量資料一下子下發到訂單生産系統，對訂單生産庫有很大壓力，是以我們中間設計出一個管道，通過異步任務來分發生産訂單。
看了圖可能有人會問為什麼要有一個個人訂單DB？其實個人訂單DB跟訂單系統是不同次元的資料，因為個人訂單其實是基于使用者去做了一個分庫分表，它每一個查詢的訂單都是基于這種個人，跟訂單生産是不一樣的，是以每個次元的資料都是單獨的存儲，來提高系統的穩定性，以及适合它自身業務特性的設計。
那麼訂單系統跟個人中心是怎麼互動的？首先異步，我們是通過MQ來互動這些訂單狀态的變更。另外C端的訂單取消，是怎麼同步到訂單生産系統的？我們是通過RPC的調用來保證訂單實時取消，有一個傳回結果。
二、訂單系統架構演進
訂單系統業務流程
我們的訂單履約分為兩大塊，商家生産和配送履約，具體步驟如下圖所示：
整個訂單履約的流程是怎麼樣的？在使用者支付完成後，訂單會有一個補全的過程，補全完後，我們會根據一些門店的設定，把訂單下發到商家。下發商家後，有幾種對接模式：有開發能力的商家可以通過開放平台，一些小商家可以通過商家中心以及我們的京明管家來完成訂單的生産履約。在商家拿到新訂單後，通過列印出發票進行揀貨。揀貨會分為幾個業務場景，因為有可能商家有貨也有可能沒貨，如果缺貨的話，我們有一個調整的功能，讓商家通過訂單調整來保證有商品的訂單可以繼續履約。
在商家完成揀貨時，我們訂單會分為分區揀貨、合單揀貨、前置倉揀貨這幾塊業務上的操作，其實在系統裡我們有一個揀貨的池子，會通過不同次元的資料來完成高效的揀貨。揀貨完成後，我們的配送主要分為兩個子產品，一種是單個訂單的配送，另一種是集合單的配送。集合單就是把發單位址和配送位址在兩個相近的格子裡的訂單合并起來，基本上都是基于将同一個門店的配送目的是同一個相近格子裡的訂單，進行合單後讓一個騎士完成配送。配送會下發到一些配送系統，分為兩種模式，集合單和單個訂單的配送，以及和配送系統的整個運單互動的一個流程。
RPC微服務化叢集
說完業務後，接下來介紹一下我們應用的一些微服務的拆分過程。先講一下微服務理論方面的知識，比如為什麼要拆分微服務？微服務拆分後可以解決哪些問題？這是接下來一個重點内容，大家可以思考一下，系統架構必須具備哪些條件才能達到高可用？
簡單總結來說，微服務可以降低系統的複雜度，可以獨立部署，并且有很好的擴充性：
- 降低複雜度：把原來耦合在一起的業務，按領域拆分為不同的微服務，拆分原有的複雜邏輯，每個微服務專注于單一業務邏輯。明确定義領域職責與邊界；
- 獨立部署：由于微服務具備獨立部署運作能力，當業務發生變更更新時，微服務可以單獨開發、測試、部署更新。提高了疊代效率，降低了研發風險；
- 擴充性：拆分後的微服務架構獨立部署，可以根據流量預估或壓測評估獨立進行擴容更新。
我們訂單系統的架構演進如上圖所示，最左邊是最初的一個模型，所有的業務都耦合在一個應用裡面，這個應用可能就有一個service來支撐，資料庫也是一個單點的資料庫。随着這些年的疊代更新變更，逐漸演進到一個應用有多個服務支撐，資料庫也在不斷更新變更，以及到後面把應用按微服務拆分成多個子產品，拆成多個領域的支撐，按不同的系統邊界去拆分。并且拆完後，随着業務量越來越大，其實我們也在做一些更新，比如Redis的接入。
Redis的接入解決了什麼問題？資料庫為什麼要分庫？ES為什麼在接下來一些系統架構更新裡會被引入進來？為什麼DB要拆成多個叢集？這背後的一些根本問題，以及解決業務系統的一些背景，接下來我們逐一探讨。
在最初搭建項目時，其實我們是要保證業務的快速試錯。這個模型會有什麼問題？就是系統會有一些單點風險，以及系統釋出是一個短暫停，所有請求都是一個主觀的操作，并發能力很差，稍微有一些業務量時，系統接口就會逾時比較嚴重。這是最初2015-2016年的情況。
接下來2016-2017年，随着業務的快速疊代，系統複雜度也慢慢高了起來，系統邏輯耦合會比較嚴重，改動一塊的邏輯影響就會比較大，導緻線上問題頻發，因為所有的邏輯都耦合在一起，一次釋出可能就會影響範圍比較大。
按微服務拆分成多個系統，如果釋出有問題也隻會影響其中的一些很小的部分。在後面随着業務量越來越大，RPC這種架構的引入，解決故障的自動下線，保證高可用，比如單台伺服器有問題時，能做到自動下線來保證不影響業務。
Redis叢集
2017-2018年，我們根據2016年遇到的問題做了一些拆分，比如按領域拆分不同的APP應用。這樣拆分做到的就是系統沒有單點，負載均衡可以橫向擴充，多點部署。包括引入Redis，其實我們用到了Redis的分布式鎖、緩存、有序隊列、定時任務。
我們資料庫為什麼更新？因為資料庫的資料量越來越大，比如添加一些字段，它其實會做一些鎖表操作，随着資料量越大，單表的資料越來越多，資料主從延遲以及一些鎖表的時間會越來越長，是以在加字段的時候對生産影響特别大，我們就會對資料做一個分離，把一些冷的資料單獨做一個曆史庫，剩下的生産庫隻留最近幾天的一些生産需要的資料，這樣生産庫的訂單資料量就會很小，每次修改表的時間是可控的，是以我們會把資料按照冷備進行拆分。
至于為什麼引入ES，是因為訂單在生産方面會有一些很複雜的查詢，複雜查詢對資料庫的性能影響非常大，引入ES就可以很好地解決這個問題。
2018-2019年，我們發現之前在引入資料庫時，用資料備援來保證一些資料應用可互備互降。比如我們之前在用ES低版本1.7的時候，其實就是一個單點，當叢集有問題時是會影響生産的。我們後來引入了一個雙叢集，雙ES叢集互備，當一個叢集有問題時，另一個叢集可以直接頂上來，確定了應用的高可用和生産沒有問題。
另外，引入Redis雙叢集，Redis其實有一些大key的問題，當一些核心業務和非核心業務都用到Redis的時候，我們會把一些核心業務拆到一個叢集，非核心業務拆到另一個叢集，來保證Redis叢集的穩定性，能穩定支撐訂單生産。
注：大key（線上看到過list的elements超過百萬的）删除時會阻塞比較長的時間，大key的危害：
- OPS低也會導緻流量大，比如一次取走100K的資料，當OPS為1000時，就會産生100M/s的流量；
- 如果為list,hash等資料結構，大量的elements需要多次周遊，多次系統調用拷貝資料消耗時間；
- 主動删除、被動過期删除、資料遷移等，由于處理這一個key時間長，而發生阻塞。
單個應用怎麼保證高可用？其實我們這邊從最初的一個單機房單執行個體單IP，一步步演進為單機房的單服務、單機房的多服務，最終是多機房的多服務，比如某個機房某些IP有問題，我們能確定應用可以正常請求響應，來保證系統的高可用。
MySQL資料庫
下面來介紹一下我們主從架構的演進。最初我們就是一些主從的架構，并且主讀和寫都會請求到一個主庫，這樣就會給主庫帶來非常大的壓力。而像訂單生産這種天然性就是讀多寫少，主庫的壓力會比較大。是以基于這個問題，我們就做了資料庫架構的更新。
我們做了讀寫分離，就能很好地解決了這個問題。比如很多查詢，我們就會直接查詢到從庫的，主庫隻是用來承載一些寫的流量，這樣主庫就減少了很多壓力。但這樣就會遇到上面說到的問題，因為我們是一個生産表和曆史表的結構，在每次加字段時，資料量很多的話，鎖表時間就會很長，導緻在這種讀寫分離的架構下資料延遲就會比較大。
基于這種場景，我們又做了一些更新和改造。我們把資料拆出來了，拆成曆史庫，當所有的生産資料都很小的時候，對于提高性能是非常有幫助的。我們把生産完的一些資料全部都歸檔到曆史中，減輕主庫的整個壓力，以及在添加表字段修改的時候，其實就沒有太大影響了，基本上都很穩定。
資料的演進最終結構如上圖，當這是基于目前業務的一個支撐，在未來業務不斷發展的情況下，這個資料庫架構是原因不夠的。基于以上架構，我們主要是做到了一主多從的主備實時切換，同時確定主從在不同機房來保證資料庫的容災能力。同時通過業務隔離查詢不同的從庫給主庫減輕壓力，以及冷備資料的隔離的一個思路來保證訂單資料庫的穩定性。
ElasticSearch叢集
最開始我們是單ES叢集，DB會通過一個同步寫寫到ES叢集。這個時候我們的ES是一個單機群，如果寫失敗的話，我們會起一個異步任務來保證資料的最終一緻性，是這樣的一個架構。在ES叢集沒問題的情況下，這個架構也是沒問題的，但當叢集有問題時，其實就沒有可降級的了。
為了解決這個問題，我們引入了ES的冷備兩個叢集，熱叢集隻儲存跟資料庫一樣的生産庫的資料，比如說我們現在保證的就是5天的生産資料，其它所有資料都歸檔在一個ES的冷叢集裡。通過這種異步跟同步寫，通過異步任務來保證最終的叢集的資料一緻性。這就是ES的架構更新。
其實ES這樣寫的話會帶來一些很大的侵入，每次我們資料庫的一個變更都會帶來一些要RPC調用去同步ES的資料。這種瓶頸以及侵入式的問題怎麼解決？我們接入了開源的Canal，通過監聽資料庫變更了binlog，來通過Canal、kafka，然後異步通過消息來同步到ES叢集。這個叢集目前已經應用到線上的一些業務，經過灰階釋出、後期驗證沒有問題後，會逐漸接入生産系統。
如上圖所示，是我們整個訂單系統的結構。整個過程我們是通過業務網關、RPC高可用、業務聚合、DB備援、多機房部署，來保證整個訂單應用的一些系統架構高可用。上述就是整體的訂單架構演進過程。
三、訂單系統穩定性保障實踐
大家思考一下，如果你要負責一些核心系統，你怎麼保證穩定性？接下來我會從訂單系統可用性建設、系統容災能力、系統容量能力、系統預警能力分享一下我們在穩定性保障上的實踐。
訂單系統可用性建設
業務的快速發展對可用性保證要求越來越高，在方法論層面，我們按照系統故障的時間順序提出了事前、事中、事後三個階段，同時提出了四方面的能力建設——預防能力、診斷能力、解決能力、規避能力。
具體在工作上，我們會劃分為流程和系統建設兩個方面。其實最開始我們是為了完成工作，保證的是結果，最後發現每一個過程我們會把它平台化，來提升人效。以上是一個大概的架構，下面我們一項一項詳細分析一下。
系統容災能力
容災能力這塊，我們從ES冷熱叢集互備、Redis緩存叢集業務隔離，到業務接口的可降級和可異步，再到多元度的灰階釋出。
就像上面提到的，我們對開放平台、商家中心、京明管家等業務系統的支撐怎麼做到互備？其實就是通過ES的冷熱叢集，冷叢集存全量的資料，熱叢集存最近幾天的生産資料。而Redis是做業務隔離，Redis 存儲有一些大key會影響核心業務，我們就會把非核心的業務拆出來，拆到另外一個Redis叢集。這就是我們系統的業務隔離和叢集的互備。
業務接口可降級，其實是在一些複雜的業務操作接口裡，我們可以通過一些異步處理，比如在訂單狀态變更的操作接口、除了更新DB和ES、發送MQ，訂單狀态的變更通過消息去同步發送。那麼我們哪些可降低？比如說我們在業務核心操作接口裡有一些push消息和發送短信，像這樣的非核心操作就可以用異步可降級的方案來解決。
灰階釋出其實很重要，線上如果有一些新業務或系統的架構更新、技術的疊代，我們這邊都會通過灰階釋出，比如可以通過一些門店先做門店彙總，如果單個門店沒問題，再通過一些商家，如果商家沒問題，就會灰階到整個城市，如果城市也沒問題，我們就會通過全量。
另一個次元來看，我們也會先灰階單台機器，再到單機房、多機房。當然這個很局限，因為跟你灰階的一些功能有關系，大家要酌情根據自己的業務借鑒這種方案思路。
系統容量能力
至于系統容量的能力，主要分為評估和擴容兩個方面。容量評估可以借助一些輔助的工具，然後進行場景的壓測和全鍊路的壓測；而擴容方面，可以分階段依次實施備援備份（主從分離）、垂直拆分（拆分核心屬性與非核心屬性）、自動歸檔。
系統預警能力
最後是預警能力，我們這邊用的是京東自研的UMP監控。
在接口層面，我們可以監控到：
- 可用率；
- 響應時間；
- 調用量：當别人調用你的接口，你設定調用的一個量值，當超過閥值時就是進來了一些非正常的流量，當監控到這些異常流量，就可以做限流等相應操作；
- 自定義：自定義一些報警；
- 關鍵詞：當系統出現某種問題，需要關鍵字報出來然後進行人工介入；
- 調用鍊：一個接口操作下來，誰調用了你？你調用了誰？哪個環節有問題？
在應用層面，我們可以監控到：
- Young GC；
- Full GC；
- 堆記憶體；
- 非堆記憶體；
- CPU使用率；
- 線程數。
下面是關于DB、ES、Redis的叢集監控，包括：
- CPU使用率；
- 系統負載；
- 記憶體；
- 線程數；
- 讀寫IO；
- 磁盤使用率；
- TCP連接配接數。
如果大家有排查過線上的問題，就應該能感受到比如像IO高、TCP連接配接、重傳等，都會影響到線上一些核心接口的響應時間，包括你CPU高的時候，線程數是否飙高？系統負載是否飙高？當這些名額都發生異常變化時，對于接口的響應時間都會有很大影響。
另外，我們還要做一些積壓監控，比如一些異步任務正常來說一分鐘最多積壓1000，就需要添加對應的監控，否則資料異常了都不知道；再比如訂單支付的狀态，當積壓到一定數量，可能是系統出了問題，就需要人工介入。
四、總結
一個企業的架構師團隊，需要長期關注技術驅動業務、明确領域職責與邊界等關鍵問題，同時架構的演進過程也是不斷考慮ROI的權衡取舍過程。技術的持續發展，有助于不斷提升使用者體驗、業務規模，降低營運成本，而架構在其中需要解決的問題就是化繁為簡，将複雜問題拆解為簡單的問題逐個攻破。随着企業規模的持續增長、業務的持續創新，會給系統架構提出越來越高的要求，是以系統架構設計将是我們長期研究的課題。在這條架構演進之路上，希望能與大家共勉共進。
>>>>Q&A
Q1：叢集規模大概是什麼樣的？各叢集節點規模如何？
A：京東到家訂單中心ES 叢集目前大約有将近30億文檔數，資料大小約1.3TB，叢集結構是8個主分片，每個主分片有兩個副本，共24個分片。每個機器上分布1-2個分片，如果企業不差錢最好的狀态就是每個分片獨占一台機器。這些叢集規模和架構設計不應該是固定的，每一個業務系統應該根據自身實際業務去規劃設計。
這樣做确定分片數：
- ES是靜态分片，一旦分片數在建立索引時确定那麼後繼不能修改；
- 資料量在億級别，8或者16分片夠用，分片數最好是2的n次方；
- 如果後繼資料量的增長超過建立索引的預期，那麼需要建立新索引并重灌資料；
- 建立mapping是請自行制定分片數，否則建立的索引的分片數是ES的預設值。這其實并不符合需求；
- 副本數：一般設定為1，特色要求除外。
Q2：ES優化做過哪些措施？
A：ES使用最佳實踐：寫入的資料考慮清楚是否會過期，ES擅長的不是存儲而是搜尋，是以一般存入ES的資料難免會随着時間删除舊資料。删除方法有兩種：①按記錄（不推薦）②按索引。推薦使用後者，是以需要業務根據資料特點，按天、月、季度等建立索引。分片數夠用就好，不要過多不要過少。ES不是資料庫，不建議做頻繁的更新。
Q3：叢集可承受的TPS是多少？
A：這個沒有具體的數字，根據不同規模叢集、不同的索引結構等不同，建議根據業務評估自己的流量，壓測雙倍流量，若ES無法承受或滿足，可以考慮擴容叢集，不要流量暴增于平時的3倍、4倍，甚至更多的規模。
Q4：ES主要是用于明細單查詢，還是聚合統計？Join對資源耗用大嗎？如何控制記憶體及優化？
A：ES在訂單系統中的實踐主要是解決複雜查詢的問題，ES不建議使用聚合統計，如果非要使用那我也攔不住你，哈哈哈。
深分頁的問題【記憶體】
ES處理查詢的流程如下：
- Client需要第N到N+m條結果；
- 接到這個請求的ES server（後繼稱之為協調者）向每一個資料分片所在的資料節點發送請求；
- 每一個資料節點都需要向協調者傳回(N+m)個結果；
- 如果有n個資料分片，那麼協調者拿到n * (N+m)個結果，排序，扔掉(n-1) * (N+m)個結果，傳回給client N+m個結果；
- 如果N是10W，100W，那麼協調者的記憶體壓力會非常大；
- 在我們目前維護的2.1版本中，ES已經不容許N>10000了。
深分頁的危害：導緻打爆節點記憶體引起叢集整體不可用。
Q5：應用canal同步資料，會有延遲嗎？
A：首先來說下ES 特點：Elasticsearch是一個接近實時的搜尋平台。這意味着，從索引一個文檔直到這個文檔能夠被搜尋到有一個輕微的延遲（通常是1秒），這個參數也是可以調整的，根據業務場景調整。
可以肯定的是延遲是肯定的。其實延遲大小完全取決你整個同步流程中是否有瓶頸點，如果業務要求實時的，其實不建議在這種場景下使用ES。就好比資料庫查詢從庫不能接受延遲，那就不要做讀寫分離，或者都查詢主庫。
Q6：sqlproxy具體用的哪個？
A：sqlproxy這個是指MySQL讀寫分離的實作，大家可以網上查詢下有很多資料。官網位址：https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-master-slave-replication-connection.html
<mvn.jdbc.driver>com.mysql.jdbc.ReplicationDriver</mvn.jdbc.driver>
<mvn.jdbc.url>jdbc:mysql:replication://m.xxx.com:3306,s.xxx.com:3306/dbName</mvn.jdbc.url> Q7：Redis用于查詢緩存、分發任務緩存？
A：Redis在項目中的使用場景，緩存查詢，分布式鎖使用。其中還有一個異步任務是通過redis zset + tbschedule 定時或實時的去執行一些業務邏輯。
添加隊列資料方法：
public Boolean zAdd(String key, final double score, String value) ; 查詢擷取隊列資料：
public Set<String> zRangeByScore(String key, final double min, final double max) ;
Q8：容量評估可以講一些細節嘛？
A：基本有兩種場景：
- 日常業務流程是否有瓶頸 ；
- 大促期間根據流量預估系統是否有瓶頸。
京東到家内部系統是有一套完整的監控系統，基于接口，應用機器，叢集的多元度監控。
- 接口：
- 響應時間，tp99，tp999，tp9999 等；
- 接口調用量，次數/分鐘；
- 可用率。
- 應用機器
根據監控可以檢視單機器相關名額資料是否正常，比如：
- CPU使用率；
- 系統負載；
- 網絡IO；
- TCP連接配接數，線程數；
-
磁盤使用率。
- 叢集
- Redis叢集；
- ES叢集；
- MySQL叢集。
對于叢集來說是根據叢集下機器名額是否正常來評估整個叢集是否正常。需要看叢集可以承載業務流量的TPS、QPS等名額是否滿足業務需求，同時需要評估大促場景下是否可以滿足要求。這種情況就需要根據大促流量評估壓測，看叢集以及應用，接口是否可以滿足需求。
每個公司可以根據自身規則進行擴容，及架構更新。比如日常CPU超過60%考慮應用擴容，負載遠大于機器核數等等。
Q9：異步定時任務用的是什麼中間件？
A：tbschedule是一個支援分布式的排程架構，讓批量任務或者不斷變化的任務能夠被動态的配置設定到多個主機的JVM中， 在不同的線程組中并行執行，所有的任務能夠被不重複，不遺漏的快速處理。基于ZooKeeper的純Java實作，由Alibaba開源。
Q10：在雲上部署還是實體伺服器？
A：應用都部署在雲伺服器上，首先即時，幾分鐘即可完成，可一鍵部署、也可自主安裝作業系統。安全性方面因為服務分布在多台伺服器、甚至多個機房，是以不容易徹底當機，抗災容錯能力強，可以保證長時間線上。彈性以及可擴充性方面雲主機基本特點就是分布式架構，是以可以輕而易舉地增加伺服器，成倍擴充服務能力。