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

細節的設計非常多，下面挑出比較典型的一些方面，給大家介紹下京東到家交易系統的架構設計和關鍵問題的處理方案。

歷程
系統Set化
初期的訂單系統和首頁，單品頁，購物車業務邏輯層等都是在一個大項目里。非常適合初期人員少，業務復雜度低，快速迭代，不斷探索試錯的過程，但是隨著業務的發展，出現了以下問題：

系統的流量和業務復雜度也越來越大，大家共用一個大項目進行開發部署，相互影響，協調成本變高；
不同的業務模塊，流量和重要級別不同需要的部署策略和容災降級限流等措施也不一樣，要分而治之；

解決方案
項目Set化，這個過程中要注意Set化的邊界問題，粒度太大了效果不好，太小了設計過度了，反而會增加維護和開發成本；

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

解決方案
針對接單數據庫我們采取的常規做法分庫，根據訂單號進行Hash分布到不同的多個數據庫中，代碼方面我們是繼承了Spring的AbstractRoutingDataSource，實現了determineCurrentLookupKey方法。對業務代碼只有很少的耦合。

另外下發到個人中心數據庫的訂單信息，每天不斷的累計到DB中，存在以下風險：

MySQL的單表容量超過單機限制
穿透緩存到達DB的數據查詢也是非常有問題的。
目前我們采取對個人中心的表按照pin進行分庫分表。
但是對于后端生產系統對于訂單數據的查詢操作，特別是涉及到多條件組合的情況，由于數據量大，多個表數據的關聯，無論分不分表或者讀寫分離對這個場景都不能很好的解決。

這種場景下我們采用了ES，在寫入DB的時候同步寫入ES。你可能會問ES失敗了，數據不一致怎么辦，ES失敗了DB回滾，Worker標識狀態，重新迎接下一次輪詢。

前端下單和后端生產分離
問題
ToC端和ToB端的業務場景不同，前端對互聯網用戶的更多的是快速響應，抗住流量壓力，而后端的場景需要穩定的全量的數據，要在接單的數據庫基礎上進行補全數據；兩個端職責不同，不能互相影響；

解決方案
ToC和ToB分離，前端App或者H5用戶下單和后端訂單真正的生產相分離；前端訂單系統掛掉了，不影響后端的生產；后端的生產掛了，對用戶的下單也是無感知的。只是對配送的時效體驗上會有影響，不是阻斷性的。

我們ToC的訂單系統和ToB的是兩個不同的獨立數據庫，互不影響；訂單管道的Woker都是基于TBSchedule的分布式管理，多個Woker并行處理，下發時機都在毫秒級；

并行控制提升效率
問題
交易的流程依賴的系統非常多，拿提單按鈕來舉例，結算頁的”提單”按鈕，點一次就會觸發20+個接口。隨著業務復雜度的提升，單純的串行執行效率越來越低，前端用戶的體驗越來越差。我們要求TP999在500ms以內的響應速度。

解決方案
我們梳理了服務的依賴關系等，對沒有前后依賴的接口進行放到線程池里面異步執行，類似：查詢庫存，查詢商品信息，查詢促銷信息等都并行執行。此步執行的時間，是并行接口里面最長的一個執行的時間。這樣一來整個提單的操作提升了幾百毫秒。

另外資源(庫存，優惠券，優惠碼，促銷等)的消費和回滾，我們也采用了并行的方式，每一種資源類都實現消費和回滾的接口。如下圖：

每個資源類都是一個Task的成員變量，Task實現了Callable接口。這樣一來，不但整個提單大接口的效率提升了，對于資源消費和回滾環節，程序和業務的擴展性提升了很多。比如新增一種資源，這時候只需實現消費和回滾接口，然后扔到線程池里面就完成了。

異步
在服務端可能需要針對提單請求做一些附屬的事情，這些事情其實用戶并不關心或者用戶不需要立即拿到這些事情的處理結果，這種情況就比較適合用異步的方式處理這些事情，思路就是將訂單交易的業務整理出來，哪些是不影響主流程的，例如：發短信，保存最近使用地址，清除購物車商品，下發訂單給個人中心等等。這些都是在提單之后的異步線程去做。對于下發給個人中心的操作，如果失敗，我們會有Woker補償機制；

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

線程池的隊列不建議使用無界隊列，它的默認大小是整數的最大值，這樣在突發流量的時候會導致內存暴漲，影響服務；建議使用ArrayBlockingQueue
不推薦使用CallerRunsPolicy，即在線程和隊列都達到max的時候，退回此請求到主線程。這樣在突發流量或者接口提供方性能下降的時候導致主線程數暴增，影響整體服務。可以直接使用拒絕的策略，后續的Woker可以對異常單就行補償；
依賴治理
訂單交易上百個接口，幾十個系統交互。各服務直接的依賴關系如何治理是一個很重要的問題。如下圖：

問題
一個服務依賴這么多服務，每個服務除自身的原因外，還受到網絡原因等其他外部因素的影響，高并發情況下任何一個依賴的服務的波動都會造成整個大服務的阻塞，進而導致系統“雪崩”。

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

我們解決此類問題是使用自己開發的基于Zookeeper的“魯班系統”，其原理就是Zookeeper相應的Znode節點下的數據做為對接口的開關或者降級情況的配置等。當相應的節點的數據發生變化的時候，對此節點監聽的所有服務器都會受到通知，并將此變更同步到本地的緩存中；本地緩存我們使用的ConcurrentHashMap。當然也可以使用Guava Cache等開源組件，注意并發的場景就可以了；

然后再結合我們的UMP監控系統對系統的可用率，調用量等情況進行降級時機的判定，對Zookeeper相應節點的數據做動態配置；

履約
問題
針對訂單履約的過程清晰可追溯，我們自己開發了UDP上報系統，對一次提單中操作的所有接口，幾十個系統的交互進行了詳細記錄；

解決方案
出參入參，是否異常，IP等信息均做了上報。通過Spring的AOP方式，開發了一個自定義注解，對添加了注解的方法UDP方式寫入到ES集群中；而且我們實現了工具化，任何項目引入我們的Jar包，做簡單配置就可以向我們的UDP服務端上報信息了。隨著現在的信息量變大，我們正在考慮升級架構，UDP Client端發送信息到Kafka，然后Storm實時在線分析形成最終需要的數據落地到ES集群中；

此系統大大提升了我們定位解決問題的效率。