背景
交易系統(tǒng)可能不是技術(shù)難度最深的，但是業(yè)務(wù)復(fù)雜度最高的，一個(gè)訂單從提交到最后真正生產(chǎn)成功要經(jīng)歷幾十個(gè)系統(tǒng)，涉及的接口交互，MQ等可能達(dá)上百個(gè)。任何一個(gè)環(huán)節(jié)出問題都會(huì)導(dǎo)致這一單的異常，而且交易不像單純的資訊門戶可以靠靜態(tài)化或者緩存抗住大并發(fā)，交易系統(tǒng)里面涉及到大量的資源(庫(kù)存，優(yōu)惠券，優(yōu)惠碼等)消費(fèi)，訂單生成等需要寫入持久化的操作不是單純的異步或者緩存化可以解決的，而且對(duì)庫(kù)存等敏感信息不能出現(xiàn)并發(fā)扣減等。

細(xì)節(jié)的設(shè)計(jì)非常多，下面挑出比較典型的一些方面，給大家介紹下京東到家交易系統(tǒng)的架構(gòu)設(shè)計(jì)和關(guān)鍵問題的處理方案。

歷程
系統(tǒng)Set化
初期的訂單系統(tǒng)和首頁(yè)，單品頁(yè)，購(gòu)物車業(yè)務(wù)邏輯層等都是在一個(gè)大項(xiàng)目里。非常適合初期人員少，業(yè)務(wù)復(fù)雜度低，快速迭代，不斷探索試錯(cuò)的過程，但是隨著業(yè)務(wù)的發(fā)展，出現(xiàn)了以下問題：

系統(tǒng)的流量和業(yè)務(wù)復(fù)雜度也越來(lái)越大，大家共用一個(gè)大項(xiàng)目進(jìn)行開發(fā)部署，相互影響，協(xié)調(diào)成本變高；
不同的業(yè)務(wù)模塊，流量和重要級(jí)別不同需要的部署策略和容災(zāi)降級(jí)限流等措施也不一樣，要分而治之；

解決方案
項(xiàng)目Set化，這個(gè)過程中要注意Set化的邊界問題，粒度太大了效果不好，太小了設(shè)計(jì)過度了，反而會(huì)增加維護(hù)和開發(fā)成本；

分庫(kù)分表
問題
隨著訂單的并發(fā)量的不斷攀升，特別是在雙十一，618等大促的時(shí)候，單組DB(一主多從)存在著明顯的壓力，單個(gè)主庫(kù)的連接數(shù)是有限的。大單量，大并發(fā)的時(shí)候，數(shù)據(jù)庫(kù)越來(lái)越成為了我們的瓶頸。

解決方案
針對(duì)接單數(shù)據(jù)庫(kù)我們采取的常規(guī)做法分庫(kù)，根據(jù)訂單號(hào)進(jìn)行Hash分布到不同的多個(gè)數(shù)據(jù)庫(kù)中，代碼方面我們是繼承了Spring的AbstractRoutingDataSource，實(shí)現(xiàn)了determineCurrentLookupKey方法。對(duì)業(yè)務(wù)代碼只有很少的耦合。

另外下發(fā)到個(gè)人中心數(shù)據(jù)庫(kù)的訂單信息，每天不斷的累計(jì)到DB中，存在以下風(fēng)險(xiǎn)：

MySQL的單表容量超過單機(jī)限制
穿透緩存到達(dá)DB的數(shù)據(jù)查詢也是非常有問題的。
目前我們采取對(duì)個(gè)人中心的表按照pin進(jìn)行分庫(kù)分表。
但是對(duì)于后端生產(chǎn)系統(tǒng)對(duì)于訂單數(shù)據(jù)的查詢操作，特別是涉及到多條件組合的情況，由于數(shù)據(jù)量大，多個(gè)表數(shù)據(jù)的關(guān)聯(lián)，無(wú)論分不分表或者讀寫分離對(duì)這個(gè)場(chǎng)景都不能很好的解決。

這種場(chǎng)景下我們采用了ES，在寫入DB的時(shí)候同步寫入ES。你可能會(huì)問ES失敗了，數(shù)據(jù)不一致怎么辦，ES失敗了DB回滾，Worker標(biāo)識(shí)狀態(tài)，重新迎接下一次輪詢。

前端下單和后端生產(chǎn)分離
問題
ToC端和ToB端的業(yè)務(wù)場(chǎng)景不同，前端對(duì)互聯(lián)網(wǎng)用戶的更多的是快速響應(yīng)，抗住流量壓力，而后端的場(chǎng)景需要穩(wěn)定的全量的數(shù)據(jù)，要在接單的數(shù)據(jù)庫(kù)基礎(chǔ)上進(jìn)行補(bǔ)全數(shù)據(jù)；兩個(gè)端職責(zé)不同，不能互相影響；

解決方案
ToC和ToB分離，前端App或者H5用戶下單和后端訂單真正的生產(chǎn)相分離；前端訂單系統(tǒng)掛掉了，不影響后端的生產(chǎn)；后端的生產(chǎn)掛了，對(duì)用戶的下單也是無(wú)感知的。只是對(duì)配送的時(shí)效體驗(yàn)上會(huì)有影響，不是阻斷性的。

我們ToC的訂單系統(tǒng)和ToB的是兩個(gè)不同的獨(dú)立數(shù)據(jù)庫(kù)，互不影響；訂單管道的Woker都是基于TBSchedule的分布式管理，多個(gè)Woker并行處理，下發(fā)時(shí)機(jī)都在毫秒級(jí)；

并行控制提升效率
問題
交易的流程依賴的系統(tǒng)非常多，拿提單按鈕來(lái)舉例，結(jié)算頁(yè)的”提單”按鈕，點(diǎn)一次就會(huì)觸發(fā)20+個(gè)接口。隨著業(yè)務(wù)復(fù)雜度的提升，單純的串行執(zhí)行效率越來(lái)越低，前端用戶的體驗(yàn)越來(lái)越差。我們要求TP999在500ms以內(nèi)的響應(yīng)速度。

解決方案
我們梳理了服務(wù)的依賴關(guān)系等，對(duì)沒有前后依賴的接口進(jìn)行放到線程池里面異步執(zhí)行，類似：查詢庫(kù)存，查詢商品信息，查詢促銷信息等都并行執(zhí)行。此步執(zhí)行的時(shí)間，是并行接口里面最長(zhǎng)的一個(gè)執(zhí)行的時(shí)間。這樣一來(lái)整個(gè)提單的操作提升了幾百毫秒。

另外資源(庫(kù)存，優(yōu)惠券，優(yōu)惠碼，促銷等)的消費(fèi)和回滾，我們也采用了并行的方式，每一種資源類都實(shí)現(xiàn)消費(fèi)和回滾的接口。如下圖：

每個(gè)資源類都是一個(gè)Task的成員變量，Task實(shí)現(xiàn)了Callable接口。這樣一來(lái)，不但整個(gè)提單大接口的效率提升了，對(duì)于資源消費(fèi)和回滾環(huán)節(jié)，程序和業(yè)務(wù)的擴(kuò)展性提升了很多。比如新增一種資源，這時(shí)候只需實(shí)現(xiàn)消費(fèi)和回滾接口，然后扔到線程池里面就完成了。

異步
在服務(wù)端可能需要針對(duì)提單請(qǐng)求做一些附屬的事情，這些事情其實(shí)用戶并不關(guān)心或者用戶不需要立即拿到這些事情的處理結(jié)果，這種情況就比較適合用異步的方式處理這些事情，思路就是將訂單交易的業(yè)務(wù)整理出來(lái)，哪些是不影響主流程的，例如：發(fā)短信，保存最近使用地址，清除購(gòu)物車商品，下發(fā)訂單給個(gè)人中心等等。這些都是在提單之后的異步線程去做。對(duì)于下發(fā)給個(gè)人中心的操作，如果失敗，我們會(huì)有Woker補(bǔ)償機(jī)制；

我們這里使用的是線程池的模式進(jìn)行異步處理的，處理過程中有幾個(gè)問題需要注意下：

線程池的隊(duì)列不建議使用無(wú)界隊(duì)列，它的默認(rèn)大小是整數(shù)的最大值，這樣在突發(fā)流量的時(shí)候會(huì)導(dǎo)致內(nèi)存暴漲，影響服務(wù)；建議使用ArrayBlockingQueue
不推薦使用CallerRunsPolicy，即在線程和隊(duì)列都達(dá)到max的時(shí)候，退回此請(qǐng)求到主線程。這樣在突發(fā)流量或者接口提供方性能下降的時(shí)候?qū)е轮骶€程數(shù)暴增，影響整體服務(wù)。可以直接使用拒絕的策略，后續(xù)的Woker可以對(duì)異常單就行補(bǔ)償；
依賴治理
訂單交易上百個(gè)接口，幾十個(gè)系統(tǒng)交互。各服務(wù)直接的依賴關(guān)系如何治理是一個(gè)很重要的問題。如下圖：

問題
一個(gè)服務(wù)依賴這么多服務(wù)，每個(gè)服務(wù)除自身的原因外，還受到網(wǎng)絡(luò)原因等其他外部因素的影響，高并發(fā)情況下任何一個(gè)依賴的服務(wù)的波動(dòng)都會(huì)造成整個(gè)大服務(wù)的阻塞，進(jìn)而導(dǎo)致系統(tǒng)“雪崩”。

解決方案
那這些服務(wù)特別是不是阻斷流程的服務(wù)，我們可以采用降級(jí)的處理，例如調(diào)用超時(shí)了給設(shè)定默認(rèn)值，調(diào)用量比較大，所依賴的服務(wù)嚴(yán)重超時(shí)并影響整個(gè)調(diào)用方時(shí)，可以通過配置直接提供有損服務(wù)，不調(diào)用此服務(wù)。

我們解決此類問題是使用自己開發(fā)的基于Zookeeper的“魯班系統(tǒng)”，其原理就是Zookeeper相應(yīng)的Znode節(jié)點(diǎn)下的數(shù)據(jù)做為對(duì)接口的開關(guān)或者降級(jí)情況的配置等。當(dāng)相應(yīng)的節(jié)點(diǎn)的數(shù)據(jù)發(fā)生變化的時(shí)候，對(duì)此節(jié)點(diǎn)監(jiān)聽的所有服務(wù)器都會(huì)受到通知，并將此變更同步到本地的緩存中；本地緩存我們使用的ConcurrentHashMap。當(dāng)然也可以使用Guava Cache等開源組件，注意并發(fā)的場(chǎng)景就可以了；

然后再結(jié)合我們的UMP監(jiān)控系統(tǒng)對(duì)系統(tǒng)的可用率，調(diào)用量等情況進(jìn)行降級(jí)時(shí)機(jī)的判定，對(duì)Zookeeper相應(yīng)節(jié)點(diǎn)的數(shù)據(jù)做動(dòng)態(tài)配置；

履約
問題
針對(duì)訂單履約的過程清晰可追溯，我們自己開發(fā)了UDP上報(bào)系統(tǒng)，對(duì)一次提單中操作的所有接口，幾十個(gè)系統(tǒng)的交互進(jìn)行了詳細(xì)記錄；

解決方案
出參入?yún)ⅲ欠癞惓＃琁P等信息均做了上報(bào)。通過Spring的AOP方式，開發(fā)了一個(gè)自定義注解，對(duì)添加了注解的方法UDP方式寫入到ES集群中；而且我們實(shí)現(xiàn)了工具化，任何項(xiàng)目引入我們的Jar包，做簡(jiǎn)單配置就可以向我們的UDP服務(wù)端上報(bào)信息了。隨著現(xiàn)在的信息量變大，我們正在考慮升級(jí)架構(gòu)，UDP Client端發(fā)送信息到Kafka，然后Storm實(shí)時(shí)在線分析形成最終需要的數(shù)據(jù)落地到ES集群中；

此系統(tǒng)大大提升了我們定位解決問題的效率。