vivo 全球商城：從 0 到 1 代銷業務的融合之路

代銷是 vivo 商城已經落地的成熟業務，本文提供給各位讀者 vivo 商城代銷業務中兩個異構系統業務融合的對接經驗和架構思路。

1、業務背景

近兩年，內銷商城業務的發展十分迅速，vivo 商城系統的架構也完成了從單體往分佈式的演進。咱們在 vivo 商城服務化方向作了不少的努力，基礎服務的能力逐漸沉澱下來。

2019年咱們也開始在產品功能上玩起了多元化的營銷業務。目前手機品類還是咱們銷售的主力，可是非手機品類的sku單品數量仍是不多，巧婦難爲無米之炊。

爲了解決非手機品類商品豐富度問題，運營考慮和電商平臺進行合做，但願用代銷的方式爲商城擴充更多的非手機類商品品類。

先跟你們解釋下「採銷」和「代銷」的區別，簡單來說就是一個貨權歸屬的問題，採銷是買貨到咱們倉庫進行售賣，可自由訂價；代銷是貨權歸屬於平臺方，也就是貨還放在對方的倉庫，用「以銷定採」的方式進行售賣，有利潤空間，可是自主訂價受限。

因此代銷業務一開始就帶着明確的目標出發了，咱們但願經過接入其餘的電商平臺可以作到如下幾點：

• 改變商品品類匱乏的現狀，品類變多能進一步豐富促銷玩法；
• 提高運營效率，解決代銷類商品從選品到商城上架週期過長的痛點。

2、平臺選擇

一開始選擇了幾個平臺方，爲了提高選擇效率，咱們先對平臺方定了幾個重要的參考指標，目的是要能過濾存在對接風險的平臺。

對接參考指標：

• 【文檔清晰】必需要有完整的API文檔，文檔邏輯要清晰，不能模棱兩可；
• 【接口完備】至少具有知足全流程的數據同步接口（能實現數據的全量和增量）、異步通知（商品變動、訂單狀態流轉等異步變動）等；
• 【商品模型】提供的商品模型要結構化。例：遇到sku信息採用內嵌html的方式，嘗試用Demo預研後，效果不好；
• 【成功案例】這個具備很是重要的參考做用。通常在對方的站點上都會宣傳一些成功案例，能夠去體驗下，由於很大可能最終接入的效果會和他們同樣；
• 【溝通機制】健全的溝通機制也很重要（剛開始咱們沒有重點考慮，致使對接過程溝通仍是不太通暢）。

可是參考指標只能做爲一個篩選器排除不能對接的。剩下的平臺方，須要咱們從技術和產品的角度進行深度的調研分析，預研期間也主動和各個平臺方電話溝通了幾回，最終咱們挑了一個各個方面都比較合適的候選人「網易嚴選」。

3、挑戰

此次對接任務是經過對方提供的API接口，把他們的商品同步過來在咱們商城進行售賣。

咱們要求的是商城能正常地展現，用戶能正常的下單並支付，同時支持逆向的用戶取消訂單，退款退貨等等。

可是外部系統的對接存在不少的風險，尤爲是非公司的第三方異構系統，並且對接的是包含商品、訂單的全流程，咱們要面對不少的挑戰。

1. 未知挑戰

• 首先要考慮商品數據能不能完美地融合進來？
• 其次訂單的正逆向流程能不能打通？
• 對方是否有環境可以測試驗證？生產環境接入有沒有過多的限制？安全性如何保證？
• 對方能不能及時、準確地解決咱們遇到的問題？

2. 前期預研

爲了保證全流程完整接入的可控，咱們先和對方溝通了測試環境配置，嘗試調通他們的接口。

緊接着咱們開發人員分紅了兩批，一批嘗試經過手工組裝字段把對方商品接入vivo商城，一批預研訂單正逆向的全流程，此次咱們嘗試接入的目的很明確「打通全流程」。

3. 預研結果

最終經過使用 Demo 拉取對方報文，手工組裝數據，快速試錯，實驗結果和前期預研的同樣，經過實踐證實全流程確實可行，鏈路能打通！實驗結果讓你們信心大增，也預示着咱們能夠整裝待發，正式踏上代銷系統的架構之路了。

4、代銷業務的設計

1. 開篇

在正式設計以前，咱們須要對新系統有點暢想，由於咱們不只僅只是完成此次對接的任務，咱們更但願它擁有更抽象的業務功能，具有必定的擴展能力。

架構代銷平臺的意義：

• 對接外部系統，提高咱們自身的系統架構、設計的能力；
• 填補代銷的空白，將來咱們但願這個平臺可以達到快速對接的目的；
• 積累必定的經驗，將來定製咱們本身的標準API，低門檻接入品質好的第三方。

2. 系統設計

咱們把系統簡單地歸類，劃分紅了三部分，從左往右分別是平臺方 → 代銷平臺 → 商城內部系統。

代銷系統總體的設計的思路有點相似API網關，但在細節方面又有不少不一樣，代銷系統的設計仍是總體偏業務實現，也提供了額外的平臺方信息的查詢服務供內部系統調用。

2.1 平臺方系統

對咱們來講是個黑盒，他們的系統設計、數據交互咱們是沒法得知的，不過若是仔細研讀文檔的話，也能從他們提供的API中窺探一二，可是相比於對方的設計咱們更須要把精力花在和他們的溝通和環境聯調上。

2.2 代銷平臺

是此次設計的重點，它承接着外部和內部系統，是系統交互的重要紐帶。目前擺在咱們面前的仍是一張白紙，咱們須要先梳理下全部的基礎功能，把它的框架先搭建出來。

爲此，咱們制定了簡單的設計原則「無侵入，對內屏蔽掉底層適配的細節，關注服務自己，並具有必定的業務抽象和擴展能力」。而後在此設計原則基礎上咱們作以下比較精心的設計：

模塊化設計

對接嚴選以後，再對接其它平臺方的話。咱們但願各個平臺分紅模塊化進行對接。保證各接入方之間業務徹底隔離，互不侵入。

可以作到可插拔，如遇到合做終止的狀況，能以最小的成本關閉對接通道。

路由層

• 商城內部系統發過來的報文/請求能識別並路由到對應的平臺模塊中處理。
• 平臺方回調的報文可以準確解析並路由到模塊中去。

適配層

• 來自於適配模式（Adapter Pattern），適配能力是整個系統橫向的核心能力。
• 模塊化設計以後，各個對接的平臺都會具有獨立的適配層。
• 商城 ↔ 平臺方的商品和訂單維度的字段映射。
• 持久化雙方的主鍵映射關係，如：<vivoSpuId, YxSpuId>，<vivoOrderId, YxOrderId>。

服務暴露

• 提供映射關係查詢，如：商品spuId、訂單關聯關係映射。
• 提供對帳信息查詢。
• 提供平臺方冗餘信息查詢，如：平臺方更豐富的商品信息。

統一回調

• 開放外網訪問接口，提供接口給平臺方進行消息的異步回調。
• 創建訪問白名單，接收並將消息經過路由層分發到各平臺模塊進行處理。
• 異步回調的消息包含：商品信息變動、庫存預警&校準、訂單狀態流轉等。

統一配置

• 利用配置中心統一管理各平臺方對接帳號、祕鑰等信息。
• 系統監控指標閾值、告警、開關等。

橫向能力

• 接口調用異常監控、業務異常告警等。
• HTTP底層通訊服務。

2.3 內部系統

2.3.1 商品中心

【高可用】

以前對外提供的都是高QPS的只讀Dubbo接口，此次要開Dubbo寫接口提供給代銷系統來建立商品。

瞭解接口設計的小夥伴都比較瞭解，寫接口最主要的是保證事務的同時要能作到防刷防重。爲此咱們在寫接口上加了統一驗籤（內部系統弱校驗）和接口冪等性設計。

【接口設計】

你們平時在瀏覽電商網站的時候，商詳頁呈現出來的內容是十分豐富的，這也間接說明了商品的模型自己仍是比較複雜的，因此在設計商品寫接口的時候，開發內部產生了爭論，討論出了兩個方案。

方案一：部分開發認爲應該按如今的商品模型，把接口打散，代銷平臺對接多個寫接口，好處是局部更新比較方便，也避免一次性提交一個大事務；

方案二：另外一波同窗認爲就應該是一個接口，不然會出現接口散亂、亂序的狀況。

最終咱們仍是採納一次性提交的方案二，雖然會有大事務的風險，可是能夠經過代碼層面來緩解，並且架構設計自己就是一種權衡，設計接口的時候仍是要多站在調用方的角度，對方確定不會但願服務方的接口是散亂、無序的，這會增長調用和維護的成本。

2.3.2 訂單中心

【正逆向的流程】

訂單的難題最主要仍是雙方流程的融合，因此咱們針對代銷邏輯作了部分的流程改造。

這邊只給你們舉一個下單的例子，嚴選提供的建立訂單API實際上包含的是下單+支付兩個動做，爲了適配他們的流程，咱們作了點改造。

當用戶在商城下完訂單以後，代銷系統僅對接嚴選作庫存和配送區域的校驗，確保訂單能下成功。等用戶在商城側支付完成後，代銷再次發起建立訂單的請求給到嚴選。若是遇到建立異常（從數據上看不多幾乎沒有），咱們也會有自動的取消流程。

3. 嚴選對接邏輯

上面的設計肯定了各個模塊的功能，劃分了業務的邊界，讓咱們看清了總體的骨架和脈絡。可是咱們還須要畫一張切實可行的調用關係圖，讓整塊邏輯立體豐滿起來，最終讓每一個開發都知道此次網易嚴選該怎麼去對接。

5、呈現效果

代銷商品覆蓋了官網商城列表頁、活動頻道頁、選購頁，展現效果以下：

 

6、展望將來

咱們在前期也遇到有些品類比較好的平臺方，可是因爲技術緣由沒法和咱們系統完成對接，也挺遺憾的。將來咱們但願代銷平臺也能本身制定一套API標準，對方按照咱們的標準，本身開發接口把數據傳給咱們就好了，這樣就少了不少溝通和接入的成本。

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