業務百倍增加，得物如何在三個月完成交易平臺重構？

嘉賓 | 陳思淼、金思宇

得物 App 專一打造新一代潮流網購社區。截止到目前，得物 App 平臺用戶中，90 後佔比超過八成。品牌升級和業務增加的同時，對應的業務架構和技術體系也須要更新迭代。

2020 年 3 月 16 日，得物技術團隊在三個月的時間內完成了整個交易體系的重構，交付了交易平臺化項目——五彩石項目。整個項目從新設計了 6 個核心交易應用，完成 180 項操做，21 個系統從新發布，相應的優化迭代還涵蓋了社區、交易、供應鏈的解耦，交易平臺化的演進、底層交互協議的更新、全鏈路壓測落地等等。爲了瞭解五彩石項目的整個構建過程，InfoQ 採訪了得物 App CTO 陳思淼、交易平臺和穩定性平臺負責人金思宇。

1 電商平臺業務架構的發展

電商起源於 1990 年，經歷了 30 年的發展，如今電商平臺已經成爲了主流購物方式之一。若是從業務架構的角度來看，中國電商平臺經歷了幾個發展階段呢？陳思淼和金思宇從各自的工做經歷出發，表示中國電商平臺的業務架構都經歷了類似的四個階段。

第一階段：一般這時的電商平臺都是從零開始搭建的，全家桶系統，包含最基礎的交易元素：用戶、商品、庫存、訂單、支付。這些功能可能只是一個系統中的多個子模塊，甚至只是一個簡單的類，能夠知足最基礎的交易需求。

第二階段：隨着業務規模逐漸增大，團隊人數也愈來愈多，整個平臺維護難度增長，耦合嚴重，性能瓶頸也逐漸出現。這時就會開始作系統拆分，從業務域、基礎服務、先後端分離的角度慢慢分割，拆分後的系統之間進行通訊 (同步 / 異步)。

第三階段：分佈式服務，系統拆分以後，雖然各個服務會有多個團隊分別負責，職責清晰。不過服務之間的通訊增多、依賴關係逐漸複雜，甚至須要支撐業務量會更大，這時就會對服務治理、監控、緩存、數據分片、分佈式事務等基礎建設有更高的要求。

第四階段：隨着業務發展，在分佈式服務的基礎上，對服務穩定性、高可用等方面須要有更高的要求。淘系作了單元化、異地多活以後，這基本上變成了多個電商甚至外賣平臺追求的統一思路；而在容器化逐漸流行起來後，基於容器化作彈性資源管理以及混合雲 (異地多活) 就變成了另外一種趨勢。

與其它平臺相比，電商平臺在數據準確性、一致性、安全性，以及服務性能、服務穩定性方面都有比較高的要求，並且一旦出問題很容易被放大

因此，在作電商平臺的系統設計和落地時，應當着重考慮如下幾個方面：

• 是否在覈心鏈路上，對於電商平臺，交易瀏覽鏈路及下單 & 支付鏈路 (包含優惠活動 & 券) 屬於核心鏈路，須要評估應用是否會對核心鏈路形成影響，以及屬於強依賴仍是弱依賴；
• 容量評估，包括峯值 QPS、每日產生的數據量，進而確認是否須要引入緩存、DB 選型（MySQL/TiDB）、數據是否須要 sharding、是否須要配置限流等；
• 性能評估，包括上下游依賴、對業務流程的影響、交互採用同步仍是異步、對總體 RT 的影響等；對於核心鏈路上的服務，會在上線前作壓測評估；
• 對數據穩定性的影響，包括對原有庫表 & 索引的影響、對原有數據字段的影響、上下游數據一致性影響等。

2 得物交易平臺的差別與發展

得物 App 技術平臺構建能夠追溯到 2015 年。當時，得物 App 第一版以潮流社區 App 上線，打造國內主流 Sneaker 互動社區（2015 年 9 月 -2017 年初）。後來，基於對潮流文化的瞭解和年輕消費的洞察，慢慢發現社區內不少用戶有鑑別的強需求，才衍生出了交易業務 (2017 年下半年)。

得物與其它電商最大的區別是什麼呢？得物 CTO 陳思淼表示最大的區別就是交易流程中包含鑑別環節，一次交易存在強參與三個角色：買家、平臺、賣家，而不像傳統電商，平臺不少時候只是提供流量入口。固然相應的，由於平臺的「強中心化」深度介入，一筆訂單對於賣家視角和買家視角，其生命週期並不相同，以現貨交易爲例，對於賣家而言，平臺收到商品而且鑑別經過，就會收到貨款，這筆訂單對他而言也就達到了終態；而對於買家，只有在收到貨以後纔多是終態。

除此以外，因爲得物定位是潮流電商，所以對於平臺內銷售的商品，其潮流屬性以及可否被鑑別有必定標準，全部商品都是平臺統一維護（上下架、商品資料更新等等），也沒有店鋪的概念；

最初，得物平臺內的交易與社區、鑑別「環環相扣」，因此當時的交易平臺是寫在同一個 PHP 項目內，集羣部署、共享緩存、數據庫。雖然，是很簡單的設計，但對於當時的得物倒是最合適的：能運行，迭代速度快，能夠快速響應需求，很好的支撐了那個階段的業務發展。

隨着得物的業務發展，交易平臺必須可以支持更大規模的業務、支撐其差別化的交易。所以，交易平臺的迭代優化勢在必行。

2019 年下半年，因爲業務發展太快，原有的交易平臺開始暴露出問題。一方面是沒法承載更大的流量，常常出現性能瓶頸，好比大促期間百倍流量忽然到訪，壓力倍增，穩定性也受影響；另外一方面，原有系統架構也難以支撐日漸複雜的業務需求，重複輪子越造越多。

在這種狀況下，得物 CTO 陳思淼決定啓動交易平臺化項目，統一規劃 & 重構整個交易體系，也就是「五彩石」項目。

其實在此以前，得物交易平臺也一直在作優化，包括服務拆分、引入新開發語言等等，可是底層數據模型並無發生變化。所以，五彩石項目首先從新設計了本來的商品、多個訂單系統、出價，造成了新的商品中心、訂單中心、出價中心、銷售庫存中心、寄存中心以及超時中心。而支付和營銷、商家，只是配合作了一部分調整，沒有歸入項目範圍。

3 交易平臺化項目的業務架構及技術選型

受限於早期的團隊技術基礎和業務模式，最初得物交易平臺技術選型和業務架構設計作了不少妥協。所以，在交易平臺化項目中着重對此前痛點進行了針對性設計，固然在此過程當中經歷了太多挑戰，在技術選型和模型設計時也有不少思考與決策。

首先是比較複雜的業務模型設計，當時團隊幾位骨幹討論了將近兩週，梳理出原有 9 個系統中的數十個對象，而後合併相似的對象及行爲，抽取出 6 個核心業務域，按照領域驅動設計的思路逐步設計整個系統。

以訂單系統爲例，當時得物存在多個訂單系統，分別面向不一樣類型賣家，在每一個訂單系統中都包含了整個下單與支付邏輯，並維護了各自的庫存，而其餘業務擁有各自的模型設計，生命週期有太多差別。若是從更高的視角看，這些都是圍繞訂單這一模型的分場景行爲。因此最終合併成統一的訂單中心，並引入狀態機引擎 Spring Statemachine 來解耦各個不一樣的交易流程，並在公用節點引入擴展點來實現差別化細節，而不該該屬於訂單領域的庫存、物流、支付等信息，則分別劃歸到各自領域。

設計商品模型時遇到了更多細節挑戰。商品實際上是整個交易體系中最基礎也最複雜的模塊之一，原設計在平臺不斷擴充品類的需求下難覺得繼，通過屢次討論，得物最終參考業界內多個主流電商平臺的設計，引入 SPU-Item-SKU 模型，同時針對搜索 & 推薦場景引入 CSPU（區別於天貓達爾文商品體系的 CSPU）、先後端數據解耦 (先後端類目)、屬性分類 (銷售屬性、基本屬性、供應鏈屬性、擴展屬性) 等等，完成了最終的商品域模型及行爲設計。

目前不少人在談領域驅動設計（DDD），DDD 確實有不少可取之處，但在應用時也很容易陷入爭論，例如領域、實體、值對象、聚合、聚合根、限界上下文、CQRS、事件溯源、分層架構、六邊形架構等等。實際上，DDD 的核心仍是領域模型自己，經過領域實體、領域服務完成對應的業務邏輯落地纔是 DDD 的核心目標，至於其它，選擇最合適本身、合適團隊的方式就足夠了。

再聊聊技術選型，按照當時的項目週期，可選空間相對有限，只能儘可能知足「夠用」的需求：

• 採用了基礎架構團隊基於 SpringCloud 全家桶封裝了一套腳手架 Fusion，同時加入了 prometheus 監控埋點，而內嵌的 Web 容器選擇了相較於 Tomcat 性能更好的 undertow。
• 同步內部通信選擇了 Feign；註冊中心採用 Consul，配置中心選擇了相對友好的 Apollo；
• 異步通信統一選擇了 RocketMQ，結束了原有多個 MQ 中間件混用的局面。
• 存儲方面，Redis+ 阿里雲 RDS，在部分大數據量場景作了數據 sharding(sharding-jdbc)。

交易平臺化項目上線後，通過後期的不斷迭代優化，目前交易平臺主要架構圖以下：

​

4 交易平臺化項目遇到的挑戰

技術選型只是完成了第一步，在得物交易平臺的整個落地過程當中還有不少難題須要解決，在金思宇看來主要的挑戰有三個：

首先是協調問題，由於只重構了部分核心項目（6 個），而整個交易流程涉及到的上下游不少，全部的上下游系統都須要協調來配合改造升級。據瞭解，當時涉及到的上下游系統共有 87 個，整個項目的上線及流量切換流程被拆解成了 180+ 個操做步驟，最終才完成上線。

其次是數據異構遷移，因爲底層數據模型作了從新設計，本來分散在各個系統內的訂單、庫存、超時信息等都須要統一轉換爲新的數據結構，並清洗到新的系統中，同時保證時效，儘量的下降對線上的影響。當時有 27 億 + 條數據在此過程當中被遷移，採用全量鋪底 + 增量追加的方式，在低流量時段停機 40 分鐘內完成。

最後是項目週期，整個交易平臺的項目週期是 2019 年 12 月 16 日到 2020 年 3 月 16 日。在項目後期，受疫情影響，全體項目成員遠程辦公，團隊溝通，項目效率，提測質量，上下游配合等有較大影響。

整個項目落地以後帶來的變化仍是很明顯的，經統計，得物 App 線上問題數目及客訴數減小了 80% 以上。同時，該項目還在不斷迭代優化，目前需求迭代能夠保持 1 到 2 周迭代一次，落地成本也明顯縮小。

5 經驗總結與分享

歷經三個月，得物交易平臺五彩石項目成功交付，陳思淼和金思宇全程參與了整個項目的迭代優化過程，並分享了一些經驗，與你們共勉。

• 在項目迭代優化過程當中，對原有業務的深刻理解很關鍵，不要否認原有的設計、系統，也不要急於落地新的東西，耐心吃透原有的業務邏輯，會讓以後的路順暢不少。
• 架構設計是很是重要的，尤爲對於一個龐大的重構項目，不但本身要想清楚，還須要明確輸出，同步給團隊本身的設計思路，同時充分吸取你們的反饋，有選擇的進行修正。
• 越是龐大的項目，越是須要精細化的管理和推動，得物當時選擇了小團隊日會、全體項目同窗雙日報、各 TL 週會的方式，及時發現問題並快速推動解決。
• 相信團隊的力量，基本每一個項目都不是一我的能夠單獨完成的，確定須要團隊內、外部的鼎力配合與相互協做，因此相信團隊的力量。

採訪嘉賓

陳思淼，得物 App CTO & 國際事業部 (POIZON Global) 總經理，負責得物 App 技術搭建、技術架構及團隊管理工做。陳思淼具有多年頂級互聯網平臺和電商平臺技術工做經驗。此前在阿里工做十一年，前後擔任淘寶資深技術專家，商家事業部技術負責人，Lazada CTO，阿里國際中臺技術負責人等職務。

金思宇，得物 App 交易平臺 & 穩定性平臺 Leader，畢業於東北大學，前後在中興通信、阿里巴巴、惟品會任職；對電商及上下游有比較豐富的開發及業務架構經驗。目前帶領團隊支撐得物 App 交易平臺的需求迭代，完善業務基礎能力，同時負責技術部穩定性體系搭建及持續建設。

活動推薦

陳思淼和金思宇將在 2020 年 12 月 20-21 日 QCon 全球軟件開發大會（上海站）上分享，介紹得物 App 的業務架構演進過程和技術細節。