vivo 全球商城：架構演進之路

本文講述 vivo 官方商城從單體應用到具有綜合能力電商平臺的演進，系統架構往服務化、中臺化的變遷歷程。

1、前言

vivo官方商城，是vivo官方的線上電商平臺，主營vivo手機及專屬配件。通過幾年發展，已經完成了從單體應用到具有綜合能力電商平臺的演進，總體系統架構也逐步往服務化、中臺化變遷。咱們在這條系統架構升級的道路中，實踐出了一些系統架構經驗。

經過本篇文章，可讓對電商感興趣的小夥伴們，更爲全面地瞭解最基礎的電商業務模式，瞭解電商體系具有的技術和架構，瞭解系統在不一樣時期的架構演進。

2、架構變遷史

「冰凍三尺，非一日之寒」。任何一個電商系統的架構升級，都不是一蹴而就的，都須要一個穩步發展的過程，不一樣階段業務發展的形態和體量決定着系統架構。下面從一張圖開始，給你們描述下商城近幾年架構變遷的歷史。

（圖1.1 vivo官方商城架構變遷歷程）

2015年以前，vivo官方商城是外包項目，採用了市面上比較成熟的ECStore（企業級開源網上電商系統）電商產品做爲系統基礎，主語言是PHP。

項目版本就是在此基礎上進行二次開發迭代。

和大多數電商平臺早期的發展同樣，知足快速部署、快速上線。

同時弊端也很明顯：

• 性能不好，根本沒法支撐稍大一點的運營活動。當有新品、大促活動，系統負載高，業務基本處於不可用狀態，沒法知足運營活動需求。

• 需求溝通效率，研發效率低下，外包研發、產品異地辦公，需求溝通困難。

• 核心項目受制於人，vivo 官方商城必須掌握在本身手中。

爲了解決這些問題，架構迫切須要升級、系統須要重構。

2.1 商城 v1.0 單體時期

2015年5月，vivo官方商城正式啓動重構計劃。vivo啓用本身的研發團隊，目標很明確，自研一套屬於本身的vivo官方商城，爲用戶提供更好的購物體驗。

在2016年1月，屬於咱們本身的vivo官方商城正式上線了。

商城v1.0以主流的 Java 做爲開發語言，採用經典的 MVC 框架，開發出了一個囊括了各個業務模塊的單體應用，總體業務模塊以下圖所示：

（圖2.1 商城v1.0系統架構）

相比以前，此次重構最重要的指導思想就是「分層」。

業務上對各個模塊進行邏輯分層。劃分出了商品模塊、訂單模塊、營銷模塊、結算模塊等等，使得代碼邏輯更爲清晰。

架構上也進行分層解耦：

• 【表現層】– 最貼近用戶的一層，主要用來處理數據展現邏輯並渲染數據；

• 【服務層】– 負責表現層與數據層之間的業務邏輯；

• 【數據層】– 負責數據的落地存儲，存儲介質使用經常使用的Mysql和Redis；

單體應用的時期，vivo官方商城業務發展尚處於初期，業務複雜度不高。首頁、商詳頁、結算頁邏輯比較簡單輕量。

v1.0的架構徹底可以知足支撐平常的新品及活動運營，且版本迭代更爲快速。相比於ECStore 性能提高了至少兩個量級，因此商城v1.0的重構很是成功。

2.2 商城 v2.0  服務化

官方商城 v1.0 架構升級以後，平穩地度過了一段時間。近兩年，vivo手機產品愈來愈多，線上業務開始迅猛發展。

隨之而來的是用戶量級的快速增加，商城v1.0的單體架構弊端也逐漸暴露：

• 飛速增加的用戶訪問流量讓性能再次出現瓶頸，單體的數據庫和Redis難以抵擋。

• v1.0 架構對業務模塊進行了分層，分層僅限於代碼模塊級別的拆分，沒有從物理上進行隔離，單體應用愈發臃腫。

• 全部研發維護同一套代碼，項目工程維護變得困難。快速迭代的版本讓模塊之間分層的界限變得模糊，代碼腐化嚴重，開發效率變得低下。

基於以上問題，咱們開始基於業務模塊進行垂直的系統物理拆分。新的系統架構採用主流的SOA架構（Service Oriented Architecture，即面向服務的架構）。

商城 v2.0 從2017年開始，以服務化爲核心穩步進行拆分獨立。咱們得保證既有的業務不受絲毫影響的狀況下獨立模塊，有人形容這個過程爲「高速換輪胎」，動做稍有不慎，對系統來講都是致命的。

最終在花了近一年半的時間，咱們實現了活動、商品、訂單、優惠券四大核心繫統的拆分。拆分出來業務線開始各司其職，提供服務化的能力，共同支撐主站業務。

（圖2.2 商城 v2.0系統架構）

下面將介紹各個系統拆分的整個過程。

2.2.1 活動系統獨立

官方商城做爲vivo的惟一線上官方渠道，承載着全部新品的線上活動需求。每次的新品發佈會，都是由商城系統負責完成。大量頻繁的活動需求，引發頻繁的商城版本變動、上線，引起咱們的思考。

相比電商的核心交易鏈路，活動系統自己比較獨立，不該與主線交易耦合在一塊兒。所以在2017年年中，將商城中的專題頁配置，新品發佈會，抽獎，預定功能剝離出來，獨立出了商城活動系統。

2017年8月，活動系統獨立上線。新的活動系統開始承接新品、大促等各類促銷活動需求。隨着活動系統不斷迭代發展，目前已經成爲電商平臺一個重要組成部分。

2.2.2 商品系統獨立

商品系統是支撐整個電商平臺的核心，是電商系統中最重要的組成部分。商品鏈接着用戶和平臺，經過商品的詳情頁能夠完美地向用戶展現產品內容，詮釋產品內涵。

商城 v2.0 服務化，商品是此次整改的重點。

咱們在思考v1.0架構帶來系統性問題的時候，也開始思考如何經過此次拆分來對應將來的業務增加。商城v1.0商品模塊亟待解決的問題：

• 商品的品類建立受限，只有垂直類的手機和配件，沒法支持全品類。

• 商品不支持店鋪、品牌維度，比較單一。

• v1.0商品模塊的查詢性能低下，單實例Redis沒法知足高性能、高可用。

• 歷史 v1.0商品接口和模型已經***到各個模塊，完整地剝離出來比較困難。

商品系統的獨立是帶着以上的問題和思考進行的，大的目標是劃清業務邊界，完全和商城解耦。咱們但願分離後的商品系統可以更好、更快速地承接將來全品類的擴展，全面服務化。爲進一步服務好商城主體業務夯實基礎。

2.2.3 優惠券系統獨立

優惠券是業界內經常使用的營銷手段之一，每到大促、節假日、新品，都會發放大量的優惠券。與外部廣告商合做、內購福利、保值換新等也以優惠券的形式承載。

隨着營銷活動力度加大，優惠券使用場景增多，優惠券系統問題也逐漸暴露：

• 海量優惠券的發放，達到優惠券單庫、單表存儲瓶頸。

• 與商城系統的高耦合，也直接影響了商城整站接口性能。

• 針對多品類優惠券，技術層面沒有沉澱通用優惠券能力。

優惠券系統獨立須要解決的就是以上問題，獨立後優惠券存儲能力提高，支撐將來5年內的優惠券發放量級。總體發券接口性能也獲得提高，發券由原來的異步發券、異步到帳，優化到同步發券、實時到帳。同時提供平臺級優惠券能力，面向全公司業務，提供通用的優惠券營銷能力。

2.2.4 訂單系統獨立

訂單系統也有與優惠券一樣的問題，隨着用戶量級的爆發式增加，性能問題逐漸暴露：

• 數據不斷累積，快要達到單表存儲瓶頸，致使訂單的查詢和修改速度很慢。

• 單機MySQL處理能力有限，併發量上來時直接拖垮整個商城的全部業務。

訂單系統的獨立，首次引入了 ES，Sharding-JDBC 等技術組件，解決數據量和高併發的痛點。訂單系統上線後，不管是訂單的存儲量級仍是下單的併發量級，都提升了不止十倍，至少知足將來 5 年的業務高速發展。

至此，商城核心系統拆分完成，各系統提供統一標準化服務，具有更純粹的業務基礎能力，與商城主站解耦，迭代效率大幅提高。

2.3 商城 v3.0  業務系統拓展

商城 v3.0 是針對商城業務快速發展，進行的業務系統完善。

這一階段因爲商城業務渠道不斷擴展，促銷玩法不斷增多，商城衍生出不少獨立的業務子系統。其中包含代銷系統、CPS系統、促銷系統3 大業務系統。

（圖2.3 商城 v3.0系統架構）

2.3.1 代銷系統：商城與代銷商品紐帶

爲了豐富自身的商品品類，支撐起更多的運營玩法，咱們開始探索代銷的業務，嘗試對接品類優質的平臺方。不少平臺方也都支持系統對接，採用以銷定採的銷售模式。

代銷系統就在此背景下誕生了。咱們但願代銷系統可以成爲外部平臺方和vivo商城之間的「粘合劑」，並可以提供如下的主要功能：

• 支持兩個平臺商品數據模型的轉換，支持部分信息二次編輯，更加本地化。

• 實時同步平臺方商品庫存、價格、訂單正逆向信息的同步。

• 支持vivo商城用戶的商品瀏覽、以及下訂單服務，知足用戶購物的完美體驗。

代銷系統是咱們對接外部系統，引入外部商品售賣的一次嘗試。代銷的通用能力被咱們徹底沉澱了下來，可以持續支撐後續其餘平臺商品接入。

2.3.2 CPS系統：商城返利平臺

CPS 系統的定位是 vivo 官方商城體系下的推廣返利平臺系統。商城的業務不斷擴展，商城的業務羣體也開始向外拓展。主要針對一些帶貨能力強的大V以及一些外部推廣平臺，以返傭的形式，最大限度發揮其帶貨能力。

隨着用戶羣體以及推廣平臺接入，CPS 系統逐漸沉澱一些基礎能力，目前支持 toB、 toC 通用接入能力。

2.3.3 促銷系統：商城營銷百花齊放

促銷系統是商城的促銷中心，承載着商城全部的營銷玩法。

促銷系統的獨立，源於商城v2.0 架構沒法知足不斷增長的活動玩法，它解決了商城原有促銷的如下痛點：

• 繁雜的活動堆砌，沒有嚴格活動優先級關係。

• 新的活動需求的加入，改動量和影響點範圍廣，沒法準確評估。

• 促銷性能沒法知足活動量級，每每會影響商城主站的性能。

促銷系統獨立，與商城解耦，提供純粹的商城營銷活動玩法。促銷系統還包括：商品計價與商品價格監控基礎能力。

3、國際化

隨着經濟全球化日益加深，國產品牌紛紛佈局海外，印度做爲海外最大單一市場，擁有很是廣闊的市場前景，順應當地市場的需求，上線印度版官方商城提上日程。

2017年12月，印度vivo官方商城正式上線運營。

印度官方語言共有22種，目前已登記的語言超過1600種，支持多語言是國際化進程中首要課題。傳統的 i18n 方案，可以解決基本的文案配置問題，可是項目須要走發佈流程，維護成本很是高。

多語言文案系統標準化了文案需求的提出、翻譯、測試、發佈等流程，極大地提高了發佈效率和文案質量。

（圖3.1  多語言文案中心）

2020年11月，泰國 vivo 官方商城也正式上線運營。

與國內電商相比，海外電商業務須要覆蓋多個國家/地區，每一個地區都有本身的語言、時區、貨幣等等，如何使用一套代碼同時支持多個地區，是咱們必需要面對而且解決的問題。

通過3年時間的摸索和打磨，咱們打造出了一套通用的全球化解決方案，包括多語言文案系統、多時區通用組件、多國家隔離框架、多機房域名部署方案等等，已經可以較好的支撐當前業務的發展須要。

（圖3.2  多時區通用組件）

（圖3.3  多國家隔離框架）

上述方案，抽象公共配置的思想以及相應的隔離技術點，即便是在非國際化場景中，也具備較大的參考價值。

海外市場複雜多變，語言文字、文化差別、地區標準、法律法規等不盡相同，地區發展階段和基礎設施成熟度也有較大差別。

挑戰與機會並存，咱們既要全力支撐業務發展，也要優先完成合規整改要求；咱們既要提煉一套通用的國際化架構，也要知足本地化定製需求；咱們既要合理應用發達地區高網速，也要兼顧欠發達地區頁面加載性能優化。

「more local more global」，隨着全球化進程的加深，咱們會繼續錘鍊全球化架構，鍛造出更加健壯的國際化/本地化產品。

寫在最後，本篇主要是簡要的介紹vivo官方商城這5年來的一些大的架構歷史變遷，不作過多的技術解讀。

這裏的介紹只是商城技術背後的冰山一角，後續咱們會出更多相關係列文章，去詳細介紹每一個系統的架構與核心技術。

做者：vivo 官網商城開發團隊