嘉賓 | 陳思淼、金思宇
得物 App 專注打造新一代潮流網(wǎng)購社區(qū)。截止到目前，得物 App 平臺用戶中，90 后占比超過八成。品牌升級和業(yè)務增長的同時，對應的業(yè)務架構和技術體系也需要更新迭代。
2020 年 3 月 16 日，得物技術團隊在三個月的時間內(nèi)完成了整個交易體系的重構，交付了交易平臺化項目——五彩石項目。整個項目重新設計了 6 個核心交易應用，完成 180 項操作，21 個系統(tǒng)重新發(fā)布，相應的優(yōu)化迭代還涵蓋了社區(qū)、交易、供應鏈的解耦，交易平臺化的演進、底層交互協(xié)議的更新、全鏈路壓測落地等等。為了了解五彩石項目的整個構建過程，InfoQ 采訪了得物 App CTO 陳思淼、交易平臺和穩(wěn)定性平臺負責人金思宇。
1 電商平臺業(yè)務架構的發(fā)展
電商起源于 1990 年，經(jīng)歷了 30 年的發(fā)展，現(xiàn)在電商平臺已經(jīng)成為了主流購物方式之一。如果從業(yè)務架構的角度來看，中國電商平臺經(jīng)歷了幾個發(fā)展階段呢?陳思淼和金思宇從各自的工作經(jīng)歷出發(fā)，表示中國電商平臺的業(yè)務架構都經(jīng)歷了相似的四個階段。
第一階段：通常這時的電商平臺都是從零開始搭建的，全家桶系統(tǒng)，包含最基礎的交易元素：用戶、商品、庫存、訂單、支付。這些功能可能只是一個系統(tǒng)中的多個子模塊，甚至只是一個簡單的類，可以滿足最基礎的交易需求。
第二階段：隨著業(yè)務規(guī)模逐漸增大，團隊人數(shù)也越來越多，整個平臺維護難度增加，耦合嚴重，性能瓶頸也逐漸出現(xiàn)。這時就會開始做系統(tǒng)拆分，從業(yè)務域、基礎服務、前后端分離的角度慢慢分割，拆分后的系統(tǒng)之間進行通信 (同步 / 異步)。
第三階段：分布式服務，系統(tǒng)拆分之后，雖然各個服務會有多個團隊分別負責，職責清晰。不過服務之間的通信增多、依賴關系逐漸復雜，甚至需要支撐業(yè)務量會更大，這時就會對服務治理、監(jiān)控、緩存、數(shù)據(jù)分片、分布式事務等基礎建設有更高的要求。
第四階段：隨著業(yè)務發(fā)展，在分布式服務的基礎上，對服務穩(wěn)定性、高可用等方面需要有更高的要求。淘系做了單元化、異地多活之后，這基本上變成了多個電商甚至外賣平臺追求的統(tǒng)一思路;而在容器化逐漸流行起來后，基于容器化做彈性資源管理以及混合云 (異地多活) 就變成了另一種趨勢。
與其它平臺相比，電商平臺在數(shù)據(jù)準確性、一致性、安全性，以及服務性能、服務穩(wěn)定性方面都有比較高的要求，而且一旦出問題很容易被放大
所以，在做電商平臺的系統(tǒng)設計和落地時，應當著重考慮以下幾個方面：
是否在核心鏈路上，對于電商平臺，交易瀏覽鏈路及下單 & 支付鏈路 (包含優(yōu)惠活動 & 券) 屬于核心鏈路，需要評估應用是否會對核心鏈路造成影響，以及屬于強依賴還是弱依賴;
容量評估，包括峰值 QPS、每日產(chǎn)生的數(shù)據(jù)量，進而確認是否需要引入緩存、DB 選型(MySQL/TiDB)、數(shù)據(jù)是否需要 sharding、是否需要配置限流等;
性能評估，包括上下游依賴、對業(yè)務流程的影響、交互采用同步還是異步、對整體 RT 的影響等;對于核心鏈路上的服務，會在上線前做壓測評估;
對數(shù)據(jù)穩(wěn)定性的影響，包括對原有庫表 & 索引的影響、對原有數(shù)據(jù)字段的影響、上下游數(shù)據(jù)一致性影響等。
2 得物交易平臺的差異與發(fā)展
得物 App 技術平臺構建可以追溯到 2015 年。當時，得物 App 初版以潮流社區(qū) App 上線，打造國內(nèi)主流 Sneaker 互動社區(qū)(2015 年 9 月 -2017 年初)。后來，基于對潮流文化的了解和年輕消費的洞察，慢慢發(fā)現(xiàn)社區(qū)內(nèi)很多用戶有鑒別的強需求，才衍生出了交易業(yè)務 (2017 年下半年)。
得物與其它電商最大的區(qū)別是什么呢?得物 CTO 陳思淼表示最大的區(qū)別就是交易流程中包含鑒別環(huán)節(jié)，一次交易存在強參與三個角色：買家、平臺、賣家，而不像傳統(tǒng)電商，平臺很多時候只是提供流量入口。當然相應的，因為平臺的“強中心化”深度介入，一筆訂單對于賣家視角和買家視角，其生命周期并不相同，以現(xiàn)貨交易為例，對于賣家而言，平臺收到商品并且鑒別通過，就會收到貨款，這筆訂單對他而言也就達到了終態(tài);而對于買家，只有在收到貨之后才可能是終態(tài)。
除此之外，由于得物定位是潮流電商，因此對于平臺內(nèi)銷售的商品，其潮流屬性以及能否被鑒別有一定標準，所有商品都是平臺統(tǒng)一維護(上下架、商品資料更新等等)，也沒有店鋪的概念;
最初，得物平臺內(nèi)的交易與社區(qū)、鑒別“環(huán)環(huán)相扣”，所以當時的交易平臺是寫在同一個 PHP 項目內(nèi)，集群部署、共享緩存、數(shù)據(jù)庫。雖然，是很簡單的設計，但對于當時的得物卻是最合適的：能運行，迭代速度快，可以快速響應需求，很好的支撐了那個階段的業(yè)務發(fā)展。
隨著得物的業(yè)務發(fā)展，交易平臺必須能夠支持更大規(guī)模的業(yè)務、支撐其差異化的交易。因此，交易平臺的迭代優(yōu)化勢在必行。
2019 年下半年，由于業(yè)務發(fā)展太快，原有的交易平臺開始暴露出問題。一方面是無法承載更大的流量，經(jīng)常出現(xiàn)性能瓶頸，比如大促期間百倍流量突然到訪，壓力倍增，穩(wěn)定性也受影響;另一方面，原有系統(tǒng)架構也難以支撐日漸復雜的業(yè)務需求，重復輪子越造越多。
在這種情況下，得物 CTO 陳思淼決定啟動交易平臺化項目，統(tǒng)一規(guī)劃 & 重構整個交易體系，也就是“五彩石”項目。
其實在此之前，得物交易平臺也一直在做優(yōu)化，包括服務拆分、引入新開發(fā)語言等等，但是底層數(shù)據(jù)模型并沒有發(fā)生變化。因此，五彩石項目首先重新設計了原本的商品、多個訂單系統(tǒng)、出價，形成了新的商品中心、訂單中心、出價中心、銷售庫存中心、寄存中心以及超時中心。而支付和營銷、商家，只是配合做了一部分調(diào)整，沒有納入項目范圍。
3 交易平臺化項目的業(yè)務架構及技術選型
受限于早期的團隊技術基礎和業(yè)務模式，最初得物交易平臺技術選型和業(yè)務架構設計做了很多妥協(xié)。因此，在交易平臺化項目中著重對此前痛點進行了針對性設計，當然在此過程中經(jīng)歷了太多挑戰(zhàn)，在技術選型和模型設計時也有很多思考與決策。
首先是比較復雜的業(yè)務模型設計，當時團隊幾位骨干討論了將近兩周，梳理出原有 9 個系統(tǒng)中的數(shù)十個對象，然后合并類似的對象及行為，抽取出 6 個核心業(yè)務域，按照領域驅動設計的思路逐步設計整個系統(tǒng)。
以訂單系統(tǒng)為例，當時得物存在多個訂單系統(tǒng)，分別面向不同類型賣家，在每個訂單系統(tǒng)中都包含了整個下單與支付邏輯，并維護了各自的庫存，而其他業(yè)務擁有各自的模型設計，生命周期有太多差異。如果從更高的視角看，這些都是圍繞訂單這一模型的分場景行為。所以最終合并成統(tǒng)一的訂單中心，并引入狀態(tài)機引擎 Spring Statemachine 來解耦各個不同的交易流程，并在公用節(jié)點引入擴展點來實現(xiàn)差異化細節(jié)，而不應該屬于訂單領域的庫存、物流、支付等信息，則分別劃歸到各自領域。
設計商品模型時遇到了更多細節(jié)挑戰(zhàn)。商品其實是整個交易體系中最基礎也最復雜的模塊之一，原設計在平臺不斷擴充品類的需求下難以為繼，經(jīng)過多次討論，得物最終參考業(yè)界內(nèi)多個主流電商平臺的設計，引入 SPU-Item-SKU 模型，同時針對搜索 & 推薦場景引入 CSPU(區(qū)別于天貓達爾文商品體系的 CSPU)、前后端數(shù)據(jù)解耦 (前后端類目)、屬性分類 (銷售屬性、基本屬性、供應鏈屬性、擴展屬性) 等等，完成了最終的商品域模型及行為設計。
目前很多人在談領域驅動設計(DDD)，DDD 確實有很多可取之處，但在應用時也很容易陷入爭論，例如領域、實體、值對象、聚合、聚合根、限界上下文、CQRS、事件溯源、分層架構、六邊形架構等等。實際上，DDD 的核心還是領域模型本身，通過領域實體、領域服務完成對應的業(yè)務邏輯落地才是 DDD 的核心目標，至于其它，選擇最合適自己、合適團隊的方式就足夠了。
再聊聊技術選型，按照當時的項目周期，可選空間相對有限，只能盡量滿足“夠用”的需求：
采用了基礎架構團隊基于 SpringCloud 全家桶封裝了一套腳手架 Fusion，同時加入了 prometheus 監(jiān)控埋點，而內(nèi)嵌的 Web 容器選擇了相較于 Tomcat 性能更好的 undertow。
同步內(nèi)部通訊選擇了 Feign;注冊中心采用 Consul，配置中心選擇了相對友好的 Apollo;
異步通訊統(tǒng)一選擇了 RocketMQ，結束了原有多個 MQ 中間件混用的局面。
存儲方面，Redis+ 阿里云 RDS，在部分大數(shù)據(jù)量場景做了數(shù)據(jù) sharding(sharding-jdbc)。
交易平臺化項目上線后，經(jīng)過后期的不斷迭代優(yōu)化，目前交易平臺主要架構圖如下：
4 交易平臺化項目遇到的挑戰(zhàn)
技術選型只是完成了第一步，在得物交易平臺的整個落地過程中還有很多難題需要解決，在金思宇看來主要的挑戰(zhàn)有三個：
首先是協(xié)調(diào)問題，因為只重構了部分核心項目(6 個)，而整個交易流程涉及到的上下游很多，所有的上下游系統(tǒng)都需要協(xié)調(diào)來配合改造升級。據(jù)了解，當時涉及到的上下游系統(tǒng)共有 87 個，整個項目的上線及流量切換流程被拆解成了 180+ 個操作步驟，最終才完成上線。
其次是數(shù)據(jù)異構遷移，由于底層數(shù)據(jù)模型做了重新設計，原本分散在各個系統(tǒng)內(nèi)的訂單、庫存、超時信息等都需要統(tǒng)一轉換為新的數(shù)據(jù)結構，并清洗到新的系統(tǒng)中，同時保證時效，盡可能的降低對線上的影響。當時有 27 億 + 條數(shù)據(jù)在此過程中被遷移，采用全量鋪底 + 增量追加的方式，在低流量時段停機 40 分鐘內(nèi)完成。
最后是項目周期，整個交易平臺的項目周期是 2019 年 12 月 16 日到 2020 年 3 月 16 日。在項目后期，受疫情影響，全體項目成員遠程辦公，團隊溝通，項目效率，提測質(zhì)量，上下游配合等有較大影響。
整個項目落地之后帶來的變化還是很明顯的，經(jīng)統(tǒng)計，得物 App 線上問題數(shù)目及客訴數(shù)減少了 80% 以上。同時，該項目還在不斷迭代優(yōu)化，目前需求迭代可以保持 1 到 2 周迭代一次，落地成本也明顯縮小。
5 經(jīng)驗總結與分享
歷經(jīng)三個月，得物交易平臺五彩石項目成功交付，陳思淼和金思宇全程參與了整個項目的迭代優(yōu)化過程，并分享了一些經(jīng)驗，與大家共勉。
在項目迭代優(yōu)化過程中，對原有業(yè)務的深入理解很關鍵，不要否定原有的設計、系統(tǒng)，也不要急于落地新的東西，耐心吃透原有的業(yè)務邏輯，會讓之后的路順暢很多。
架構設計是非常重要的，尤其對于一個龐大的重構項目，不但自己要想清楚，還需要明確輸出，同步給團隊自己的設計思路，同時充分吸收大家的反饋，有選擇的進行修正。
越是龐大的項目，越是需要精細化的管理和推進，得物當時選擇了小團隊日會、全體項目同學雙日報、各 TL 周會的方式，及時發(fā)現(xiàn)問題并快速推進解決。
相信團隊的力量，基本每個項目都不是一個人可以單獨完成的，肯定需要團隊內(nèi)、外部的鼎力配合與相互協(xié)作，所以相信團隊的力量。
采訪嘉賓
陳思淼，得物 App CTO & 國際事業(yè)部 (POIZON Global) 總經(jīng)理，負責得物 App 技術搭建、技術架構及團隊管理工作。陳思淼具備多年頂級互聯(lián)網(wǎng)平臺和電商平臺技術工作經(jīng)驗。此前在阿里工作十一年，先后擔任淘寶資深技術專家，商家事業(yè)部技術負責人，Lazada CTO，阿里國際中臺技術負責人等職務。
金思宇，得物 App 交易平臺 & 穩(wěn)定性平臺 Leader，畢業(yè)于東北大學，先后在中興通訊、阿里巴巴、唯品會任職;對電商及上下游有比較豐富的開發(fā)及業(yè)務架構經(jīng)驗。目前帶領團隊支撐得物 App 交易平臺的需求迭代，完善業(yè)務基礎能力，同時負責技術部穩(wěn)定性體系搭建及持續(xù)建設。
活動推薦
陳思淼和金思宇將在 2020 年 12 月 20-21 日 QCon 全球軟件開發(fā)大會(上海站)上分享，介紹得物 App 的業(yè)務架構演進過程和技術細節(jié)。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）
