背景
交易系統(tǒng)可能不是技術難度最深的，但是業(yè)務復雜度最高的，一個訂單從提交到最后真正生產(chǎn)成功要經(jīng)歷幾十個系統(tǒng)，涉及的接口交互，MQ等可能達上百個。任何一個環(huán)節(jié)出問題都會導致這一單的異常，而且交易不像單純的資訊門戶可以靠靜態(tài)化或者緩存抗住大并發(fā)，交易系統(tǒng)里面涉及到大量的資源(庫存，優(yōu)惠券，優(yōu)惠碼等)消費，訂單生成等需要寫入持久化的操作不是單純的異步或者緩存化可以解決的，而且對庫存等敏感信息不能出現(xiàn)并發(fā)扣減等。
細節(jié)的設計非常多，下面挑出比較典型的一些方面，給大家介紹下京東到家交易系統(tǒng)的架構設計和關鍵問題的處理方案。
歷程
系統(tǒng)Set化
初期的訂單系統(tǒng)和首頁，單品頁，購物車業(yè)務邏輯層等都是在一個大項目里。非常適合初期人員少，業(yè)務復雜度低，快速迭代，不斷探索試錯的過程，但是隨著業(yè)務的發(fā)展，出現(xiàn)了以下問題：
系統(tǒng)的流量和業(yè)務復雜度也越來越大，大家共用一個大項目進行開發(fā)部署，相互影響，協(xié)調成本變高；
不同的業(yè)務模塊，流量和重要級別不同需要的部署策略和容災降級限流等措施也不一樣，要分而治之；
解決方案
項目Set化，這個過程中要注意Set化的邊界問題，粒度太大了效果不好，太小了設計過度了，反而會增加維護和開發(fā)成本；
分庫分表
問題
隨著訂單的并發(fā)量的不斷攀升，特別是在雙十一，618等大促的時候，單組DB(一主多從)存在著明顯的壓力，單個主庫的連接數(shù)是有限的。大單量，大并發(fā)的時候，數(shù)據(jù)庫越來越成為了我們的瓶頸。
解決方案
針對接單數(shù)據(jù)庫我們采取的常規(guī)做法分庫，根據(jù)訂單號進行Hash分布到不同的多個數(shù)據(jù)庫中，代碼方面我們是繼承了Spring的AbstractRoutingDataSource，實現(xiàn)了determineCurrentLookupKey方法。對業(yè)務代碼只有很少的耦合。
另外下發(fā)到個人中心數(shù)據(jù)庫的訂單信息，每天不斷的累計到DB中，存在以下風險：
MySQL的單表容量超過單機限制
穿透緩存到達DB的數(shù)據(jù)查詢也是非常有問題的。
目前我們采取對個人中心的表按照pin進行分庫分表。
但是對于后端生產(chǎn)系統(tǒng)對于訂單數(shù)據(jù)的查詢操作，特別是涉及到多條件組合的情況，由于數(shù)據(jù)量大，多個表數(shù)據(jù)的關聯(lián)，無論分不分表或者讀寫分離對這個場景都不能很好的解決。
這種場景下我們采用了ES，在寫入DB的時候同步寫入ES。你可能會問ES失敗了，數(shù)據(jù)不一致怎么辦，ES失敗了DB回滾，Worker標識狀態(tài)，重新迎接下一次輪詢。
前端下單和后端生產(chǎn)分離
問題
ToC端和ToB端的業(yè)務場景不同，前端對互聯(lián)網(wǎng)用戶的更多的是快速響應，抗住流量壓力，而后端的場景需要穩(wěn)定的全量的數(shù)據(jù)，要在接單的數(shù)據(jù)庫基礎上進行補全數(shù)據(jù)；兩個端職責不同，不能互相影響；
解決方案
ToC和ToB分離，前端App或者H5用戶下單和后端訂單真正的生產(chǎn)相分離；前端訂單系統(tǒng)掛掉了，不影響后端的生產(chǎn)；后端的生產(chǎn)掛了，對用戶的下單也是無感知的。只是對配送的時效體驗上會有影響，不是阻斷性的。
我們ToC的訂單系統(tǒng)和ToB的是兩個不同的獨立數(shù)據(jù)庫，互不影響；訂單管道的Woker都是基于TBSchedule的分布式管理，多個Woker并行處理，下發(fā)時機都在毫秒級；
并行控制提升效率
問題
交易的流程依賴的系統(tǒng)非常多，拿提單按鈕來舉例，結算頁的”提單”按鈕，點一次就會觸發(fā)20+個接口。隨著業(yè)務復雜度的提升，單純的串行執(zhí)行效率越來越低，前端用戶的體驗越來越差。我們要求TP999在500ms以內的響應速度。
解決方案
我們梳理了服務的依賴關系等，對沒有前后依賴的接口進行放到線程池里面異步執(zhí)行，類似：查詢庫存，查詢商品信息，查詢促銷信息等都并行執(zhí)行。此步執(zhí)行的時間，是并行接口里面最長的一個執(zhí)行的時間。這樣一來整個提單的操作提升了幾百毫秒。
另外資源(庫存，優(yōu)惠券，優(yōu)惠碼，促銷等)的消費和回滾，我們也采用了并行的方式，每一種資源類都實現(xiàn)消費和回滾的接口。如下圖：
每個資源類都是一個Task的成員變量，Task實現(xiàn)了Callable接口。這樣一來，不但整個提單大接口的效率提升了，對于資源消費和回滾環(huán)節(jié)，程序和業(yè)務的擴展性提升了很多。比如新增一種資源，這時候只需實現(xiàn)消費和回滾接口，然后扔到線程池里面就完成了。
異步
在服務端可能需要針對提單請求做一些附屬的事情，這些事情其實用戶并不關心或者用戶不需要立即拿到這些事情的處理結果，這種情況就比較適合用異步的方式處理這些事情，思路就是將訂單交易的業(yè)務整理出來，哪些是不影響主流程的，例如：發(fā)短信，保存最近使用地址，清除購物車商品，下發(fā)訂單給個人中心等等。這些都是在提單之后的異步線程去做。對于下發(fā)給個人中心的操作，如果失敗，我們會有Woker補償機制；
我們這里使用的是線程池的模式進行異步處理的，處理過程中有幾個問題需要注意下：
線程池的隊列不建議使用無界隊列，它的默認大小是整數(shù)的最大值，這樣在突發(fā)流量的時候會導致內存暴漲，影響服務；建議使用ArrayBlockingQueue
不推薦使用CallerRunsPolicy，即在線程和隊列都達到max的時候，退回此請求到主線程。這樣在突發(fā)流量或者接口提供方性能下降的時候導致主線程數(shù)暴增，影響整體服務。可以直接使用拒絕的策略，后續(xù)的Woker可以對異常單就行補償；
依賴治理
訂單交易上百個接口，幾十個系統(tǒng)交互。各服務直接的依賴關系如何治理是一個很重要的問題。如下圖：
問題
一個服務依賴這么多服務，每個服務除自身的原因外，還受到網(wǎng)絡原因等其他外部因素的影響，高并發(fā)情況下任何一個依賴的服務的波動都會造成整個大服務的阻塞，進而導致系統(tǒng)“雪崩”。
解決方案
那這些服務特別是不是阻斷流程的服務，我們可以采用降級的處理，例如調用超時了給設定默認值，調用量比較大，所依賴的服務嚴重超時并影響整個調用方時，可以通過配置直接提供有損服務，不調用此服務。
我們解決此類問題是使用自己開發(fā)的基于Zookeeper的“魯班系統(tǒng)”，其原理就是Zookeeper相應的Znode節(jié)點下的數(shù)據(jù)做為對接口的開關或者降級情況的配置等。當相應的節(jié)點的數(shù)據(jù)發(fā)生變化的時候，對此節(jié)點監(jiān)聽的所有服務器都會受到通知，并將此變更同步到本地的緩存中；本地緩存我們使用的ConcurrentHashMap。當然也可以使用Guava Cache等開源組件，注意并發(fā)的場景就可以了；
然后再結合我們的UMP監(jiān)控系統(tǒng)對系統(tǒng)的可用率，調用量等情況進行降級時機的判定，對Zookeeper相應節(jié)點的數(shù)據(jù)做動態(tài)配置；
履約
問題
針對訂單履約的過程清晰可追溯，我們自己開發(fā)了UDP上報系統(tǒng)，對一次提單中操作的所有接口，幾十個系統(tǒng)的交互進行了詳細記錄；
解決方案
出參入?yún)ⅲ欠癞惓＃琁P等信息均做了上報。通過Spring的AOP方式，開發(fā)了一個自定義注解，對添加了注解的方法UDP方式寫入到ES集群中；而且我們實現(xiàn)了工具化，任何項目引入我們的Jar包，做簡單配置就可以向我們的UDP服務端上報信息了。隨著現(xiàn)在的信息量變大，我們正在考慮升級架構，UDP Client端發(fā)送信息到Kafka，然后Storm實時在線分析形成最終需要的數(shù)據(jù)落地到ES集群中；
此系統(tǒng)大大提升了我們定位解決問題的效率。