從單一架構到分散式交易架構，網易嚴選的成功實踐

作者｜馬超

編輯｜薛梁

過去兩年嚴選提出並設計了統一售後模型、最大可退金額、和多級退款引擎等概念，抽象出了銷退支持、上門取件、極速退款、售後風控等通用能力，經過幾次架構演變，有效的降低了業務邏輯耦合和複雜度，可以做到上層業務的快速搭建和服務接入。

作為電商產品，交易在嚴選的業務中承擔著重要的角色。隨著業務的不斷發展，交易場景的定製化和差異化開始凸顯，同時第三方支付合作方的接入也越來越多，如何在保證交易服務安全穩定的同時做到良好的擴展和彈性是近一年嚴選在分散式交易架構中思考和實踐的重點。

很榮幸，InfoQ 採訪了網易嚴選技術經理，ArchSummit 全球架構師技術峰會講師 馬超，從核心數據模型迭代、服務架構演變等方面介紹嚴選商城在交易環節的分散式技術架構實踐。（馬超也會在 7 月深圳 ArchSummit 峰會上分享《大道至簡 - 嚴選售後服務架構演變實踐》話題）

（為便於完整展示嚴選技術迭代歷程，文章將對話在不改變原意的基礎上進行第一人稱改寫）

嚴選分散式交易架構演變簡史

嚴選把交易環節定義為能夠促成買家和賣家達成契約的動態過程，而不是簡單的把交易和支付直接畫上等號。在大多數電商領域，除了貨到付款等特殊場景，契約一般都以支付成功的訂單形式達成，因此交易架構需要能夠很好的支持電商最核心的下單和支付環節。

初期刀耕火種階段，嚴選商城業務量小，商品數量少且差異小，用戶從購物車到下單再到支付的交易模式相對單一。於是在結算頁面生成訂單的同時，資料庫中冗餘了一條支付相關的記錄，使支付的金額和訂單結算金額保持一致。然後以此為中介通過一個簡單的支付服務來對接微信、支付寶、網易支付三大支付機構，引導用戶在客戶端完成訂單支付，最終再把支付記錄的狀態同步到訂單中去。整個架構簡單直接，運轉起來也非常高效。

早期刮骨療傷階段，隨著業務發展，嚴選交易場景開始出現多樣化和差異化。最開始是在支付環節，比如聯合登錄帳號體系的建立帶來了更多第三方支付機構的接入，我們發現這些第三方支付機構的接入標準和方式存在較大差異，甚至交互模式都有所不同，同時以企業購、拼團為代表的獨立業務模塊也迅速發展起來，這些業務的訂單生命周期和規則不同，存儲也比較離散，很難與原有的支付服務中的支付記錄建立映射關係。原有架構多個功能模塊糅雜在一起顯得臃腫並且不好擴展，線上質量也無法保證。因此我們快馬加鞭做了架構調整與服務拆分，將支付服務拆分為支付系統和收銀台系統，支付系統的範疇縮小到主站訂單支付狀態管理；而外部支付機構的收銀、退款等業務都交給收銀台系統負責，將訂單與支付信息的關聯換成了嚴選內部唯一的交易流水號。

嚴選收銀台架構圖

通過架構升級，能夠實現比較靈活的配置能力，不同帳號在不同產品模塊和終端上可以看到不同的收銀定製頁面，極大的滿足了上層業務方的訴求。同時收銀台屏蔽了對接第三方的模式差異和複雜性，在設計中將支付通知服務、退款服務全部統一成非同步回調模式，降低了上層業務接入的複雜性。

中期韜光養晦發展階段，在支付環節經歷架構升級的同時，商品的差異性也開始對下單交易環節產生影響，比如商品類別屬性和商品運費。這裡以禮品卡為例，禮品卡是一種特殊的商品，用戶購買綁定後可以作為資金在交易環節使用，電子禮品卡不需要履約配送，但是需要對接額外的制卡服務，此外在禮品卡購買過程中還需要根據金額判斷是否需要實名認證。在初始的架構中我們對這種商品在交易的每個環節都做特殊處理，但是耦合比較深，隨著虛擬商品 (點卡、話費) 和非標準商品 (眼鏡、定製品) 的不斷出現，技術團隊對原有架構做了升級，抽象出了交易模板的概念，交易模板可以在結算頁面提供定製能力，比如是否可以使用禮品卡、是否可以使用優惠券 / 紅包、是否需要用戶填寫額外的附加信息。不同交易模板產生的訂單還會附加上不同的交易標識，用於後續的業務模塊對接和訂單中心處理。

目前百花齊放階段，我們正在著手的工作是禮品卡平台化，提供可以配置的禮品卡的消耗和逆向策略，使其和支付系統、收銀台系統共同構建嚴選的基礎交易服務矩陣。同時還在考慮擴展交易模板的能力，以其為中心能有效的把下單結算環節和基礎交易服務矩陣有效連接在一起，通過平台配置化能力支持不同業務模式下的交易場景。

未來，嚴選規劃能在現有交易架構逐漸立體化的情況下更近一步，形成完整的嚴選交易中心平台，交易中心平台不僅囊括了包括購物車服務，下單服務，支付服務在內的通用交易能力，還將提供完整交易的編排能力，為上層業務提供更加可靠的支持。同時在嚴選模式往線下拓展的情況下，也在主動探索交易模式的線下場景化，實現線上線下數據打通，為消費者帶來更好的購物體驗。

交易架構實踐過程中的技術積累

在嚴選整個分散式架構演變過程中，一方面很好的滿足了系統高可用高吞吐的訴求；另一方面，像大部分互聯網公司一樣，也碰到分散式架構中常見的數據一致性、資源均衡性等問題。在解決這些問題的過程中，慢慢沉澱出了嚴選自己的一些中間件。

交易流程管理 - 分散式鎖和分散式事務

首先來說分散式鎖。dlock 是嚴選可重入、可阻塞、可超時、高可用、高性能、低成本、可彈性伸縮的分散式鎖中間件（整體架構如下圖所示），其設計目標主要有兩個：

對分散式環境下資源的訪問進行同步，適合多機器、多進程、多線程、單線程等場景；

替換高開銷、高成本、擴展性差的資料庫鎖。

dlock 可適配多種類型的緩存基礎實施，比如 Redis、Memcached、Zookeeper 等，dlock 的容量可根據需求水平伸縮。

dlock 支持 3 種不同類型的鎖重入策略，分別為：線程級重入、進程級重入、分散式重入，這些重入策略可以完全滿足嚴選業務各複雜場景對對分散式鎖的訴求。

其次是分散式事務。為了解決交易過程中分散式系統之間數據的一致性，嚴選自研了分散式事務中間件 DTS。DTS遵循 BASE類型，是一種典型的 TCC(Try/Confirm/Cancel)類型事務，整個 DTS的架構如下圖所示：

DTS針對兩階段提交做了優化，叫做最末參與者優化 (LPO):分散式事務發起者沒有兩階段，只有單階段，即在所有參與者第一階段準備好後，它的提交結果直接決定分散式事務的成功與否。

交易資源管理 - 核心資源隔離機制與策略

為了攔截刷單、攻擊等異常流量，同時也對正常用戶流量進行合理限制，嚴選自研流量限制 & 應急熔斷中間件 eudemon。eudemon 將對 CPU、MEM、DB 等資源訪問的抽象前移到方法調用、頁面訪問的層面，通過對方法調用、頁面訪問的限制間接達到對資源過載的保護。eudemon 的整體架構如下圖所示：

eudemon 對流量進行了兩個層面的控制：

攔截刷單和攻擊流量：通過對流量主體的行為特徵進行分析可以攔截掉 99% 以上的刷單和攻擊流量，不讓這些黑產流量來與正常流量競爭系統資源，同時減輕下游風控系統的壓力。

正常流量的控制與熔斷：對正常用戶流量進行合理限制，削峰填谷，始終保證湧入的流量不超過系統的負載，同時在緊急情況下對業務進行熔斷。

如何做資源隔離？系統越來越趨向於分散式架構，服務節點越多，級聯失敗導致單節點故障在分散式架構下被放大。在專註於流入流控 eudemon 之外，嚴選研發了一個專註於流出流控的資源隔離中間件 aegis。

分散式鏈路中，一個服務依賴的多個下游服務時，因為某一個下游服務不可用或者響應很慢會影響當前服務甚至引起雪崩效應。我們之前線上碰到的比較典型的就慢 SQL，一個慢 SQL 的出現導致資料庫的 load 飆升，導致 DB 基本短時突發性不可用，從而導致整個服務或系統的不可用。

aegis 的資源隔離流程如上圖所示，使用了動態隔離機制，可以按業務維度進行隔離。比如使用分散式資料庫的場景，可以只對其中某一個出現故障的 DB Node 進行隔離，而不是對整個分散式資料庫進行隔離。

總結與思考 - 嚴選中間件實踐的核心理念

嚴選中間件一直以來都秉承以最低成本解決最核心技術問題的理念，秉承技術驅動業務的信仰，始終以業務為核心做好 360 度支撐。中間件的建設遵循「開源 + 自研」的雙引擎模式，開源為主，自研為輔，反饋開源。站在開源巨人的肩上，可以降低嚴選的研發成本，通過自研又可以很好的彌補開源的不足，通過反饋開源為開源世界的繁榮反哺嚴選的技術力量。

大促交易中的挑戰與應對之道

電商中的大促是對架構設計和平時技術積累的最好考驗。作為一種特殊的高並發場景，其峰值往往是平時的數倍甚至幾個數量級的差距，一些看似穩定的系統和服務在極端的並發情況下也可能暴露出問題。

周期較短的大促活動中，交易鏈路顯得尤為重要，從購物車到下單再到支付，任何一個環節出現故障都可能會影響到運營活動的效果。回顧嚴選在歷次大促中的表現，交易系統面臨的主要挑戰有這幾類：

資料庫資源的合理使用

支付服務的穩定性和及時性

外部攻擊的防禦

資料庫是交易系統依賴比較重的組件，對數據一致性要求非常高。以下單為例，我們一般會使用事務來保證強一致性，不過隨著業務的發展，事務變得臃腫，在高並發場景下性能變差，資料庫資源很容易成為瓶頸，輕則影響部分數據節點，重則影響整個下單服務甚至整個交易環節。為了保障大促，嚴選對事務進行了拆解，梳理出核心業務和非核心業務，非核心業務盡量採用非同步化和補償的機制來完成，核心業務的事務粒度降低到最低，採用分散式鎖和分散式事務進行落地。拆解後，事務大小趨於合理，同時在 DDB(網易分散式資料庫) 中，選擇合適的用戶分區策略，把不同用戶的事務有效分布到不同的資料庫節點上，避免熱點問題。

支付的穩定性和及時性是另外一個比較大的挑戰，大促中如果支付服務發生抖動或者回調不及時都可能在短時間內給用戶造成比較大的利益損失，客訴也會增多。在增強監控的前提下，我們還會對資源進行嚴格的隔離和劃分，保留一定的機動性，及時隔離一些服務不穩定的渠道。同時還會準備好主動查詢以及重試的策略，在回調發生故障時能夠及時切換到備用方式。同時還在用戶端做了一個小優化，增加了一個支付處理中的等待文案給用戶以安撫。

此外，交易系統也可能受到外部攻擊的威脅，線上的刷單、刷券等惡意行為時有發生，如果直接使交易介面暴露在攻擊下，交易資源就會發生傾斜，嚴重的可能拖垮整個服務系統。因此我們在交易系統外構建一個可靠的防護罩來保護核心用戶的利益。和業界的普遍做法類似，嚴選的防禦也從入口層開始，通過訪問特徵識別惡意請求進行第一道防禦；在業務服務之上，還有了一個介面粒度的防護組件，可以通過 mvel 語法對交易環節的重點介面進行干預；核心交易業務服務邏輯中一般還會接入風控查詢介面，對用戶進行精準分析。通過這三層防護，嚴選的核心鏈路得到了有效的安全保證。

最後說說嚴選的大促保障流程與策略，主要分為三個階段。

首先是評估階段，以資源評估準備和壓測為主。通過分解大促測算的指標，設定系統關鍵交易鏈路的介面吞吐以及響應指標，評估現有系統容量是否滿足要求並制定相應的擴容方案。同時在模塊壓測以及全鏈路壓測中了解服務的現有指標，結合測試報告分析出瓶頸並制定優化方案。

然後是準備階段，在這個階段我們會詳細制定大促交易環節的限流降級以及容災預案，比如針對秒殺交易場景，也會準備至少兩套庫存管理方案，當服務出現故障時能夠及時進行切換。所有的交易環節確認是否有監控缺失，從購物車到結算頁到收銀完成針對每一個潛在的交易失敗的場景制定相關的發現、解決和補償計劃，並落實到具體負責人身上。預案全部完成後會和測試一起通過全鏈路壓測與局部模塊測試進行有效性驗證。

最後是實施階段，即便做了充分的準備，線上還是可能出現各種意外的狀況，當大促中發生故障時，及時止損是第一原則，這時候準備的限流甚至熔斷等預案都是可能派上用場的，同時要立馬著手分析原因並做出最小代價的修復方案，即時發布到線上。

作者介紹

馬超，網易嚴選技術經理，2013 年加入網易郵件事業部，曾先後參與了多款網易郵箱產品的研發工作。2015 年開始負責嚴選商城的研發工作，兩年以來主導完成了多次技術架構的改造和演變，推動嚴選業務的高速發展。同時帶領團隊歷經多次大促，保障系統的穩定。在高並發、分散式、業務系統優化和中間件研發等領域有較豐富的實踐經驗。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！