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

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

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

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

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

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

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

前端下單和后端生產(chǎn)分離
問(wè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í)；

并行控制提升效率
問(wèn)題
交易的流程依賴的系統(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ì)沒(méi)有前后依賴的接口進(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)物車(chē)商品，下發(fā)訂單給個(gè)人中心等等。這些都是在提單之后的異步線程去做。對(duì)于下發(fā)給個(gè)人中心的操作，如果失敗，我們會(huì)有Woker補(bǔ)償機(jī)制；

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

線程池的隊(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è)很重要的問(wèn)題。如下圖：

問(wèn)題
一個(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í)，可以通過(guò)配置直接提供有損服務(wù)，不調(diào)用此服務(wù)。

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

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

解決方案
出參入?yún)ⅲ欠癞惓＃琁P等信息均做了上報(bào)。通過(guò)Spring的AOP方式，開(kāi)發(fā)了一個(gè)自定義注解，對(duì)添加了注解的方法UDP方式寫(xiě)入到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)大大提升了我們定位解決問(wèn)題的效率。